Boost logo

Boost :

Subject: Re: [boost] Interest in an 'either' library?
From: David Sankel (camior_at_[hidden])
Date: 2013-06-24 23:55:25

On Mon, Jun 24, 2013 at 1:19 PM, Eric Niebler <eniebler_at_[hidden]> wrote:

> On 13-06-24 11:53 AM, Pierre Talbot wrote:
> >>
> >> 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:
> >>
> >>
> >
> > In the Expected proposal, there are some methods related to this idea.
<snip various do-syntax derivatives>

If we really care about adding a do syntax EDSL, why not make it general
purpose like Haskell's version so that it can work with any monad and
compose better with other things?

either<error, int> result =
    set( _x, getInt ),
    set( _y, getInt ),
    doReturn( pure( _x + _y ) ) );

If we're going to do that, lets do it generically and completely.

> > 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.
> Seems a bit excessive to me to have both. If we get Expected, then
> Either is unnecessary -- it's just one template alias away from variant.
> I don't consider the syntactic niceties of "left" and "right" to be
> compelling, and if folks want it, we can provide left and right free
> functions for 2-arg variants. But IMO automatic error propagation is the
> *only* thing that can make this proposal compelling.

I personally find myself using std::pair frequently even though it is also
just one template alias away from std::tuple. I still think there's a case
for exposing these commonly-useful simple building blocks. Incidentally,
the std::pair monad is also interesting.


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