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:
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk