Re: [boost] Error handling libraries and proposals

Thank you for letting me know that the Outcome design has changed, again. :)

It's only changed as per peer review feedback. If you trawl all 800+ emails and drag out a consensus view of the community, you end up with highly inoffensive Outcome v2. Well, apart from copying std::variant's constructor design, that's on me, but I think cloning the C++ standard is an okay design choice.

For example, outcome is legal, though unusable.

What would be the meaning of outcome?

outcome would equal outcome. Such an object can store a void or an exception_ptr. Or rather, have the state of a void or an exception_ptr.

, but for Outcome v2 the new values are:

yes, yes, yes, yes, no, yes, yes, yes.

To me, your note that Outcome is struct-like rather than variant-like means that it does not have strict value-or-error semantics, so the last one would be "no".

Unless you enable the positive status support manually, a strict enforcement of value or error is made. There is no longer an empty state, so you literally must choose either valued, or errored. Anything else won't compile.

Also, could you expand on how Outcome can propagate errors from a C-style callback or across language boundaries? I'm referring to use cases like these: https://zajo.github.io/boost-noexcept/#example_lua

I specifically personally need result to be C layout compatible so AFIO can have C SWIG bindings. Outcome v1 was C layout compatible too, but v2 is even more so because it's just a struct of the form: struct { T value; unsigned flags; EC error; }; ... and bit 0 of the unsigned means a T is present, and bit 2 means an EC is present. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/