Rationale:

The issue(s) at hand not adequately communicated.

[ 2009-10 post-Santa Cruz: ]

Tentatively NAD. We are not sure what has been addressed and what hasn't. Recommend closing unless someone sorts this out into something more readable.

[ Batavia (2009-05): ]

Move to Open, pending proposed wording from Dave for further review.

Notes

[2009-03-21 Sat] p. 535 at the top we need MoveConstructible V1, MoveConstructible V2 (where V1,V2 are defined on 539). Also make_tuple on 550

CD-1 reads:

template <MoveConstructible T1, MoveConstructible T2> 
pair<V1, V2> make_pair(T1&&, T2&&); 

Actually I'm guessing we need something like MoveConstructible<V1,T1>, i.e. "V1 can be constructed from an rvalue of type T1."

Ditto for make_tuple

[2009-03-21 Sat] p1183 thread ctor, and in general, we need a way to talk about "copiable from generalized rvalue ref argument" for cases where we're going to forward and copy.

This issue may well be quite large. Language in para 4 about "if an lvalue" is wrong because types aren't expressions.

Maybe we should define the term "move" so we can just say in the effects, "f is moved into the newly-created thread" or something, and agree (and ideally document) that saying "f is moved" implies

F x(move(f))

is required to work. That would cover both ctors at once.

p1199, call_once has all the same issues.

[2009-03-21 Sat] p869 InputIterator pointer type should not be required to be convertible to const value_type*, rather it needs to have a operator-> of its own that can be used for the value type.

This one is serious and unrelated to the move issue.

[2009-03-21 Sat] p818 stack has the same problem with default ctor.

[2009-03-21 Sat] p816 priority_queue has the same sorts of problems as queue, only more so

   requires MoveConstructible<Cont> 
     explicit priority_queue(const Compare& x = Compare(), Cont&& = Cont()); 

Don't require MoveConstructible when default constructing Cont. Also missing semantics for move ctor.

[2009-03-21 Sat] Why are Allocators required to be CopyConstructible as opposed to MoveConstructible?

[2009-03-21 Sat] p813 queue needs a separate default ctor (Cont needn't be MoveConstructible). No documented semantics for move c'tor. Or *any* of its 7 ctors!

[2009-03-21 Sat] std::array should have constructors for C++0x, consequently must consider move construction.

2009-05-01 Daniel adds:

This could be done as part of 1035, which already handles deviation of std::array from container tables.

[2009-03-21 Sat] p622 all messed up.

para 8 "implementation-defined" is the wrong term; should be "see below" or something.

para 12 "will be selected" doesn't make any sense because we're not talking about actual arg types.

paras 9-13 need to be totally rewritten for concepts.

[2009-03-21 Sat] Null pointer comparisons (p587) have all become unconstrained. Need to fix that

[2009-03-21 Sat] mem_fun_t etc. definition doesn't match declaration. We think CopyConstructible is the right reqt.

make_pair needs Constructible<V1, T1&&> requirements!

make_tuple needs something similar

tuple bug in synopsis:

   template <class... UTypes>
   requires Constructible<Types, const UTypes&>...
   template <class... UTypes>
   requires Constructible<Types, RvalueOf<UTypes>::type>...

Note: removal of MoveConstructible requirements in std::function makes these routines unconstrained!

2009-05-02 Daniel adds:

This part of the issue is already covered by 1077.

these unique_ptr constructors are broken [ I think this is covered in "p622 all messed up" ]

 unique_ptr(pointer p, implementation-defined d);
 unique_ptr(pointer p, implementation-defined d);

multimap range constructor should not have MoveConstructible<value_type> requirement.

same with insert(..., P&&); multiset has the same issue, as do unordered_multiset and unordered_multimap. Review these!