Re: [boost] Error handling libraries and proposals

On Mon, Jul 10, 2017 at 1:36 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:

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.

So, if I understand correctly, the second void means exception_ptr? Why isn't it outcome? What are the semantic differences between e.g. expected and outcome?

...

, 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.

Ah, so this means that it is optional, like in Noexcept. I'll reflect that in the comparison table.

...

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.

It seems that here you are making the case I've been making, that in general std::error_code is not sufficient, that an error-handling library must be able to propagate errors of user-defined types, and not only through an exception_ptr. I also think it is a good idea to be C-compatible, but from the above it isn't clear to me how that works. Could you please post a complete example, specifically how can outcome<T> propagate errors from a C (not C++) API? That said, if you look at the example I linked, you'll see that it is about more than just being C-layout compatible, but also being able to propagate an error from a third-party C-style callback which does not return your struct. In case I'm missing something, could you post the outcome<T> version of the example I linked?