Boost logo

Boost :

Subject: Re: [boost] Error handling libraries and proposals
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-07-10 20:36:26

> 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<void, void, void> is legal, though
> unusable.
> What would be the meaning of outcome<void,void>?

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.

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

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:

  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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at