Re: [boost] [next gen future-promise] What to call the monadic return type?

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_exception().

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

> > > > * 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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/