Re: [boost] [review] Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-17 21:38:44

Le 16/05/2017 à 00:22, Peter Dimov via Boost a écrit :
> Niall Douglas wrote:
>
>> Vicente, when he reviewed Outcome's docs, was pretty appalled at how 
>> error handling focused they are. His view is that Expected is an 
>> EITHER monad where E is exactly like T, and he was not happy that 
>> Outcome presents Expected as if it is solely for use for returning 
>> stuff from functions.
No I have never said that E is like T.
>>
>> And, he is right.
>
> No, he isn't. The whole point of expected<> is that T is not like E. 
> That's why T is _expected_, and E is _unexpected_. It's in the name.
>
> When T is like E, you use variant<T, E>. Or variant<E, T>.
>
> My own idea of expected<T, E...> takes one T and an arbitrary amount 
> of Es, and while all Es are alike, T isn't.
>
> And this aside, the general idea is to provide alternative to 
> exceptions, which kind of implies returning stuff from functions, does 
> it not?
I agree completly.

expected<T, E...> is IMO the same as expected<T, variant<E...>> except 
that it could add some syntactic sugar. I'll not be against a 
expected<T, E...>.

The way either E T is used in Haskell is exactly this one. Note that 
with TypeClasses a type as variant <T, E...> can be seen in a lot of 
different ways.

Vicente