Boost logo

Boost :

Subject: Re: [boost] [next gen future-promise] What to call the monadic return type?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-26 06:23:13

On 26 May 2015 at 5:07, Rob Stewart wrote:

> On May 25, 2015 7:09:57 PM EDT, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
> > On 25 May 2015 at 23:35, Vicente J. Botet Escriba wrote:
> >
> > Names suggested so far are maybe, result, holder, value.
> I'm still trying to understand use cases to help guide naming.

Exactly why I asked for people to bikeshed here on the naming. I am
also unsure.

> However,
> among those choices, "result" seems best. That said, one often refers to
> the result of a function, so discussing a function that returns a
> "result" would get awkward. Perhaps "retval" would convey the idea well
> enough and be less awkward?

One vote for result<T>. One vote for retval<T>. Okay.

I think that's three votes for result<T> now, none for maybe<T>.

> > result<int> v(5);
> > assert(v.get()==5);
> > v.set_value(6);
> > assert(v.get()==6);
> > v.set_exception(foo());
> > v.get(); // throws foo
> > v.set_error(error_code);
> > v.get(); // throws system_error(error_code)
> Can one ask whether it contains an exception or an error_code? Can one
> retrieve the exception or error_code without calling get() with, say,
> get_exception() and get_error_code()?

Of course. As with Boost.Thread's future, there are has_value(),
has_error(), has_exception() plus get(), get_error(),

get() will throw any error or exception. get_exception() returns any
error or exception as an exception_ptr. get_error() returns an

> > > > * maybe<T>
> > > we have already optional, isn't it?
> >
> > True. But I think a monadic transport supersets optional as it can
> > have no value. So:
> >
> > result<int> v;
> > assert(!v.is_ready());
> > assert(!v.has_value());
> > v.get(); // throws no_state.
> Here you show has_value(). Are there has_exception() and has_error_code()?

Yes. There is also is_ready(), also from Boost.Thread. This is
aliased by explicit operator bool. Finally on the monad but not
future, there is a reset().

On future<T>, but not result<T>/retval<T>, there is also a valid()
which tests if a future has an associated promise or is ready. You
also cannot set the state of a future except via its promise - those
member functions are inherited from monad into future by protected
inheritance, and are not exposed publicly.

I haven't implemented them yet, but I am also going to add some of
the essential monadic operators from Expected which enable if, and
only if, your callable is noexcept. The rationale for insisting on
noexcept is that a later clang AST analysis tool can convert monadic
logic into a formal mathematical proof if and only if noexcept is
enforced, and this is not a limitation because the monadic transport
can carry exceptions.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at