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

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

On May 25, 2015 7:09:57 PM EDT, Niall Douglas 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/