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.