Boost logo

Boost :

Subject: Re: [boost] Interest in an 'either' library?
From: David Sankel (camior_at_[hidden])
Date: 2013-06-22 09:10:21

On Sat, Jun 22, 2013 at 2:07 AM, Bjorn Reese <breese_at_[hidden]>

> You may want to check the GSoC 2013 proposal for Boost.Expected:
> http://google-melange.appspot.**com/gsoc/proposal/review/**
> google/gsoc2013/trademark/**25002<>

Thanks for the pointer.

On Fri, Jun 21, 2013 at 2:55 PM, Gottlob Frege <gottlobfrege_at_[hidden]>wrote:

> On Fri, Jun 21, 2013 at 12:35 PM, David Sankel <camior_at_[hidden]> wrote:
> > **Use 1**: Can be used as an alternative to exceptions or the (error
> > codes+set reference idiom):
> >
> >
> There was also talk of an 'expected' class for this case (where one of the
> 2 choices was the, well, expected one).
> I'm still hoping for that class. Although it may be syntactically the same
> as 'either', I appreciate its explicit intentions.
> I'm not sure if that makes 'either' less needed, and means variant +
> expected ( + optional, etc) is enough.

To summarize my understanding of how 'Boost.Expected' relates 'either':
They are semantically equivalent, but the former using naming conventions
and default values that imply one particular use case, the return error
condition one.

Maybe std::map should be using a specialized 'KeyValue' instead of
std::pair, but I personally think that in both map's case and in the error
returning case the types are simple enough that a convention would be

David Sankel

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