Re: [boost] [variant2] documentation request

Subject: Re: [boost] [variant2] documentation request
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-03-05 08:26:11

> 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<T, E> a template alias to a preconfigured mix of those internals.
I didn't like the idea at the time one bit. But after I did the
substantial refactor, and deployed it into production, it's grown on me.
To the extent that I now recognise that I was wrong, and you guys were
right. And I'm wondering the same about variant2)

Niall