Re: [boost] [variant] Please vote for behavior

Subject: Re: [boost] [variant] Please vote for behavior
From: Paul Smith (pl.smith.mail_at_[hidden])
Date: 2013-01-30 10:48:30

On Wed, Jan 30, 2013 at 1:40 AM, Joel de Guzman <djowel_at_[hidden]> wrote:
> On 1/30/13 5:00 AM, Paul Smith wrote:
>>
>> On Tue, Jan 29, 2013 at 7:25 PM, Jeffrey Lee Hellrung, Jr.
>
>
>>> 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 ?
>>
>>    All of the choices which you have specified, which popularly boils down
>>    to II or III, involves this question. The choice of II answers No to
>> the
>>    question above while the choice of III answers Yes to the question
>> above.
>>
>> As absurd as it may sound right now, I think Joel's and mine opinions
>> are much closer than it seems. I like performance too, believe it or
>> not. And it's not just about performance, under non-destructive move
>> semantics there's an entire class of objects which is neither copyable
>> nor movable, and it becomes harder to give no-throw guarantees. I
>> definitely *do* want to be able to move recursive_wrapper by nulling
>> it's pointer. I think what we disagree on is how to get there :-)
>
>
> Ok, let's just agree to disagree then and leave it at that.

Listen, Joel, I'll say this once more - I'm not trying to annoy you.
This discussion isn't about you or me, it's about variant, and it also
seems to be about move semantics in general. I agree to disagree with
you, but I still want to understand the view you represent for my own
sake, whoever cares to explain it to me.

What the language semantics are designed for, what the standard
library guarantees and effectively requires, and what the committee
seem to advocate for, are conservative move-semantics - ones that
require that a moved-from object maintains its invariants (in the case
of the library - its requirements). On the other hand we have
destructive move-semantics, for the sake of this discussion let's
define them as the ones that merely require the moved-from object to
remain destructible and assignable. If this is where I'm wrong - I'd
love to be shown otherwise, either by giving me a standard citation or
a reference to a WG paper that shows it, or by addressing the ones I
gave and explaining to me what did I misinterpret.

Currently, recursive_wrapper has the fact that it always holds a value
as an invariant, or equivalently in the context of variant, variant
has a never-empty guarantee and a variant that contains a
recursive_wrapper<T> behaves as if it contained a T.

Now we have a problem, because nulling recursive_wrapper's pointer,
even though it does the trick for destructive move-semantics, breaks
these invariants. This problem is in fact not uqniue to variant or
recursive_wrapper specifically.

If our universal solution to this problem is going to be to introduce
an artifical post-move state and have it as an anti-precondition to
anything but assignemnt and destruction, then what's the point in
having conservative move-semantics in the first place? Destructive
move-semantics is what we end up with in practice. We'd be much better
off by saying that moved-from objects can break their usual invariants
than by having to weaken those invariants.

This is my break-down of the situtation. If anyone disagrees with any
of this - I'd love to hear why.

--
Paul Smith