Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at