Re: [boost] Variant2 review

Subject: Re: [boost] Variant2 review
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-04-08 23:29:29

>> Coming back to my point, there really isn't anything wrong with a
>> variant which defines its size to be twice that of its largest
>> alternative state. If it is *documented* to be so.
> 
> Well, the size of the variant is wrong: we know how to implement the
> variant that occupies half of this double storage. It is inefficient in
> terms of space consumption. The fact that this inefficiency is documented
> does not change the fact that it is inefficient.> [snip]
> With this advice what I get is: either a space-efficient type or a compiler
> error. This is inferior to solution where I get a space-efficient type
> always.

I do not currently believe that it is possible to make an alternative to
std::variant, which is worth the difference to std::variant, which is
not mostly double-buffered.

Or, put another way, I think the primary failing in the design of
std::variant is its lack of default-to-double-buffering. Single
buffering ought to be an optimisation. Double buffering ought to be the
default, with all the many benefits that that design choice brings.

(Don't get me wrong, my opinion is this for a union-storage variant
only. I personally think an upper bound of 2x sizeof is an excellent
tradeoff for all the benefits double buffering brings. I am highly
unconvinced that anything less than an upper bound of 2x sizeof is worth
the very substantial tradeoffs in terms of corner case surprise. I
*personally* think anything else is an over-eager optimisation on any
out-of-order CPU made in the past decade)

Niall