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

Subject: Re: [boost] Interest in an 'either' library?
From: Pierre Talbot (ptalbot_at_[hidden])
Date: 2013-06-25 03:28:20

> 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<A,B>]] = A + B = [[expected<A,B>]] (I'm using
> ADT syntax here for the mathematical domain (see:
> http://cpp-next.com/archive/2010/07/algebraic-data-types/)).
>
> They are *syntactically* different in that different names were chosen.
>

Mathematically speaking, ok there are semantically equivalent, I got it 
now (BTW thanks for the link, I learned something).
>
> 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)
>
Indeed, the Expected class was firstly designed for error reporting. We 
can generalize it for an Either class but we lose some contexts that 
would have helped to simplify this reporting in C++. Maybe we can 
propose free functions over Either to handle this specific use case, but 
I don't know how well it will work.
>
>> 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
>