Re: [review][LEAF] Review of LEAF

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2020-06-01 14:19:23

On 01/06/2020 14:48, degski wrote:
> 
> On Mon, 1 Jun 2020 at 08:30, Niall Douglas via Boost-users
> <boost-users_at_[hidden] <mailto:boost-users_at_[hidden]>> wrote:
> 
>     The current formulation of lightweight exceptions before WG21 is
>     literally Experimental Outcome in language form. Same proposed error
>     object, std::error. It is currently expected that both value-based and
>     type-based exceptions would exist in future C++, in order to retain
>     backwards compatibility, as the semantics between the two are not
>     currently believed possible to be made exactly one-one.
> 
> 
> i am obviously oblivious to what 'is in front of', but knowing that now
> [what light weight exceptions entails], I concur with you. As I noted in
> that same post, I 'get' [in respect of LEAF] the use-case of a c-api
> error-handler (but there must be plenty of those, no?), but otherwise I
> don't see it. From my personal perspective, I would not hesitate one
> second to use Outcome now, instead of any other solution better, or
> worse, just because it is going to be in some shape or form, but very
> similar, in the future standard.

Just so nobody misinterprets anything, right now EWG is not keen on
proposed lightweight exceptions. Microsoft hopes to modify MSVC to
support an implementation in the near future, and that may change EWG's
opinion.

LEWG is keen, so far, on the library side of things i.e. std::error and
the wider status_code machinery. We recently ported a large codebase at
work from <system_error> to status_code. It took about a day, and the
status_code edition is considerably more flexible and useful (mainly
thanks to that custom payload feature, and strongly typed code objects).
The ability to quickly wrap custom enums into custom status code domains
is a nice timesaver too. I should stress though that status_code
natively recognises std::error_code, it automatically wraps any custom
std::error_category into a synthesised custom status_code_code, so you
can totally mix the two in the same codebase, and it'll all "just work".

Current committee direction is that C++ 23 should get std::error and a
implementation of Outcome's result<T> as std::result<T>, with E
hardwired to any type deriving from std::error. This isn't as good as
lightweight exceptions, but if EWG changes its mind, the library side of
things is ready to go. And obviously everything I just said could change
next meeting.

Niall