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?