On Fri, Feb 1, 2013 at 5:51 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
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@gmail.com> 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 sometimes). - Jeff