Re: [boost] Boost.Outcome review - First questions

Subject: Re: [boost] Boost.Outcome review - First questions
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-21 22:45:23

Niall Douglas wrote:

> ... I just needed to unload the above, and I appreciate that the docs do 
> not sufficiently get into the universal error handling framework part of 
> Outcome. That is due to repeated Reddit feedback telling me that earlier 
> editions of the docs didn't make sense, and I needed to go much slower and 
> hold the hand, so you got the current tutorial which as you've already 
> observed, is too long as it is.

For what it's worth, I found the docs understandable and useful. (Although 
the reference is a bit unwieldy, for a number of reasons.) If you could drop 
the remaining mentions of the word "monad" and any of its derivatives, it'd 
be even better. :-)

Your first iteration was full of monad this and monad that, and embedded 
programmers who just want to return an error from a function are not very 
interested in monads.

Taking a step back to the part of the message I snipped, the problem with 
expected<T, E> that makes it not suitable as a universal error handling 
strategy is the single E. In the real world, obviously lib1 will use E1 and 
lib2 will use E2, and the class needs to acknowledge this eventuality. That 
is why in my opinion the correct expected<T, E...> takes a variable number 
of possible Es, such that you could have result<T> == expected<T, 
error_code>, outcome<T> == expected<T, error_code, exception_ptr>, and 
make_expected(T) can return expected<T> (without any Es, because there 
aren't any.)

I really need to write this thing down at some point before Work(tm) takes 
over and blows it away.