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
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