In contrast, Boost.Outcome is intended for usage in these rare cases were "forward up and abort" is not the thing you would like to do most of the time. Its goal is not to handle failures anywhere, but to solve a specific problem in specific places. I believe that the criticism of Boost.Outcome should be in this context of places where "forward up and abort" is not what you typically need to do.
And this really drives to heart of what I don't get about your arguments Emil. Outcome is really an abstraction layer for setting per-namespace rules for when to throw exceptions. Exception throwing is absolutely at the heart of Outcome. That's why Outcome != Expected, and why it ICEs older compilers, and why C++ 14 is needed. Let me give you an example literally from what I was doing last night. I just this week finally persuaded OS X to compile AFIO, and amazingly the test suite passed as well as on Linux except for the async i/o test which was failing.
From the build log on Travis, I could immediately see that the cause was a "resource temporarily unavailable" failure. An `io_result<>` was being constructed with that failure, returned to the i/o completion handler which in turn type erased it into an exception_ptr, put that into the future for the completion handler, and finally at the end of the test all accumulated failures were rethrown out out the futures for all the async i/o.
Outcome behaved exactly as AFIO told it to behave: expected errors were handled locally with an unmeasurably low overhead, unexpected errors were type erased into an exception_ptr and pushed up the call stack. Eventually after a fair bit of head scratching I discovered that OS X's implementation of `aio_select()` does not do what its man page says it does, so last night I committed a workaround and now async i/o works on OS X, so -3 failures at https://my.cdash.org/index.php?project=Boost.AFIO&date=2018-02-01 yay! The point I'm making here is that exception throws are what Outcome does. You're basically arguing against the premise of this library on ideological grounds, yet the library is fulfilling all of the rationales you have made on why exception throws are the right approach. Outcome is ticking all your boxes. Outcome is all about throwing exceptions. Will you consider now changing your peer review vote? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/