On 06/24/13 06:20, Pierre T. wrote:> Hello [snip]
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: http://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/trade... says: 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”). from: http://book.realworldhaskell.org/read/error-handling.html Based on a brief look at: http://www.boost.org/doc/libs/1_53_0/libs/optional/doc/html/boost_optional/d... 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 above. Hence, I don't see any fundamental difference between Either and Expected. What am I missing? [snip]
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? [snip] -regards, Larry