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
> 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:
... and bit 0 of the unsigned means a T is present, and bit 2 means an
EC is present.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk