Boost logo

Boost :

Subject: Re: [boost] [variant] Please vote for behavior
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2013-02-01 21:32:06

On Fri, Feb 1, 2013 at 5:51 PM, Edward Diener <eldiener_at_[hidden]>wrote:

> On 1/30/2013 8:33 PM, Dave Abrahams wrote:
>> on Tue Jan 29 2013, Paul Smith <> 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.

Not true. First of all, the primary present issue is implementing move
semantics for a variant with recursive_wrapper. Non-recursive variants
aren't really a problem.

Second, specifically for recursive variants, if one of the underlying types
is default constructible (trivially, ideally!), then, again no issues (in
theory; such a solution isn't presently implemented). So we basically have
this very "narrow" case (recursive variant with no detectable
default-constructible types) which is the issue, and even then, we have a
solution (it's just, by all accounts, suboptimal, since it has to use new

- Jeff

Boost list run by bdawes at, gregod at, cpdaniel at, john at