Boost logo

Boost :

Subject: Re: [boost] [variant] Please vote for behavior
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-01-30 20:31:07

on Wed Jan 30 2013, Joel de Guzman <> wrote:

> On 1/30/13 1:25 AM, Jeffrey Lee Hellrung, Jr. wrote:
>> On Tue, Jan 29, 2013 at 7:12 AM, Paul Smith <pl.smith.mail_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.
> No, Jeff, that is wrong. We are not violating the semantics to variant.
> It's not about variant. It's about recursive_wrapper. I think people are
> confused with this. The variant's never-empty guarantee still holds.
> A variant holding a singular-valued recursive_wrapper is similar to
> a variant holding a singular valued iterator. The variant is not empty.

But Joel, IIUC a variant never actually, from the abstract interface
point-of-view, contains a recursive_wrapper anyway. Isn't the
recursive_wrapper just a detail required to make it possible for a
variant type to (logically) contain itself? A visitor never sees the
recursive_wrapper, for example, and the never-empty guarantee doesn't
says that the variant always contains one of the types it can logically

Dave Abrahams
BoostPro Computing                  Software Development        Training             Clang/LLVM/EDG Compilers  C++  Boost

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