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-02-01 12:56:55

On Fri, Feb 1, 2013 at 7:15 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>
> on Fri Feb 01 2013, Paul Smith <pl.smith.mail-AT-gmail.com> wrote:
>>
>> Okay, I'm truely confused about what you're saying then.
>>
>> Either the standard library requires moved-from user-types to keep
>> meeting all their requirements, or it only requires them to remain
>> destructible and assignable.
>
> Not knowing if there's specific text about this, I can't say for sure.
> If, as I think is likely, what it requires of them is not explicitly
> called out, then it is implied by other requirements.  In other words,
> the library has the freedom to perform any operations on such objects as
> it may perform on any other object in the same context.  For example, in
> a call to sort(first, last), it is free to compare two objects in the
> range [first,last) even if one or both of them has been moved-from, so
> the objects passed to such a call must, technically, preserve
> less-than-comparability of moved-from objects.
>
> In practice, though, IIUC implementations will only actually use
> assignment and destruction on moved-from objects.

This was my understanding.

>
>> The standard says the former.
>
> If you say so.

Table 20, [moveconstructible]:

  rv (the moved-from object) must still meet the requirements of
  the library component that is using it. The operations listed in
  those requirements must work as specified whether rv has
  been moved from or not.

How else should I read it? When I say that "this is what the library
requires" I mean exactly that - what it technically requires, not what
it will or will not use in practice.

>
>> The wording that appears in the standard is the same (or almost the
>> same) wording as the resolution of N3264, which is what you say you
>> fought for.
>
> OK.
>
>> The only other way I can interpret "That's (destructibility and
>> assignability) all that srandard library will use" is "that's all it
>> will use in practice", but you say you disavow that.
>
> No, I only disavow these parts of what you attributed to me:
>
> "it's not something the standard actually guarantees in general, though,
> and the requirements are still much stricter, perhaps superfluously
> so.

I'm not sure what you're disavowing then. You don't say that the
standard guarantees that destructibility and assignability are enough,
but you do say that this is all it will need in practice. That's
called superfluous in my book. I'm not saying that it's a good thing
or a bad thing.

> ... it's a good selling point for having destructive move semantics."
>
>> So, please, could you rephrase this sentence in a more elaborate way?
>
> HTH,

Indeed! And sorry for nagging.

--
Paul Smith