On Mon, Jun 24, 2013 at 5:20 AM, Pierre T.
For example, compare the following definition,
optional< either< isbn_10, isbn_13 > > parse_isbn_string( std::string );
to the equivalent using the 'expected' wording,
optional< expected< isbn_10, isbn_13 > > parse_isbn_string( std::string );
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 particular use-case.
I think the misunderstanding is between the precise meanings of syntax and
semantics. The expected class and the either class are *semantically*
equivalent. That is, if we map them to their precise mathematical meanings,
they are the same. [[either
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).
I have no idea what you mean by 'brother' and 'child'. To correct the example above, it should be:
optional< either< isbn_10, isbn_13 > > parse_isbn_string( std::string );
OR
expected< either< isbn_10, isbn_13 > > parse_isbn_string( std::string );
Depending on the design of parse_isbn_string – if it says or not why the parsing failed.
Okay, I think you've made it clear that you'd like to limit the application of expected to a particular use case that isn't implied by the semantics, but only by the author's intention. This is a bad design strategy IMO. A good reusable library will be documented by its semantics primarily and provide use-cases to give the user hints of where it will be useful (but never limit the user by the author's necessarily limited foresight)
I think Either could be useful in case it's massively used to avoid the syntactic overhead of Variant.
Finally, the first argument of this Either library was the error/value couple facilities, but now we know that Expected is quite better, does Either is just syntactic sugar ? Or do you have other relevant use cases ?
I don't think it has been demonstrated that "expected is quite better". There are plenty of use cases for either because it is such a fundamental type. Here are just a few handy generic functions (using Haskell type syntax for conciseness): either :: (a -> c) -> (b -> c) -> Either a b -> c partitionEithers :: [Either a b] -> ([a], [b]) mapEither :: (a -> Either b c) -> IntMap a -> (IntMap b, IntMap c) lefts :: [Either a b] -> [a] rights :: [Either a b] -> [b] liftRight :: a -> Either a b liftLeft :: a -> Either b a David