2018-02-05 3:16 GMT+01:00 charleyb123 . via Boost
# Boost.Outcome.v2 REVIEW REPORT
In conclusion to the review for Boost.Outcome(v2) (19-Jan to 28-Jan, 2018): The library is ACCEPTED (conditions below).
Wow. Congratulations Niall for getting Outcome accepted into Boost. But at this point I would really like to congratulate Charley on managing the review and coming with the verdict. It is my perception that this review was particularly hard and controversial. One can learn a lot only from reading the justification of the verdict. The beclouded discussion appeared at times to exhibit violent agreement:
However it looks like Outcome provides a solution for most of the
Quoting reviewer (voting to reject): practical
cases, while leaving the general case unsolved. Boost.Outcome is a set of tools (rather than just one) and you are expected to choose one that best solves your particular problem.
Quoting response by library author:
I was just about to say the same thing, but more pointed. <...> Knowing that a piece of code will never, ever see stack unwinding lets you skip handling stack unwinding. Hence `noexcept`.
Furthermore, unlike with exception specifications which were unhelpfully checked at runtime, Outcome fails at compile time. .... You can't successfully compile code if your E types don't have interop specified for them.
Outcome is of particular use in a lower-level layer of code (closer to bare metal, or in server contexts), where explicit deterministic error handling warrants increased tedium or inconvenience in explicit checks for success/failure.
I would like to clarify one thing. In the quoted discussion above it was actually me talking to Niall, and I voted to conditionally accept the library. It does not change the conclusion though, as indeed there were points in the discussion where those voting to reject did agree on the scope and limitations of the library. Regards, &rzej;