I know why I dislike it. It exposes low level details of the implementation which most users should neither know nor care about. If someone asks for a single buffered variant, what he really means, is "I really care about performance. Give me a hard error instead of using more space."
Not quite. It means "I understand and want the tradeoffs that using a single buffer (and no dynamic allocation) requires".
double_buffered_variant, really means "give me strong exception safety. I don't care about the cost."
Not quite. It means "I don't trust that somebody won't mess up this variant during code maintenance in the next decade".
Exposing single_buffered_variant and double_buffered_variant effectively rules out other possible compromises.
I think that shows a lack of imagination. For example, why can't double_buffered_variant be constructed by gluing two single_buffered_variants together internally, and wrapping the glue with logic to switch between them in an exception safe fashion? If that's not possible, it smells to me like that's a design issue which needs fixing. Elementary components ought to be composable. I don't claim that this is easy to get right, but I do claim it is worth thinking about. All that said, you do raise a very valid point important to what is becoming a fairly comprehensive design review discussion already. What is lost by taking a "composition of elementals" design approach?
For
example, if all the types without no-throw move are smaller than the largest type in the variant, then you can save space with a partially double buffered variant.
I'd consider that sort of argument as important if variant2 implements
or would implement that kind of optimisation.
If variant2 doesn't implement that kind of optimisation, and won't, it
holds much less weight with me.
i.e. Peter what specific gains do you see as important that you want to
retain a single variant implementation with hardcoded selection logic?
(I might remind Boost now of Outcome. As presented, it had a hardcoded
logic selecting between configurations. You guys persuaded me to break
out the internal implementations, expose them to the user, and make
result