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