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

Subject: Re: [boost] [variant2] Need rationale for never-empty guarantee
From: Robert Ramey (ramey_at_[hidden])
Date: 2019-03-01 17:27:12

On 3/1/19 9:13 AM, Ivan Matek via Boost wrote:
> On Fri, Mar 1, 2019 at 5:50 PM Robert Ramey via Boost <boost_at_[hidden]>
> wrote:
> 
>> C++ starts from the idea that every instance should be mutable and hence
>> gives you an assignment operator by default.  The design discussions
>> around variant (expected, outcome, ...) presume that this operation must
>> be implemented.  I question this.  Not only for variant, but for many
>> other C++ data types.
>>
>> Robert Ramey
>>
>   It is part history, 

I'd say it's all history.

> part performance, for example your immutable integers
> work fine and fast, 

> but if you had immutable strings and pushback was O(n)
> or string was no longer an array that would be problematic.

This is interesting.  For my extended integer case it wasn't apparent to 
me the assignability was a problem.  I eventually came around the idea 
that it was easier and better to tweak my code not to require assignment 
than to permit assignment in the "variable" type.

So as an exercise, you might experiment with your own use case regarding 
strings.  I don't claim that variant with assignment is not 
useful/necessary.  I'm really suggesting that perhaps might be 
interesting to consider a variant of variant (const variant?)  which 
didn't assignment.  The only problem with this is that implementation is 
so trivial that perhaps a library is not appropriate other than as a 
tool to motivate people to think about how they are using the variant in 
the first place.

Robert Ramey