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-31 10:31:02

On Thu, Jan 31, 2013 at 3:22 AM, Dave Abrahams <dave_at_[hidden]> wrote:
>
> on Mon Jan 28 2013, Paul Smith <pl.smith.mail-AT-gmail.com> wrote:
>
>> This issue has been discussed more than once before, and nothing I say
>> here is my own opinion, so please don't take it out on me.
>> For example, see N3264 (CH-18 and US-85: Clarifying the state of
>> moved-from objects (Revision 1)):
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3264.htm
>>
>>> and Dave confirms that,
>>
>> I don't want to read into what Dave said too much, because he's here
>> and he can clarify it. But I believe what he said is that specific
>> algorithms, in their own localized context, practically only require
>> destructibility and assignability. And even then, it's not something
>> the standard actually guarantees in general, though, and the
>> requirements are still much stricter, perhaps superfluously so. That's
>> frustrating, no doubt about it, and it's a good selling point for
>> having destructive move semantics - not for breaking the rules.
>
> That doesn't sound like anything I meant to say, but I do agree fully
> with the resolutions (if not the NB comments) in the paper cited above.

Then what did you mean? I was responding to Joel's claim:

> The standard only mentions assign and destroy as necessary,
> and Dave confirms that

He refers to you answer:

>> (The) ability to both assign and destroy? Is that all that it needs?
> That's all the standard library will use.

But the library's requirement from moved-from user-types, as of this
paper's resolution, is stricter. In [moveconstructible]:

  rv’s state is unspecified [ Note:rv 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. —end note ]

Nowhere does it say anything about just being destructible and assignable.

Btw, the reason why I brought up this paper was because I couldn't
help noticing the similarity between the case mentioned there and what
we have here. The US NB was requesting that the standard would require
standard-library types (or maybe types in general) only to be
destructible and assignable after a move. The case they mentioned was
containers that allocate their sentinel nodes dynamically. If the
container has to remain valid after a move, the move constructor has
to allocate sentinel nodes "for nothing".

The resolution was, AFAICT: No. Moved-from library types should remain
valid. If dynamically allocated sentinel nodes are your implementation
strategy, you have to bite the bullet (Which is, btw, what the
Microsoft implementation actually does, at least as of MSVC 10. Could
someone please check if they changed it in 11? Run the attached file,
you should see two allocations).

The resolution wasn't "let's say that moved-from types should only
remain destructible and assignable", and it wasn't "let's add a
singular value to std::list". Ofcourse, boost isn't the standard
library and you're not bound by any of this. Still, it's awkward to
have the standard pull in one direction and boost pull in the other
one.

--
Paul Smith