Re: [boost] Error handling libraries and proposals

Subject: Re: [boost] Error handling libraries and proposals
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-07-10 21:06:56

On Mon, Jul 10, 2017 at 1:36 PM, Niall Douglas via Boost <
boost_at_[hidden]> wrote:

> outcome<void, void> would equal outcome<void, void, std::exception_ptr>.
>
> 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<void,exception_ptr>? What are the semantic differences
between e.g. expected<int,exception_ptr> and outcome<int,void>?

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