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