Re: [boost] [variant2] documentation request

AMDG On 3/4/19 5:44 PM, Peter Dimov via Boost wrote:

Niall Douglas wrote:

...

You seem very wedded to not breaking out single_buffer_variant and double_buffer_variant Peter. You seem keen we should accept your preferred mix of when each ought to be employed using your hardcoded logic. Can I ask why?

I don't have a good answer to this question. Breaking out into two separate classes per number of buffers seems sensible and straightforward, and I don't have any waterproof arguments against it apart from the fact that I intuitively dislike it.

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." double_buffered_variant, really means "give me strong exception safety. I don't care about the cost." Exposing single_buffered_variant and double_buffered_variant effectively rules out other possible compromises. 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 prefer having a single variant, named "variant", which is almost always a drop-in replacement for std::variant, for the fairly obvious reason that (a) it's easy to recommend to users: just use variant2::variant instead of std::variant, and your problems will be gone (not valid in all jurisdictions) and (b) it would be possible, in theory, to one day replace std::variant with it.

For people who'd rather have single_buffer_variant, I can provide a static constexpr member function `bool variant::is_single_buffered()`, which they can static_assert. So

template using single_buffer_variant =    mp_if_c::is_single_buffered(), variant>;

To those who'd rather have double_buffer_variant, though, I don't have a good offer.

In Christ, Steven Watanabe