Re: [boost] [outcome] Change semantics on UB from peer review agreed semantics?

Subject: Re: [boost] [outcome] Change semantics on UB from peer review agreed semantics?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-09-13 16:34:46

>> Me personally I almost exclusively use Outcome in P1028 SG14
>> `status_code` mode now. Far superior codegen.
> 
> Out of curiosity, what does this mean?

Outcome + error_code requires injection of payload and custom member
functions via Outcome.

Outcome + status_code requires no injection, as the status_code is
configured with payload directly, and gains its custom member functions
via mixins.

I cannot say if that is the cause (less complexity facing the compiler),
or whether the all-constexpr nature of status_code is more important,
but if you look at the assembler generated by the former, it is markedly
inferior to assembler generated by the latter, on VS2017 at least.

I keep meaning to get around to doing a proper benchmark, but
subjectively I'd estimate there's a 1-2% gain for status_code for the
workloads LLFIO performs in its unit tests on Windows.

After this work contract ends and I redo the docs for Outcome for entry
into Boost, I'll redo the benchmark, and see if I'm right and if so by
how much. Do bear in mind status_code only stabilised in July, but I'm
already much preferring it over error_code. It's just much cleaner to
work with. Advantage of a clean room design.

Niall