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 to result or
outcome 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`
... 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` but returns a `result` will dump the context, if returning an `outcome` 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/
