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.

### 1099. Various issues

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: