This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
Section: 16 [library] Status: NAD Submitter: David Abrahams Opened: 2009-03-21 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [library].
View all other issues in [library].
View all issues with NAD status.
Discussion:
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!
[ Batavia (2009-05): ]
Move to Open, pending proposed wording from Dave for further review.
[ 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.
Rationale:
The issue(s) at hand not adequately communicated.
Proposed resolution: