Re: [boost] [next gen futures] Lightweight monad ready for inspection

Le 21/06/15 09:07, Vicente J. Botet Escriba a écrit :

Le 19/06/15 19:03, Niall Douglas a écrit :

...

Some may remember the thread starting from http://boost.2283326.n4.nabble.com/next-gen-future-promise-What-to-cal l-the-monadic-return-type-td4676039.html and that I would firstly prepare an optimally lightweight monad<T> for review here before going on to base a next-gen lightweight future-promise on that monad<T>.

Nial, I don't understand why you call this class monad. I see it much more as a generalized optional_expected that allows the user to say which exception is thorw when there is an error type and not an exception type.

IMO, the last parameter throw_error is really not needed.

You can always wrap an error code with a class that states how to throw an exception. That means that we need an additional Error concept that defines the throw_error function, e.g.

We could have a class that wraps an error with an exception

template struct ThrowError { Error value; };

template void throw_error(ThrowError const& e) { throw Exception(e.value); }

Now the generalized optional/expected class will use the throw error whenever it needs to throw an exception and has an error type stored.

BTW, why have you chosen a Callable for throw_error instead of directly the Exception?

BTH, expected could already store an error or an exception_ptr. All you need is to have a class

template struct ErrorOrException;

Resuming you monad class is in some way an alias of

expected, Exception>>

possibly optimized with a specific specialization.

BTW, why your class accepts only on Exception type and not a variadic set of Exceptions types?

I have some trouble with the is_ready function. You say "True if monad is not empty.". Do you mean that oi will not be ready

optional<int> oi;

You need to add the preconditions of each function. No precondition mean the function is not partial.

I don't see comparison operators, neither hash customization, was this intentional?

I suspect that the exception thown by value() when an instance is empty is not future_error,and that there is a type on the documentation. Or was this intentional?

In the function value()&& you say "If contains a value_type, returns a rvalue reference to it, else throws an exception of future_error(no_state), system_error or the exception_type."

Why system_error? Do you mean that when the exception_type given as parameter is exception_ptr, the exception throw is exception_ptr and not the stored exception? In the Expected proposal and in std::future, the exception throw will be the stored exception.

The function has_exception is not coherent with the others state observer functions empty/has/value/has_error.

What is the exact signature (or valid signatures) of the functions passed to map/bind/then? BTW, are these functions proposed?

Last can the map function be applied to an empty instance? What would be the result?

I would like to suggest a different approach. Given a class optionals, which is a variant accepting to be empty we can see optionals as an Error Monad, when all the Ei are instances of the Error concept. A class is a model of the Error concept if it defines the rethrow_exception function. When the optionals is empty the exception thrown is bad_optionals_access. exception_ptr is a type erased Error that rethrows the stored exception. std::error_code and std::error_condition can be seen as instances of the type class Error if we define the rethrow_exception on them throwing an system_error exception. optionals can not define all the function that your class monad defines as they are too specific. Instead of defining member functions we can define non-member functions. has_value/has_error/value/set_value/set_error/get_error/emplace/map/bind/then optionals should be default constructible from Ti and convertible to Ti using maybe a specific cast function. optionals must be implicitly convertible from the result of throw_error(e). We could also define a specific class as you propose with specific semantic for the first argument that would defines member functions. I'm not against this approach, nevertheless the main issue I have is how to name this class :( result doesn't conveys the fact that it can be empty. monad is not good as Monad is a type class not a concrete type. optional_result is too long optional_value_or_errors is too long HTH, Vicente