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

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]>
 wrote:

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

>

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
sufficient.

David Sankel