This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.

### 753. Move constructor in draft

Section: 16.4.4.2 [utility.arg.requirements] Status: C++11 Submitter: Yechezkel Mett Opened: 2007-10-14 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [utility.arg.requirements].

View all issues with C++11 status.

Discussion:

The draft standard n2369 uses the term move constructor in a few places, but doesn't seem to define it.

`MoveConstructible` requirements are defined in Table 33 in 16.4.4.2 [utility.arg.requirements] as follows:

> `MoveConstructible` requirements
> expression | post-condition
> --- | ---
> `T t = rv` | `t` is equivalent to the value of `rv` before the construction
> [Note: There is no requirement on the value of `rv` after the construction. -- end note]

(where `rv` is a non-const rvalue of type `T`).

So I assume the move constructor is the constructor that would be used in filling the above requirement.

For `vector::reserve`, `vector::resize` and the `vector` modifiers given in 22.3.11.5 [vector.modifiers] we have

> Requires: If `value_type` has a move constructor, that constructor shall not throw any exceptions.

Firstly "If `value_type` has a move constructor" is superfluous; every type which can be put into a `vector` has a move constructor (a copy constructor is also a move constructor). Secondly it means that for any `value_type` which has a throwing copy constructor and no other move constructor these functions cannot be used -- which I think will come as a shock to people who have been using such types in `vector` until now!

I can see two ways to correct this. The simpler, which is presumably what was intended, is to say "If `value_type` has a move constructor and no copy constructor, the move constructor shall not throw any exceptions" or "If `value_type` has a move constructor which changes the value of its parameter,".

The other alternative is add to `MoveConstructible` the requirement that the expression does not throw. This would mean that not every type that satisfies the `CopyConstructible` requirements also satisfies the `MoveConstructible` requirements. It would mean changing requirements in various places in the draft to allow either `MoveConstructible` or `CopyConstructible`, but I think the result would be clearer and possibly more concise too.

Proposed resolution:

Add new defintions to [definitions]:

> move constructor

> a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a side effect during the construction.

> move assignment operator

> an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a side effect during the assignment.

> move assignment

> use of the move assignment operator.

[ Howard adds post-Bellevue: ]

> Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect. `reserve` et. al. will use a move constructor if one is available, else it will use a copy constructor. A type may have both. If the move constructor is used, it must not throw. If the copy constructor is used, it can throw. The sentence in the proposed wording is correct without the recommended insertion. The Bellevue LWG recommended moving this issue to Ready. I am unfortunately pulling it back to Open. But I'm drafting wording to atone for this egregious action. :-)