Re: [boost] Interest in an 'either' library?

Subject: Re: [boost] Interest in an 'either' library?
From: Pierre Talbot (ptalbot_at_[hidden])
Date: 2013-06-24 14:53:17

>
> This misses what is, IMO, the most important use case of Haskell's
> Either monad: automatic error propagation. This would be more useful if
> there were a way to call a function such that if any of the function's
> arguments were an Either-in-error, the function would immediately return
> the error.
>
> I implemented something like this. Check out substitution_failure and
> try_call starting here:
>
> https://github.com/ericniebler/proto-0x/blob/master/boost/proto/v5/utility.hpp#L742
>

In the Expected proposal, there are some methods related to this idea. 
Actually, the "then" method can be applied on an expected and 
immediately returns the expected if it contains an error. Furthermore, 
you can chain function calls until one of these fail.

Here one of the use-case shown in the proposal:

expected<int> create_and_connect()
{
   return socket() // call the function socket that creates an expected.
         .then(connect) // Pass the expected handle to connect if it contains a 
value, otherwise just returns it.
          .on_error(error_resolver); // Use the error_resolver if the 
last expected contains an error, otherwise just returns it.
}

There is maybe two advantages to this then function:

* Chaining multiple calls.
* A specific error resolver in case of failure.

But it doesn't offer multiple argument check, and that's why we also 
proposed if_all:

if_all(f(), g()).then(h).on_error(error_resolver);

I think this one is much more related to your function.

I honestly think that if Either goes into Boost, we shouldn't consider 
it as a value or error structure at all. Expected (will) do the job.