If all Outcome did was transport values, error_code and exception_ptr, I'd support it.
Last review it was widely agreed that being able to transport arbitrary payload with error_code was a desirable thing. I appreciate that you're not the whole community Emil, but that's the feedback I was given last review, and this library implements what the community asked for last time we were here.
exception_ptr _is_ arbitrary payload.
exception_ptr type erases and calls malloc. Its use cannot be elided by the compiler, due to the use of atomics. The `trait::has_error_code_v<E>` mechanism lets you return arbitrary payload without those overhead, but at the cost of extra brittleness introduced into the type system. One can, at any time, further up the call stack do the type erasure then, and regain flexibility by removing from the type returned returned the arbitrary payload. I do this myself in my own code: as a stack unwinds, make type erased the unwind by throwing a custom exception type containing type erased arbitrary payload. All this sounds complex I am sure. But in practice when writing the code it all follows naturally, and the code is clear regarding its intent and purpose. It just is probably a bit new to some folk, that's all. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/