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

On Sat, Jun 22, 2013 at 2:07 AM, Bjorn Reese wrote:

You may want to check the GSoC 2013 proposal for Boost.Expected:

http://google-melange.appspot.**com/gsoc/proposal/review/** google/gsoc2013/trademark/**25002http://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/trade... http://github.com/**TrademarkPewPew/Boost.Expectedhttp://github.com/TrademarkPewPew/Boost.Expected

Thanks for the pointer. On Fri, Jun 21, 2013 at 2:55 PM, Gottlob Frege wrote:

On Fri, Jun 21, 2013 at 12:35 PM, David Sankel 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