Boost logo

Boost :

Subject: Re: [boost] [variant] Please vote for behavior
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-02-01 20:51:15


On 1/30/2013 8:33 PM, Dave Abrahams wrote:
>
> on Tue Jan 29 2013, Paul Smith <pl.smith.mail-AT-gmail.com> wrote:
>
>> On Tue, Jan 29, 2013 at 7:25 PM, Jeffrey Lee Hellrung, Jr.
>> <jeffrey.hellrung_at_[hidden]> wrote:
>
>>> This discussion might be facilitated if Joel et al (sorry Joel, I don't
>>> mean to pick on you, I just mean the group arguing for introducing this
>>> "singular" post-move state) simply said "yes, we understand we're making a
>>> breaking change (by possibly introducing an additional state to variant
>>> that violates the never-empty guarantee), but we still think it's the most
>>> practical approach to introduce efficient move semantics to variant". I can
>>> jive with that but I think Paul's concerned that you (again, as a
>>> representative of the platform you're taking) don't appreciate that this is
>>> a breaking change to variant.
>>
>> I think this is about a little more than that, even though to be
>> honest, I'm not entirely sure what's the dispute is about too.
>> I think it's closer to what Edward Diener said:
>>
>> The main issue seems to be simply this: are guarantees ( invariants )
>> for an object of a class meant to cover moved from objects of that
>> class?
>
> I don't think that question should really even be on the table. If
> "invariant" and "guarantee" are to have any useful meaning, the answer
> must be "yes."

I agree with you but that means to me that for a class to be movable an
invariant for that class can never be that the class cannot be empty.
It seems to me that the Variant class does have an invariant which says
that the class can never be empty. So my conclusion is that a Variant
can not be movable.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk