Re: [boost] [variant2] documentation request

Subject: Re: [boost] [variant2] documentation request
From: Gavin Lambert (boost_at_[hidden])
Date: 2019-03-04 05:28:27

On 4/03/2019 10:43, Peter Dimov wrote:
> Niall Douglas wrote:
> 
>> This is why I would suggest variant2 provide elemental 
>> single_buffer_variant and double_buffer_variant, and let the end user 
>> choose which they want.
> 
> variant2 presently is single_buffer_variant except that instead of 
> giving you an error when that's not possible, it silently switches to 
> double_buffer_variant and soldiers on. (Which happens rarely.)

I dislike in general silent implementation switches that can have 
performance consequences that can be triggered by a typo or a forgetful 
lack of "noexcept" modifier.

> I agree that one can make a good argument for (a variation of) 
> double_buffer_variant, which prioritizes strong guarantee over sizeof. 
> But that's only needed when your contained types don't have noexcept 
> move. In this case, a not unreasonable course of action is to hold them 
> by unique_ptr in the variant instead.

How hard would it be to publicly provide single_buffer_variant, 
double_buffer_variant, and variant (where the latter is just an 
intelligent alias to one of the other two based on the argument types, 
as per your current rules)?

That would let consumers who care explicitly indicate that they don't 
want double-buffering -- and then get a compile error if they 
inadvertently put an incorrect type in, rather than getting unintended 
buffering.

(I'm less sure if there's a use case for explicitly wanting 
double-buffering always, but it seems easier to provide it than not to, 
if you have to write a double-buffered version anyway.)

But the alias means that consumers who don't care, don't have to.