Re: [boost] [variant2] Need rationale for never-empty guarantee

Subject: Re: [boost] [variant2] Need rationale for never-empty guarantee
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-03-04 09:53:13

>> If it's going to do weirdness like setting state C out of the blue, then
>> better dispose entirely any double buffered implementation as not adding
>> value.
> 
> While I agree that switching to an apparently unrelated state is
> surprising, it could be anticipated and "solved" by always using
> monostate as the first type where the types might throw on move.  (And
> perhaps variant could issue a warning or error if you try to do otherwise?)

I'd much prefer that the code not compile instead of unrelated states
magically appearing in corner case situations.

Let the user add in monostate to the list of state options if they'd
like to explicitly opt into monostate, and only monostate, magically
appearing if there is no alternative in the single buffer variant
implementation only.

Niall