Subject: Re: [boost] Interest in an 'either' library?
From: Larry Evans (cppljevans_at_[hidden])
Date: 2013-06-24 08:49:04
On 06/24/13 06:20, Pierre T. wrote:> Hello
> I think there is some misunderstanding and confusion between
> Expected/Optional/Either. Indeed, I'm quite sure that Expected and
> Either are completely different. Even if Expected seems to be a subset
> of Either, because you can choose to return a (value,
> exception/error) couple in Either, the behavior will be different. IMHO,
> Expected is more useful because it adds a lot of semantics for this
Could you please highlight what the semantics are which distinguish
Either from Expected?
> particular use-case.
> I'd say that if Expected is the brother of Optional, Either is the child
> of Variant (because it's a subset without adding specific semantic).
The gsoc2013 Expected page:
expected< T,Error > proposed here is a type that contains a type T or
a type Error in its storage space.
which sounds a lot like the OP passage:
**Use 1**: Can be used as an alternative to exceptions or the (error
codes+set reference idiom):
and a lot like:
The Either type is similar to the Maybe type, with one key
difference: it can carry attached data both for an error and a
success (the Right answer).
Based on a brief look at:
Boost.Optional is like haskell's Maybe<T>(either a T value or
Nothing). The Nothing in haskell's Maybe is like the none_t
mentioned on the boost_optional/detailed_semantics.html page mentioned
Hence, I don't see any fundamental difference between Either and Expected.
What am I missing?
> Finally, the first argument of this Either library was the error/value
> couple facilities, but now we know that Expected is quite better,
Could you explain exactly how Expected is better?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk