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.