Re: [boost] Outcome v2

Subject: Re: [boost] Outcome v2
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-07-13 10:12:53

>> A majority of peer review feedback didn't see the need for variant
>> storage. Eliminating it very significantly reduces the complexity of the
>> implementation, it's a big gain. I was able to SFINAE all the
>> constructors because of the compile time budget released by eliminating
>> the variant storage.
> 
> If you're going to maintain strict no-value-plus-error semantics then
> union/variant storage makes sense, as otherwise you're wasting memory.
> I'm not sure why this would increase complexity.

I did some benchmarking before making the change to non-variant storage,
and found a worst case performance loss of 3-6% depending on compiler.
And by worst case, I mean where we do nothing other than return
outcomes, and it's 3 CPU cycle hit over ten outcomes returned. I think
we'll live.

I also did some benchmarking of a std::variant based toy outcome v2 and
found compile times to be unacceptably high. The present v2 outcome
requires about 4 seconds minimum per compiland, most of which stems from
<type_traits> which is unavoidable. std::variant was adding 2 seconds to
that, so up to a 50% compile time increase just for naive usage.

Just because we don't store strict value-or-error doesn't mean we can't
pretend we do in the API. And it eliminates so much special casing for
achieving never-empty guarantees etc, it's a lot less work for the
compiler and me the developer.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/