Outcome v2 appears to have chosen a different path, where you mostly still use unadorned std::error_code (although since it's templated it's possible you could still do the above) but you also get an extra arbitrary payload pointer *or* an exception_ptr (where then presumably your extra payload is carried in a particular exception subclass). I'm still a bit on the fence about that latter option; exception_ptrs are a bit of a pain to extract useful information from. Or perhaps I'm just misinterpreting something; the docs are still incomplete after all.
You can hook the conversion from result<T, EC1> to result<T, EC2> or outcome<T, EC1, P> via ADL function injection. So v2 doesn't say anything about what the best way of sending payload with your error_code is. In AFIO v2, which I am converting over to Outcome v2 during the next few weeks, I am intending that the code closest to the syscall returns: `result<T, afio_error_code_ref>` ... where `afio_error_code_ref` is *potential* error_code + context. The idea is that we don't waste time copy constructing the path at fault unless asked for. However, `afio_error_code_ref` is non-copyable and non-moveable to prevent it outliving the object it refers to, so anything consuming a `result<T, afio_error_code_ref>` but returns a `result<T, std::error_code>` will dump the context, if returning an `outcome<T, std::error_code, afio_error_code>` it'll do the copy construction then, if an exception is thrown from it then the exception is constructed with the payload embedded and so on. Outcome v2 says nothing about any of this stuff. Up to the end user to customize. As I've mentioned before, you could use TLS to store the extra context too. Up to the end user. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/