<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=US-ASCII">
<title>Defining Move Special Member Functions</title>
<style type="text/css">
td { vertical-align: top; }
</style>
</head>

<body>


<h1>Defining Move Special Member Functions</h1>

<p>
ISO/IEC JTC1 SC22 WG21 N2953 = 09-0143 - 2009-09-27
</p>

<p>
Bjarne Stroustrup
<br>
Lawrence Crowl
</p>

<p>

<a href="#Introduction">Introduction</a><br>
<a href="#Findings">Findings</a><br>
<a href="#Proposal">Proposal</a><br>
<a href="#Wording">Wording</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#intro.object">1.8 The C++ object model [intro.object]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#basic.def">3.1 Declarations and definitions [basic.def]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#basic.def.odr">3.2 One definition rule [basic.def.odr]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#basic.stc.static">3.7.1 Static storage duration [basic.stc.static]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#basic.stc.auto">3.7.3 Automatic storage duration [basic.stc.auto]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#basic.stc.dynamic.safety">3.7.4.3 Safely-derived pointers [basic.stc.dynamic.safety]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#basic.life">3.8 Object lifetime [basic.life]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#basic.types">3.9 Types [basic.types]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#expr.prim.lambda">5.1.2 Lambda expressions [expr.prim.lambda]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#expr.ass">5.17 Assignment and compound assignment operators [expr.ass]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#stmt.return">6.6.3 The return statement [stmt.return]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#dcl.constexpr">7.1.5 The constexpr specifier [dcl.constexpr]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#namespace.udecl">7.3.3 The using declaration [namespace.udecl]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#dcl.fct.def">8.4 Function definitions [dcl.fct.def]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#dcl.fct.def.default">8.4.1 Explicitly-defaulted definitions [dcl.fct.def.default]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#dcl.fct.def.delete">8.4.2 Deleted definitions [dcl.fct.def.delete]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#dcl.init">8.5 Initializers [dcl.init]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#class">9 Classes [class]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#class.union">9.5 Unions [class.union]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#special">12 Special member functions [special]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#class.temporary">12.2 Temporary objects [class.temporary]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#class.conv.ctor">12.3.1 Conversion by constructor [class.conv.ctor]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#class.expl.init">12.6.1 Explicit initialization [class.expl.init]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#class.copy">12.8 Copying <ins>and moving</ins> class objects [class.copy]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#class.inhctor">12.9 Inheriting Constructors [class.inhctor]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#over.best.ics">13.3.3.1 Implicit conversion sequences [over.best.ics]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#over.ics.user">13.3.3.1.2 User-defined conversion sequences [over.ics.user]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#">13.5.3 Assignment [over.ass]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#except.throw">15.1 Throwing an exception [except.throw]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#except.spec">15.4 Exception specifications [except.spec]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#structure.specifications">17.5.1.4 Detailed Specifications [structure.specifications]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#functions.within.classes">17.5.2.2 Functions within classes [functions.within.classes]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#type.index.overview">18.7.2.1 type_index overview [type.index.overview]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#propagation">18.8.5 Exception Propagation [propagation]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#utility.arg.requirements">20.1.1 Template argument requirements [utility.arg.requirements]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#meta.type.synop">20.6.2 Header &lt;type_traits&gt; synopsis [meta.type.synop]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#meta.unary.prop">20.6.4.3 Type properties [meta.unary.prop]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#refwrap">20.7.5 Class template reference_wrapper [refwrap]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#func.bind.place">20.7.12.1.4 Placeholders [func.bind.place]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#util.smartptr.shared">20.8.13.2 Class template shared_ptr [util.smartptr.shared]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#util.smartptr.weak">20.8.13.3 Class template weak_ptr [util.smartptr.weak]</a><br>
<a href="#Acknowledgments">Acknowledgments</a><br>

</p>


<h2><a name="Introduction">Introduction</a></h2>

<p>

<p>
Paper 
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2904.pdf">N2904</a>
examined the generation of default copy and move operations
when elements are combined into an aggregate.
The proposal was discussed extensively in the July 2009 meeting,
and several changes were suggested at that meeting.
In addition, several changes surfaced in analysis after the meeting.
This paper is the formal proposal
to make move functions special.
</p>

<p>
Rather than repeat much of the arguments and analysis of 
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2904.pdf">N2904</a>,
we present a summary of our findings
and our proposal,
and then present the formal wording.
</p>

<h2><a name="Findings">Findings</a></h2>

<p>
More restrictive rules for when to generate a copy
would break too much existing code.
The rules explored, but which no longer appear viable include:
</p>
<ul>
<li><p>
Not generating a copy because of a pointer member.
</p></li>
<li><p>
Not generating a copy because of a user-defined destructor.
</p></li>
<li><p>
Not generating a copy when there is slicing.
We cannot technically alter behavior on slicing
because the slicing may occur in one translation unit but not in another.
</p></li>
</ul>

<p>
The move operations match a subset of the expressions of the copy operations.
That is, all expressions that match a move operation
would match a copy operation in the absence of that move operation.
So,
</p>
<ul>
<li><p>
Adding an implicit move operation
has the potential to inject new semantics into existing code,
particularly PODs.
</p></li>
<li><p>
Having unnecessarily different rules for when to generate moves and copies
would cause surprising behavior.
</p></li>
<li><p>
Implicitly generating a move when the copy was deleted
would break much of the existing C++0x library
and would leave a trap for programmers.
Programmers can add the move back in with an explicit default.
</p></li>
<li><p>
Implicitly generating a move when the copy was user-defined
would bypass the programmers intent for existing code,
and would do so silently.
</p></li>
</ul>

<p>
One suggestion in
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2904.pdf">N2904</a>,
was to permit compiler to null pointers that are moved from.
The idea was that doing so would help debugging of move semantics.
However, doing so would break too much existing code, particularly for PODS.
</p>

<p>
The standard uses the concept of copying extensively.
In most cases, the standard is adequately changed
by replacing "copy" with "copy/move".
</p>


<h2><a name="Proposal">Proposal</a></h2>

<p>
Built-in types have a move equivalent to their copy.
</p>

<p>
A struct copy is well-formed if and only if
all its bases and members have a (usable) copy.
</p>

<p>
A struct move is well-formed if and only if
all its bases and members have a (usable) move.
</p>

<p>
Moves and copies can be both <code>=default</code> and <code>=delete</code>,
even when not implicitly declared.
They must be well-formed, though.
</p>

<p>
A struct move is implicitly declared
if it is well-formed and the corresponding copy is not user-declared.
So, explicitly defaulting a copy constructor
will supress the move constructor.
One can add the move constructor back by explicitly defaulting it.
Doing otherwise would require deleting the move,
which leaves a hole in the expressions.
</p>
<blockquote><pre><code>
struct no_move {
    no_move( const no_move&amp; ) = default;
};
struct has_move {
    has_move( const has_move&amp; ) = default;
    has_move( has_move&amp;&amp; ) = default;
};
</code></pre></blockquote>

<p>
Unions have implicit deleted moves if a members has a
non-trivial moves.  This rule is the same as for copy, and
means that a user-defined union copy will not shadow a move.
That is <code>S&nbsp;a(x+y)</code>would be ill-formed.
For example,
given two classes non_trival_copier and non_trivial_mover,
that are otherwise trivial, the following happens.
</p>
<blockquote><pre><code>
union wrap_copy {
    non_trival_copier c;
};
// implicit wrap_copy::wrap_copy( const wrap_copy&amp; ) = delete;
// declaration "wrap_copy x(y)" is ill-formed
// because of delete;
// declaration "wrap_copy x(f());" is well-formed
// because the trival move is a better match.

union wrap_move {
    non_trivial_mover m;
};
// implicit wrap_move::wrap_move( wrap_move&amp;&amp; ) = delete;
// declaration "wrap_move x(f());" is ill-formed
// because of delete;
// declaration "wrap_move x(y);" is well-formed
// because the trival copy is a better match.

union wrap_both {
    non_trival_copier c;
    non_trivial_mover m;
};
// implicit wrap_both::wrap_both( const wrap_both&amp; ) = delete;
// implicit wrap_both::wrap_both( wrap_both&amp;&amp; ) = delete;
// declaration "wrap_both x(y)" is ill-formed because of delete;
// declaration "wrap_both x(f());" is ill-formed because of delete;
</code></pre></blockquote>

<p>
The current copy operations may throw.
If we added non-throwing implicit moves,
then the throw() specification would require us
to put the catch for unexpected into the generated move.
That catch and its control flow inhibit the optimizer
and add more code.
We already have people looking for ways to turn off that catch unexpected,
so adding one implicitly is likely to cause some concern.
</p>

<p>
However, throwing moves are problematic within the library,
and some libary specifications prohibit throwing moves.
To enable conditional definition of move operations within the library,
we add an <code>is_nothrow_constructible</code> variadic type trait.
</p>

<p>
We also extend existing type traits for copy to move.
</p>

<p>
Finally, we redefine the library concepts for copy and move
to reflect the status of change in core language.
</p>


<h2><a name="Wording">Wording</a></h2>

<p>
The proposed wording is usually relative to working draft
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2857.pdf">N2857</a>.
However, some wording is in sections heavily affected
by the decision to defer concepts,
and those sections are relative to working draft
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2723.pdf">N2723</a>.
Those sections are so marked.
</p>


<h3><a name="intro.object">1.8 The C++ object model [intro.object]</a></h3>

<p>
Edit paragraph 5 as follows.
</p>

<blockquote><p>
Unless it is a bit-field (9.6),
a most derived object shall have a non-zero size
and shall occupy one or more bytes of storage.
Base class subobjects may have zero size.
An object of trivially copyable<ins>, trivially movable,</ins>
or standard-layout type (3.9)
shall occupy contiguous bytes of storage.
</p></blockquote>


<h3><a name="basic.def">3.1 Declarations and definitions [basic.def]</a></h3>

<p>
Edit paragraph 3 as follows.
</p>

<blockquote><p>
[<i>Note:</i>
in some circumstances,
C++ implementations implicitly define the
default constructor (12.1), copy constructor (12.8),
<ins>move constructor ([class.copy]),</ins>
<ins>copy</ins> assignment operator (12.8),
<ins>move assignment operator ([class.copy]),</ins>
or destructor (12.4) member functions.
<ins>&mdash;<i>end note</i>]</ins>
[<i>Example:</i>
given
</p>
<blockquote><pre><code>
#include &lt;string&gt;
struct C {
    std::string s; // std::string as in (Clause 21)
};
int main() {
    C a;
    C b = a;
    b = a;
}
</code></pre></blockquote>
<p>
the implementation will implicitly define functions
to make the definition of C equivalent to
</p>
<blockquote><pre><code>
struct C {
    std::string s;
    C(): s() { }
    C(const C&amp; x): s(x.s) { }
    <ins>C(C&amp;&amp; x): s(std::move(x.s)) { }</ins>
    C&amp; operator=(const C&amp; x) { s = x.s; return *this; }
    <ins>C&amp; operator=(C&amp;&amp; x) { s = std::move(x.s); return *this; }</ins>
    ~C() { }
};
</code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
<del>&mdash;<i>end note</i>]</del>
</p></blockquote>


<h3><a name="basic.def.odr">3.2 One definition rule [basic.def.odr]</a></h3>

<p>
Edit paragraph 2 as follows.
</p>

<blockquote><p>
An expression is potentially evaluated
unless it is an unevaluated operand (Clause 5) or a subexpression thereof.
An object or non-overloaded function
whose name appears as a potentially-evaluated expression
is used unless it is an object
that satisfies the requirements for appearing in a constant expression (5.19)
and the lvalue-to-rvalue conversion (4.1) is immediately applied.
A virtual member function is used
if it is not pure.
An overloaded function is used
if it is selected by overload resolution
when referred to from a potentially-evaluated expression.
[<i>Note:</i>
this covers calls to named functions (5.2.2),
operator overloading (Clause 13),
user-defined conversions (12.3.2),
allocation function for placement new (5.3.4),
as well as non-default initialization (8.5).
A copy constructor <ins>or move constructor</ins> is used
even if the call is actually elided by the implementation.
&mdash;<i>end note</i>]
An allocation or deallocation function for a class
is used by a new expression appearing in a potentially-evaluated expression
as specified in 5.3.4 and 12.5.
A deallocation function for a class
is used by a delete expression appearing in a potentially-evaluated expression
as specified in 5.3.5 and 12.5.
A non-placement allocation or deallocation function for a class
is used by the definition of a constructor of that class.
A non-placement deallocation function for a class
is used by the definition of the destructor of that class,
or by being selected by the lookup at the point of definition
of a virtual destructor (12.4).
[<i>Footnote:</i>
An implementation is not required
to call allocation and deallocation functions from constructors or destructors;
however, this is a permissible implementation technique.
&mdash;<i>end footnote</i>]
A copy-assignment function for a class
is used by an implicitly-defined copy-assignment function
for another class as specified in 12.8.
<ins>A move-assignment function for a class
is used by an implicitly-defined move-assignment function
for another class as specified in [class.copy].</ins>
A default constructor for a class
is used by default initialization or value initialization as specified in 8.5.
A constructor for a class is used as specified in 8.5.
A destructor for a class is used as specified in 12.4.
</p></blockquote>


<h3><a name="basic.stc.static">3.7.1 Static storage duration [basic.stc.static]</a></h3>

<p>
Edit paragraph 2 as follows.
</p>

<blockquote><p>
If an object of static storage duration
has initialization or a destructor with side effects,
it shall not be eliminated even if it appears to be unused,
except that a class object or its copy<ins>/move</ins> may be eliminated
as specified in 12.8.
</p></blockquote>


<h3><a name="basic.stc.auto">3.7.3 Automatic storage duration [basic.stc.auto]</a></h3>

<p>
Edit paragraph 3 as follows.
</p>

<blockquote><p>
If a named automatic object
has initialization or a destructor with side effects,
it shall not be destroyed before the end of its block,
nor shall it be eliminated as an optimization even if it appears to be unused,
except that a class object or its copy<ins>/move</ins> may be eliminated
as specified in 12.8.
</p></blockquote>


<h3><a name="basic.stc.dynamic.safety">3.7.4.3 Safely-derived pointers [basic.stc.dynamic.safety]</a></h3>

<p>
Edit within paragraph 2 as follows.
</p>

<blockquote><p>
....
</p>
<ul>
<li><p>
the value of an object whose value
was copied <ins>or moved</ins> from a traceable pointer object,
where at the time of the copy <ins>or move</ins>
the source object contained a copy of a safely-derived pointer value.
</p></li>
</ul>
<p>
....
</p></blockquote>

<p>
Edit within paragraph 3 as follows.
</p>

<blockquote><p>
....
</p>
<ul>
<li><p>
the value of an object whose value
was copied <ins>or moved</ins> from a traceable pointer object,
where at the time of the copy <ins>or move,</ins>
the source object contained
an integer representation of a safely-derived pointer value;
</p></li>
</ul>
<p>
....
</p></blockquote>


<h3><a name="basic.life">3.8 Object lifetime [basic.life]</a></h3>

<p>
Edit within paragraph 1 as follows.
</p>

<blockquote><p>
The lifetime of an object is a runtime property of the object.
An object is said to have non-trivial initialization
if it is of a class or aggregate type
and it or one of its members is initialized by a constructor
other than a trivial default constructor.
[<i>Note:</i>
initialization by a trivial copy<ins>/move</ins> constructor
is non-trivial initialization.
&mdash;<i>end note</i>]
The lifetime of an object of type T begins when:
....
</p></blockquote>


<h3><a name="basic.types">3.9 Types [basic.types]</a></h3>

<p>
Edit within paragraph 2 as follows.
</p>

<blockquote><p>
For any object (other than a base-class subobject)
of trivially copyable <ins>or trivially movable</ins> type <code>T</code>,
whether or not the object holds a valid value of type <code>T</code>,
the underlying bytes (1.7) making up the object can be copied into an array
of char or unsigned char.
[<i>Footnote:</i>
By using, for example,
the library functions (17.6.1.2)
<code>std::memcpy</code> or <code>std::memmove</code>.
&mdash;<i>end footnote</i>]
If the content of the array of char or unsigned char
is copied back into the object,
the object shall subsequently hold its original value.
....
</p></blockquote>

<p>
Edit paragraph 3 as follows.
</p>

<blockquote><p>
For any trivially copyable <ins>or trivially movable</ins> type <code>T</code>,
if two pointers to <code>T</code>
point to distinct <code>T</code> objects
<code>obj1</code> and <code>obj2</code>,
where neither <code>obj1</code> nor <code>obj2</code> is a base-class subobject,
if the value of <code>obj1</code> is copied into <code>obj2</code>,
using the <code>std::memcpy</code> library function,
<code>obj2</code> shall subsequently hold the same value as <code>obj1</code>.
[<i>Example:</i>
</p>
<blockquote><pre><code>
T* t1p;
T* t2p; // provided that t2p points to an initialized object ...
std::memcpy(t1p, t2p, sizeof(T)); // at this point,
// every subobject of trivially copyable <ins>
// or trivially movable</ins> type <ins>in *t1p</ins>
// <del>in *t1p</del> contains the same value<ins>
// </ins>as the corresponding subobject in *t2p
</code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
</p></blockquote>

<p>
Edit paragraph 4 as follows.
</p>

<blockquote><p>
The <dfn>object representation</dfn> of an object of type <code>T</code>
is the sequence of <var>N</var> <code>unsigned char</code> objects
taken up by the object of type <code>T</code>,
where <var>N</var> equals <code>sizeof(T)</code>.
The <dfn>value representation</dfn> of an object
is the set of bits that hold the value of type <code>T</code>.
For trivially copyable <ins>or trivially movable</ins> types,
the value representation is a set of bits in the object representation
that determines a value,
which is one discrete element of an implementation-defined set of values.
[<i>Footnote:</i>
The intent is that the memory model of C++
is compatible with that of ISO/IEC 9899 Programming Language C.
&mdash;<i>end footnote</i>]
</p></blockquote>

<p>
Edit paragraph 10 as follows.
</p>

<blockquote><p>
Arithmetic types (3.9.1), enumeration types, pointer types,
pointer to member types (3.9.2), and <code>std::nullptr_t</code>,
and cv-qualified versions of these types (3.9.3)
are collectively called <dfn>scalar types</dfn>.
Scalar types, POD classes (Clause 9),
arrays of such types and
<del><i>cv-qualified</i></del>
<ins>cv-qualified</ins>
versions of these types (3.9.3)
are collectively called <dfn>POD types</dfn>.
Scalar types, trivially copyable class types (Clause 9),
arrays of such types, and cv-qualified versions of these types (3.9.3)
are collectively called <dfn>trivially copyable types</dfn>.
<ins>Scalar types, trivially movable class types (Clause 9),
arrays of such types, and cv-qualified versions of these types (3.9.3)
are collectively called <dfn>trivially movable types</dfn>.</ins>
Scalar types, trivial class types (Clause 9),
arrays of such types and cv-qualified versions of these types (3.9.3)
are collectively called <dfn>trivial types</dfn>.
Scalar types, standard-layout class types (Clause 9),
arrays of such types and cv-qualified versions of these types (3.9.3)
are collectively called <dfn>standard-layout types</dfn>.
</p></blockquote>

<p>
Edit paragraph 12 as follows.
Note that literal types continue to not require a trivial move constructor.
</p>

<blockquote><p>
A type is a literal type if it is:
</p>
<ul>
<li><p>
a scalar type; or
</p></li>
<li><p>
a class type (Clause 9) with
</p>
<ul>
<li><p>
a trivial copy constructor,
</p></li>
<li><p>
<ins>no non-trivial move constructor,</ins>
</p></li>
<li><p>
a trivial destructor,
</p></li>
<li><p>
a trivial default constructor
or at least one constexpr constructor
other than the copy <ins>or move</ins> constructor,
and
</p></li>
<li><p>
all non-static data members and base classes of literal types; or
</p></li>
</ul>
</li>
<li><p>
an array of literal type.
</p></li>
</ul></blockquote>


<h3><a name="expr.prim.lambda">5.1.2 Lambda expressions [expr.prim.lambda]</a></h3>

<p>
Note that this wording comes from N2927,
which has been adopted but which has not yet appeared in a working draft.
</p>

<p>
Edit within paragraph 3 as follows.
</p>

<blockquote><p>
....
An implementation may define the closure type
differently from what is described below
provided this does not alter the observable behavior of the program
other than by changing:
</p>
<ul>
<li><p>
the size and/or alignment of the closure type
</p></li>
<li><p>
whether the closure type is trivially copyable
<ins>or trivially movable</ins> (_class_ Clause 9)
</p></li>
<li><p>
whether the closure type is a standard-layout class (_class_ Clause 9)
</p></li>
<li><p>
whether the closure type is a POD class (_class_ Clause 9)
</p></li>
</ul>
<p>
An implementation shall not add members of rvalue reference type
to the closure type.
</p></blockquote>

<p>
Edit paragraph 18 as follows.
</p>

<blockquote><p>
The closure type associated with a <var>lambda-expression</var>
has a deleted <ins>([dcl.fct.def.delete])</ins> default constructor
and a deleted copy assignment operator.
It has an implicitly-declared copy constructor
<ins>and may have an implicitly-declared move constructor</ins>
(_class.copy_ 12.8).
[<i>Note:</i>
The copy<ins>/move</ins> constructor
is implicitly defined in the same way
as any other implicitly declared copy<ins>/move</ins> constructor
would be implicitly defined.
&mdash;<i>end note</i>]
</p></blockquote>

<p>
Delete paragraph 19.
</p>

<blockquote><p><del>
The closure type <var>C</var> associated with a <var>lambda-expression</var>
has an additional public inline constructor
with a single parameter of type <var>C</var><code>&amp;&amp;</code>.
Given an argument object <code>x</code>,
this constructor initializes
each non-static data member <code>m</code> of <code>*this</code> as follows:
</del></p>
<ul>
<li><p><del>
if <code>m</code> is an array,
each element of <code>this->m</code>
is direct-initialized with an expression
equivalent to std::move(e)
where e is the corresponding element of <code>x.m</code>.
Otherwise,
</del></p></li>
<li><p><del>
if <code>m</code> is an lvalue reference,
<code>this->m</code> is initialized with <code>x.m</code>.
[<i>Note:</i>
<code>m</code> cannot be an rvalue reference.
&mdash;<i>end note</i>]
Otherwise,
</del></p></li>
<li><p><del>
<code>this->m</code>
is direct-initialized with an expression
equivalent to <code>std::move(x.m)</code>.
</del></p></li>
</ul>
<p><del>
[<i>Note:</i>
The notations are for exposition only;
the members of a closure type are unnamed
and std::move need not be called.
&mdash;<i>end note</i>]
</del></p></blockquote>

<p>
Note that paragraph 21 is unchanged
because named variables are not moved.
<p>

<blockquote><p>
When the <var>lambda-expression</var> is evaluated,
the entities that are captured by copy
are used to direct-initialize
each corresponding non-static data member of the resulting closure object.
(For array members,
the array elements are direct-initialized in increasing subscript order.)
These initializations are performed in the (unspecified) order
in which the non-static data members are declared.
[<i>Note:</i>
This ensures that the destructions
will occur in the reverse order of the constructions.
&mdash;<i>end note</i>]
</p></blockquote>


<h3><a name="expr.ass">5.17 Assignment and compound assignment operators [expr.ass]</a></h3>

<p>
Edit paragraph 4 as follows.
</p>

<blockquote><p>
If the left operand is of class type,
the class shall be complete.
Assignment to objects of a class
is defined by the copy<ins>/move</ins> assignment operator (12.8, 13.5.3).
</p></blockquote>


<h3><a name="stmt.return">6.6.3 The return statement [stmt.return]</a></h3>

<p>
Edit paragraph 2 as follows.
</p>

<blockquote><p>
A return statement without an expression can be used
only in functions that do not return a value,
that is, a function with the return type <code>void</code>,
a constructor (12.1), or a destructor (12.4).
A return statement with an expression of non-void type
can be used only in functions returning a value;
the value of the expression is returned to the caller of the function.
The expression is implicitly converted
to the return type of the function in which it appears.
A return statement can involve the construction and copy <ins>or move</ins>
of a temporary object (12.2).
[<i>Note:</i>
A copy <ins>or move</ins> operation associated with a return statement
may be elided or considered as an rvalue
for the purpose of overload resolution
in selecting a constructor (12.8).
&mdash;<i>end note</i>]
A return statement with a <var>braced-init-list</var>
initializes the object or reference to be returned from the function
by copy-list-initialization (8.5.4) from the specified initializer list.
[<i>Example:</i>
</p>
<blockquote><pre><code>
std::pair&lt;std::string,int&gt; f(const char* p, int x) {
    return {p,x};
}
</code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
Flowing off the end of a function is equivalent to a return with no value;
this results in undefined behavior in a value-returning function.
</p></blockquote>


<h3><a name="dcl.constexpr">7.1.5 The constexpr specifier [dcl.constexpr]</a></h3>

<p>
Edit within paragraph 4 as follows.
</p>

<blockquote><p>
....
A trivial copy<ins>/move</ins> constructor is also a constexpr constructor.
....
</p></blockquote>


<h3><a name="namespace.udecl">7.3.3 The using declaration [namespace.udecl]</a></h3>

<p>
Edit paragraph 4 follows.
</p>

<blockquote><p>
[<i>Note:</i>
Since destructors do not have names,
a <var>using-declaration</var> cannot refer to a destructor for a base class.
Since specializations of member templates for conversion functions
are not found by name lookup,
they are not considered when a
<var>using-declaration</var> specifies a conversion function (14.6.2).
&mdash;<i>end note</i>]
If an assignment operator brought from a base class into a derived class scope
has the signature of a <del>copy-assignment</del>
<ins>copy/move assignment</ins> operator
for the derived class (12.8),
the <var>using-declaration</var> does not by itself
suppress the implicit declaration of
the derived class <del>copy-</del>assignment operator;
the <del>copy-assignment</del> <ins>copy/move assignment</ins> operator
from the base class
is hidden or overridden by
the implicitly-declared <del>copy-assignment</del>
<ins>copy/move assignment</ins> operator
of the derived class,
as described below.
</p></blockquote>


<h3><a name="dcl.fct.def">8.4 Function definitions [dcl.fct.def]</a></h3>

<p>
End the section after paragraph 8.
The intent is to make defaulted and deleted definitions
have their own section for citations.
</p>


<h3><a name="dcl.fct.def.default">8.4.1 Explicitly-defaulted definitions [dcl.fct.def.default]</a></h3>

<p>
Add a new section comprising paragraph 9
of the old 8.4 Function definitions [dcl.fct.def].
</p>

<p>
Split the paragraph into three paragraphs,
with the first paragraph containing the introductory sentence,
the second paragraph containing the special member discussion,
and the third paragraph containing the note and example.
The intent is to structure the discussion better for citations.
</p>

<p>
Edit the resulting second paragraph as follows.
</p>

<blockquote><p>
<del>Only special</del>
Special member functions may be explicitly defaulted,
and the implementation shall define them
as if they had implicit definitions (12.1, 12.4, 12.8).
A special member function
that would be implicitly defined as deleted
shall not be explicitly defaulted.
A special member function is <dfn>user-provided</dfn>
if it is user-declared
and not explicitly defaulted on its first declaration.
A user-provided explicitly-defaulted function
is defined at the point where it is explicitly defaulted.
</p></blockquote>

<p>
Edit the resulting third paragraph as follows.
</p>

<blockquote><p>
[<i>Example:</i>
</p>
<blockquote><pre><code>
struct trivial {
    trivial() = default;
    trivial(const trivial&amp;) = default;
    trivial(trivial&amp;&amp;) = default;
<ins>    trivial&amp; operator =(const trivial&amp;) = default;
    trivial&amp; operator =(trivial&amp;&amp;) = default;</ins>
    ~trivial() = default;
};

struct nontrivial1 {
    nontrivial1();
};
nontrivial1::nontrivial1() = default;         // not inline

struct nontrivial2 {
    nontrivial2();
};
inline nontrivial2::nontrivial2() = default;  // not first declaration

struct nontrivial3 {
    virtual ~nontrivial3() = 0;               // virtual
};
inline nontrivial3::~nontrivial3() = default; // not first declaration
</code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
</p></blockquote>


<h3><a name="dcl.fct.def.delete">8.4.2 Deleted definitions [dcl.fct.def.delete]</a></h3>

<p>
Add a new section comprising paragraph 10
of the old 8.4 Function definitions [dcl.fct.def].
Split that paragraph as follows.
The intent is to structure the section better for citations.
</p>

<p>
The first paragraph comprises the introductory text.
It will be as follows.
</p>

<blockquote><p>
A function definition of the form:
</p>
<blockquote><p>
<var>decl-specifier-seq<sub>opt</sub> attribute-specifier<sub>opt</sub>
declarator</var> <code>= delete ;</code>
</p></blockquote>
<p>
is called a <dfn>deleted definition</dfn>.
A function with a deleted definition
is also called a <dfn>deleted function</dfn>.
</p></blockquote>

<p>
The second paragraph comprises the explanatory text.
It will be as follows.
</p>

<blockquote><p>
A program that refers to a deleted function implicitly or explicitly,
other than to declare it, is ill-formed.
[<i>Note:</i>
this includes calling the function implicitly or explicitly
and forming a pointer or pointer-to-member to the function.
It applies even for references in expressions
that are not potentially-evaluated.
If a function is overloaded,
it is referenced only if the function is selected by overload resolution.
&mdash;<i>end note</i>]
</p></blockquote>

<p>
The third paragraph comprises the primary examples.
Edit it as follows.
</p>

<blockquote><p>
[<i>Example:</i>
One can enforce non-default initialization and non-integral initialization with
</p>
<blockquote><pre><code>
struct sometype {
    sometype() = delete;              // redundant, but legal
    sometype(std::intmax_t) = delete;
    sometype(double);
};
</code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
[<i>Example:</i>
One can prevent use of a class in certain new expressions
by using deleted definitions of a user-declared operator new for that class.
</p>
<blockquote><pre><code>
struct sometype {
    void *operator new(std::size_t) = delete;
    void *operator new[](std::size_t) = delete;
};
sometype *p = new sometype;    // error, deleted class operator new
sometype *p = new sometype[3]; // error, deleted class operator new[]
</code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
<ins>[<i>Example:</i>
One can make a class uncopyable, i.e. move-only,
by using deleted definitions of
the copy constructor and copy-assignment operator,
and then providing defaulted definitions of
the move constructor and the move assignment operator.</ins>
</p>
<blockquote><pre><code>
<ins>struct moveonly {
    moveonly() = default;
    moveonly(const moveonly&amp;) = delete;
    moveonly(moveonly&amp;&amp;) = default;
    moveonly&amp; operator=(const moveonly&amp;) = delete;
    moveonly&amp; operator=(moveonly&amp;&amp;) = default;
    ~moveonly() = default;
};
moveonly *p;
moveonly q(*p); // error, deleted copy constructor</ins>
</code></pre></blockquote>
<p>
<ins>&mdash;<i>end example</i>]</ins>
</p></blockquote>

<p>
The fourth paragraph comprises restrictive clauses.
</p>

<blockquote><p>
A deleted function is implicitly inline.
[<i>Note:</i>
the one-definition rule (3.2) applies to deleted definitions.
&mdash;<i>end note</i>]
A deleted definition of a function
shall be the first declaration of the function.
[<i>Example:</i>
</p>
<blockquote><pre><code>
struct sometype {
    sometype();
};
sometype::sometype() = delete; // ill-formed; not first declaration
</code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
</p></blockquote>


<h3><a name="dcl.init">8.5 Initializers [dcl.init]</a></h3>

<p>
Edit paragraph 14 as follows.
</p>

<blockquote><p>
The initialization that occurs in the form
</p>
<blockquote><pre><code>
T x = <del>a</del> <ins><var>expr</var></ins>;
</code></pre></blockquote>
<p>
as well as in argument passing, function return, throwing an exception (15.1),
handling an exception (15.3), and aggregate member initialization (8.5.1)
is called
<dfn><del>copy-initialization</del> <ins>copy initialization</ins></dfn>.
<ins>
[<i>Note:</i>
The copy initialization may invoke a move ([class.copy]).
&mdash;<i>end note</i>]
</ins>
</p></blockquote>


<h3><a name="class">9 Classes [class]</a></h3>

<p>
Edit paragraph 3 as follows.
</p>

<blockquote><p>
Complete objects and member subobjects of class type shall have nonzero size.
[<i>Footnote:</i>
Base class subobjects are not so constrained.
&mdash;<i>end footnote</i>]
[<i>Note:</i>
class objects can be assigned, passed as arguments to functions,
and returned by functions
(except objects of classes
for which copying <ins>or moving</ins> has been restricted;
see 12.8.
Other plausible operators, such as equality comparison,
can be defined by the user; see 13.5.
&mdash;<i>end note</i>]
</p></blockquote>

<p>
Edit paragraph 6 as follows.
</p>

<blockquote><p>
A <dfn>trivially copyable class</dfn> is a class that:
</p>
<ul>
<li><p>
has <del>no non-</del>trivial copy constructors (12.8),
</p></li>
<li><p><ins>
has no non-trivial move constructors ([class.copy]),
</ins></p></li>
<li><p>
has <del>no non-</del>trivial copy assignment operators (13.5.3, 12.8),
<del>and</del>
</p></li>
<li><p><ins>
has no non-trivial move assignment operators (13.5.3, [class.copy]), and
</ins></p></li>
<li><p>
has a trivial destructor (12.4).
</p></li>
</ul>
<p><ins>
A <dfn>trivially movable class</dfn> is a class that:
</ins></p>
<ul>
<li><p><ins>
has trivial move constructors ([class.copy]),
</ins></p></li>
<li><p><ins>
has trivial move assignment operators
(13.5.3, [class.copy]), and
</ins></p></li>
<li><p><ins>
has a trivial destructor (12.4).
</ins></p></li>
</ul>
<p>
<ins>
[<i>Note:</i>
A class may not have
a move constructor or a move assignment operator ([class.copy]),
in which case it is neither trivially movable nor non-trivially movable.
&mdash;<i>end note</i>]
</ins>
A <dfn>trivial class</dfn> is a class that
has a trivial default constructor (12.1)
and is trivially copyable.
[<i>Note:</i>
in particular,
a trivially copyable<ins>, trivially movable,</ins> or trivial class
does not have virtual functions or virtual base classes.
&mdash;<i>end note</i>]
</p></blockquote>


<h3><a name="class.union">9.5 Unions [class.union]</a></h3>

<p>
Split and edit paragraph 1 as follows.
The first part of paragraph 1 remains paragraph 1.
The intent is to structure the discussion better for citations.
</p>

<blockquote><p>
In a union, at most one of the data members can be active at any time,
that is, the value of at most one of the data members
can be stored in a union at any time.
[<i>Note:</i>
one special guarantee is made in order to simplify the use of unions:
If a standard-layout union
contains several standard-layout structs
that share a common initial sequence (9.2),
and if an object of this standard-layout union type
contains one of the standard-layout structs,
it is permitted to
inspect the common initial sequence of any of standard-layout struct members;
see 9.2.
&mdash;<i>end note</i>]
The size of a union is sufficient to contain the largest of its data members.
Each data member is allocated as if it were the sole member of a struct.
</p></blockquote>

<p>
The second part of paragraph 1 becomes a new paragraph.
Edit that paragraph as follows.
Note that non-movable classes may still be copyable.
Note the lone added comma after "reference type".
</p>

<blockquote><p>
A union can have member functions (including constructors and destructors),
but not virtual (10.3) functions.
A union shall not have base classes.
A union shall not be used as a base class.
If a union contains a non-static data member of reference type<ins>,</ins>
the program is ill-formed.
[<i>Note:</i>
if any non-static data member of a union
has a non-trivial default constructor (12.1), copy constructor (12.8),
copy assignment operator (12.8), or destructor (12.4),
the corresponding member function of the union
must be <del>user-declared</del> user-provided
or it will be implicitly deleted <ins>([dcl.fct.def.delete])</ins>
for the union.
<ins>If any non-static data member of a union
has a non-trivial move constructor ([class.copy])
or move assignment operator ([class.copy]),
the corresponding member function of the union
must be user-provided
or it will not be implicitly deleted for the union.</ins>
&mdash;<i>end note</i>]
</p></blockquote>

<p>
The third part of paragraph 1,
consisting of the string example, becomes a new paragraph.
Edit that paragraph as follows.
</p>

<blockquote><p>
[<i>Example:</i>
Consider the following union:
</p>
<blockquote><pre><code>
union U {
    int i;
    float f;
    std::string s;
};
</code></pre></blockquote>
<p>
Since <code>std::string</code> (21.3)
declares non-trivial versions of all of the special member functions,
<code>U</code> will have an implicitly deleted default constructor,
copy<ins>/move</ins> constructor, copy<ins>/move</ins> assignment operator,
and destructor.
To use <code>U</code>,
some or all of these member functions
must be <del>user-declared</del> <ins>user-provided</ins>.
<ins>&mdash;<i>end example</i>]</ins>
</p></blockquote>

<p>
The fourth part of paragraph 1,
consisting of the example changing the active member, becomes a new paragraph.
Edit that paragraph as follows.
</p>

<blockquote><p>
<ins>
[<i>Note:</i>
In general,
one must use explicit destructor calls and placement new operators
to change the active member of a union.
&mdash;<i>end note</i>]
[<i>Example:</i>
</ins>
Consider an object <code>u</code> of a union type <code>U</code>
having non-static data members <code>m</code> of type <code>M</code>
and <code>n</code> of type <code>N</code>.
If <code>M</code> has a non-trivial destructor
and <code>N</code> has a non-trivial constructor
(for instance, if they declare or inherit virtual functions),
the active member of <code>u</code>
can be safely switched from <code>m</code> to <code>n</code>
using the destructor and placement new operator as follows:
</p>
<blockquote><pre><code>
u.m.~M();
new (&amp;u.n) N;
</code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
</p></blockquote>


<h3><a name="special">12 Special member functions [special]</a></h3>

<p>
Split and edit paragraph 1 as follows.
This first part of paragraph 1 remains paragraph 1.
The second part, about refering implicitly-defined member functions,
becomes a new paragraph.
The intent is to structure the discussion better for citations.
</p>

<blockquote><p>
The default constructor (12.1),
copy constructor and copy assignment operator (12.8),
<ins>move constructor and move assignment operator ([class.copy]),</ins>
and destructor (12.4)
are special member functions.
[<i>Note:</i>
The implementation
will implicitly declare these member functions for some class types
when the program does not explicitly declare them.
The implementation will implicitly define them if they are used.
See 12.1, 12.4 and 12.8.
&mdash;<i>end note</i>]
Programs shall not define implicitly-declared special member functions.
</p></blockquote>

<p>
Edit paragraph 2 as follows.
</p>

<blockquote><p>
[<i>Note:</i>
the special member functions
affect the way objects of class type are
created, copied, <ins>moved,</ins> and destroyed,
and how values can be converted to values of other types.
Often such special member functions are called implicitly.
&mdash;<i>end note</i>]
</p></blockquote>

<p>
Edit paragraph 9 as follows.
</p>

<blockquote><p>
A copy constructor (12.8) is used to copy objects of class type.
<ins>A move constructor ([class.copy])
is used to move the contents of objects of class type.</ins>
</p></blockquote>


<h3><a name="class.temporary">12.2 Temporary objects [class.temporary]</a></h3>

<p>
Merge and split existing paragraphs 1 and 2.
Edit them as follows.
The first part of paragraph 1 remains paragraph.
</p>

<blockquote><p>
Temporaries of class type are created in various contexts:
binding an rvalue to a reference (8.5.3), returning an rvalue (6.6.3),
a conversion that creates an rvalue (4.1, 5.2.9, 5.2.11, 5.4),
throwing an exception (15.1), entering a <dfn>handler</dfn> (15.3),
and in some initializations (8.5).
[<i>Note:</i>
the lifetime of exception objects is described in 15.1.
&mdash;<i>end note</i>]
Even when the creation of the temporary object
is avoided (12.8),
all the semantic restrictions shall be respected
as if the temporary object had been created.
<del>[<i>Example:</i></del>
<ins>[<i>Note:</i></ins>
even if the copy<ins>/move</ins> constructor is not called,
all the semantic restrictions, such as accessibility (Clause 11),
shall be satisfied.
<del>&mdash;<i>end example</i>]</del>
<ins>&mdash;<i>end note</i>]</ins>
</p></blockquote>

<p>
Take the last part, the true example, of the existing paragraph 1
and merge it into the existing paragraph 2.
</p>

<blockquote><p>
[<i>Example:</i>
<ins>Consider the following code.</ins>
<blockquote><pre><code>
class X {
public:
    X(int);
    X(const X&amp;);
    ~X();
};

<ins>class Y {
public:
    Y(int);
    Y(Y&amp;&amp;);
    ~Y();
};</ins>

X f(X);
<ins>Y g(Y);</ins>

void h() {
    X a(1);
    X b = f(X(2));
    <ins>Y c = g(Y(3));</ins>
    a = f(a);
}
</code></pre></blockquote>
<p>
<del>Here, an</del> <ins>An</ins> implementation
might use a temporary in which to construct <code>X(2)</code>
before passing it to <code>f()</code>
using <code>X</code>'s <del>copy-constructor</del> <ins>copy constructor</ins>;
alternatively, <code>X(2)</code> might be constructed
in the space used to hold the argument.
<ins>Likewise,
an implementation
might use a temporary in which to construct <code>Y(3)</code>
before passing it to <code>g()</code>
using <code>Y</code>'s move constructor;
alternatively, <code>Y(3)</code> might be constructed
in the space used to hold the argument.</ins>
Also, a temporary might be used to hold the result of <code>f(X(2))</code>
before copying it to <code>b</code>
using <code>X</code>'s <del>copy-constructor</del> <ins>copy constructor</ins>;
alternatively, <code>f()</code>'s result might be constructed in <code>b</code>.
<ins>Likewise,
a temporary might be used to hold the result of <code>g(Y(3))</code>
before moving it to <code>c</code> using <code>Y</code>'s move constructor;
alternatively, <code>g()</code>'s result
might be constructed in <code>c</code>.</ins>
On the other hand,
the expression <code>a=f(a)</code>
requires a temporary for the result of <code>f(a)</code>,
which is then assigned to <code>a</code>.
&mdash;<i>end example</i>]
</p></blockquote>


<h3><a name="class.conv.ctor">12.3.1 Conversion by constructor [class.conv.ctor]</a></h3>

<p>
Edit paragraph 3 as follows.
</p>

<blockquote><p>
A non-explicit <del>copy-constructor</del>
<ins>copy/move constructor</ins> (12.8)
is a converting constructor.
An implicitly-declared copy<ins>/move</ins> constructor
is not an explicit constructor;
it may be called for implicit type conversions.
</p></blockquote>

<h3><a name="class.expl.init">12.6.1 Explicit initialization [class.expl.init]</a></h3>

<p>
Within the example of paragraph 1,
change uses of "copy" to "copy/move".
</p>


<h3><a name="class.copy">12.8 Copying <ins>and moving</ins> class objects [class.copy]</a></h3>

<p>
Edit the section title as above.
</p>

<p>
Edit paragraph 1 as follows.
</p>

<blockquote><p>
A class object can be copied <ins>or moved</ins> in two ways,
by initialization (12.1, 8.5),
including for function argument passing (5.2.2)
and for function value return (6.6.3),
and by assignment (5.17).
Conceptually,
these two operations are implemented by
a copy<ins>/move</ins> constructor (12.1)
and copy<ins>/move</ins> assignment operator (13.5.3).
</p></blockquote>

<p>
Split the existing paragraph 2 into two parts.
The intent is to structure the discussion better for citations
and to make room for a move specification.
Edit the first part as follows.
Note that the footnote is not deleted, but moved to later in the text.
</p>

<blockquote><p>
A non-template constructor for class <code>X</code> is a copy constructor
if its first parameter is of type <code>X&amp;</code>,
<code>const X&amp;</code>, <code>volatile X&amp;</code>
or <code>const volatile X&amp;</code>,
and either there are no other parameters
or else all other parameters have default arguments (8.3.6).
<del>
[<i>Footnote:</i>
Because a template constructor
or a constructor whose first parameter is an rvalue reference
is never a copy constructor,
the presence of such a constructor
does not suppress the implicit declaration of a copy constructor.
Such constructors participate in overload resolution with other constructors,
including copy constructors,
and, if selected, will be used to copy an object.
&mdash;<i>end footnote</i>]
</del>
[<i>Example:</i>
<code>X::X(const X&amp;)</code> and <code>X::X(X&amp;,int=1)</code>
are copy constructors.
</p>
<blockquote><pre><code>
struct X {
    X(int);
    X(const X&amp;, int = 1);
};
X a(1);    // calls X(int);
X b(a, 0); // calls X(const X&amp;, int);
X c = b;   // calls X(const X&amp;, int);
</code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
</p></blockquote>

<p>
After the first part of the existing paragraph 2,
add a new paragraph as follows.

<blockquote><p><ins>
A non-template constructor for class <code>X</code> is a move constructor
if its first parameter is of type <code>X&amp;&amp;</code>,
<code>const X&amp;&amp;</code>, <code>volatile X&amp;&amp;</code>
or <code>const volatile X&amp;&amp;</code>,
and either there are no other parameters
or else all other parameters have default arguments (8.3.6).
[<i>Example:</i>
<code>Y::Y(X&amp;&amp;)</code>
is a move constructor.
</ins></p>
<blockquote><pre><code><ins>
struct Y {
    Y(const Y&amp;);
    Y(Y&amp;&amp;);
}; 
extern Y f(int);
Y d(f(1)); // calls Y(Y&amp;&amp;);
Y e = d;   // calls Y(const Y&amp;);
</ins></code></pre></blockquote>
<p><ins>
&mdash;<i>end example</i>]
</ins></p></blockquote>

<p>
Edit the second part of the existing paragraph 2 as follows.
</p>

<blockquote><p>
[<i>Note:</i>
all forms of copy<ins>/move</ins> constructor may be declared for a class.
[<i>Example:</i>
</p>
<blockquote><pre><code>
struct X {
    X(const X&amp;);
    X(X&amp;);        // OK
<ins>    X(X&amp;&amp;);
    X(const X&amp;&amp;); // OK, but possibly not sensible</ins>
};
</code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
&mdash;<i>end note</i>]
[<i>Note:</i>
if a class <code>X</code> only has
a copy constructor with a parameter of type <code>X&amp;</code>,
an initializer of type <code>const X</code> or <code>volatile X</code>
cannot initialize an object of type (possibly cv-qualified) <code>X</code>.
[<i>Example:</i>
</p>
<blockquote><pre><code>
   struct X {
     X();   // default constructor
     X(X&amp;); // copy constructor with a nonconst parameter
   };
   const X cx;
   X x = cx;    // error: X::X(X&amp;) cannot copy cx into x
</code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
&mdash;<i>end note</i>]
</p></blockquote>

<p>
Split and edit paragraph 3 as follows.
The first sentence remains within the paragraph,
which also gets an example.
</p>

<blockquote><p>
A declaration of a constructor for a class <code>X</code>
is ill-formed
if its first parameter is of type (optionally cv-qualified) <code>X</code>
and either there are no other parameters
or else all other parameters have default arguments.
<ins>
[<i>Footnote:</i>
A copy constructor cannot presuppose that its parameter has been copied.
&mdash;<i>end footnote</i>]
[<i>Example:</i>
</ins>
</p>
<blockquote><pre><code><ins>
struct S {
    S(S); // no way to copy constructor's parameter
};
</ins></code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
</p></blockquote>

<p>
Add a new paragraph consisting of
the remainder of the existing paragraph 3
and edited as follows.
</p>

<blockquote><p>
A member function template is never instantiated
to perform the copy of a class object to an object of its class type.
<ins>
[<i>Footnote:</i>
Because a template constructor
or a constructor whose first parameter is an rvalue reference
is never a copy constructor,
the presence of such a constructor
does not suppress the implicit declaration of a copy constructor.
Such constructors participate in overload resolution with other constructors,
including copy constructors,
and, if selected, will be used to copy an object.
&mdash;<i>end footnote</i>]
A member function template is never instantiated
to perform the move of a class object to an object of its class type.
[<i>Footnote:</i>
Because a template constructor
is never a move constructor,
the presence of such a constructor
does not suppress the implicit declaration of a move constructor.
Such constructors participate in overload resolution with other constructors,
including move constructors,
and, if selected, will be used to move an object.
&mdash;<i>end footnote</i>]
</ins>
[<i>Example:</i>
</p>
<blockquote><pre><code>
struct S {
    template&lt;typename T&gt; S(const T&amp;);
<ins>    template&lt;typename T&gt; S(T&amp;&amp;);
    S();</ins>
};
S f();
const S g;
void h() {
    S a( f() ); // does not instantiate member template
<ins>                // uses the implicitly generated move constructor
    S a( g );   // does not instantiate member template
                // uses the implicitly generated copy constructor</ins>
}
</code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
</p></blockquote>

<p>
The existing paragraph 4 remains unchanged.
</p>

<blockquote><p>
If the class definition does not explicitly declare a copy constructor,
one is declared implicitly.
Thus, for the class definition
</p>
<blockquote><pre><code>
struct X {
    X(const X&amp;, int);
};
</code></pre></blockquote>
<p>
a copy constructor is implicitly-declared.
If the user-declared constructor is later defined as
</p>
<blockquote><pre><code>
X::X(const X&amp; x, int i =0) { /* ... */ }
</code></pre></blockquote>
<p>
then any use of <code>X</code>'s copy constructor
is ill-formed because of the ambiguity;
no diagnostic is required.
</p></blockquote>

<p>
Split the existing paragraph 5 into two parts,
the form of copy constructors and the deleting of copy constructors.
The first part remains unchanged as follows.
</p>

<blockquote><p>
The implicitly-declared copy constructor for a class <code>X</code>
will have the form
</p>
<blockquote><pre><code>
X::X(const X&amp;)
</code></pre></blockquote>
<p>
if
</p>
<ul>
<li><p>
each direct or virtual base class <code>B</code> of <code>X</code>
has a copy constructor whose first parameter
is of type <code>const B&amp;</code> or <code>const volatile B&amp;</code>,
and
</p></li>
<li><p>
for all the non-static data members of <code>X</code>
that are of a class type <code>M</code> (or array thereof),
each such class type has a copy constructor
whose first parameter
is of type <code>const M&amp;</code> or <code>const volatile M&amp;</code>.
[<i>Footnote</i>:
This implies that
the reference parameter of the implicitly-declared copy constructor
cannot bind to a volatile lvalue;
see C.1.8.
&mdash;<i>end footnote</i>]
</p></li>
</ul>
<p>
Otherwise, the implicitly-declared copy constructor will have the form
</p>
<blockquote><pre><code>
X::X(X&amp;)
</code></pre></blockquote>
</blockquote>

<p>
After the first part of the existing paragraph 5,
insert a new paragraph as follows.
</p>

<blockquote><p><ins>
The default definition of the move constructor for a class <code>X</code>
is well-formed if and only if
</ins></p>

<ul>
<li><p><ins>
each direct or virtual base class <code>B</code> of <code>X</code>
has a move constructor or is trivially movable, and
</ins></p></li>

<li><p><ins>
each non-static member of <code>X</code>
has a move constructor or is trivially movable.
</ins></p></li>
</ul>

<p>
If the class definition does not explicitly declare a move constructor,
one will be declared implicitly if and only if
</p>
<ul>
<li><p><ins>
The default definition of the move constructor for <code>X</code> 
is well-formed, and
</ins></p></li>

<li><p><ins>
<code>X</code> does not have a user-declared copy constructor.
</ins></p></li>
</ul>
<p>
<ins>
[<i>Note:</i>
When the move constructor is not implicitly declared or explicitly supplied,
expressions that otherwise would have invoked the move constructor
will instead invoke the copy constructor.
&mdash;<i>end note</i>]
</ins>
</p></blockquote>

<p>
After the new paragraph above,
insert a new paragraph as follows.
</p>

<blockquote><p><ins>
The implicitly-declared move constructor for class <code>X</code>
will have the form
</ins></p>
<blockquote><pre><code><ins>
X::X(X&amp;&amp;)
</ins></code></pre></blockquote>
</blockquote>

<p>
Edit the second part of the existing paragraph 5 as follows.
</p>

<blockquote><p>
An implicitly-declared copy<ins>/move</ins> constructor
is an <code>inline public</code> member of its class.
An implicitly-declared copy<ins>/move</ins> constructor
for a class <code>X</code>
is defined as deleted <ins>([dcl.fct.def.delete])</ins>
if <code>X</code> has:
</p>

<ul>
<li><p>
a variant member
with a non-trivial <del>copy</del> <ins>corresponding</ins> constructor
and <code>X</code> is a union-like class
</p></li>

<li><p>
a non-static data member of class type <code>M</code> (or array thereof)
that cannot be copied<ins>/moved</ins> because overload resolution (13.3),
as applied to <code>M</code>'s
<del>copy</del> <ins>corresponding</ins> constructor,
results in an ambiguity
or a function that is deleted
or inaccessible from the implicitly-declared <del>copy</del> constructor, or
</p></li>

<li><p>
a direct or virtual base class <code>B</code>
that cannot be copied because overload resolution (13.3),
as applied to <code>B</code>'s
<del>copy</del> <ins>corresponding</ins> constructor,
results in an ambiguity
or a function that is deleted
or inaccessible from the implicitly-declared <del>copy</del> constructor.
</p></li>
</ul>
</blockquote>

<p>
Edit the existing paragraph 6 as follows.
</p>

<blockquote><p>
A copy<ins>/move</ins> constructor for class <code>X</code>
is <dfn>trivial</dfn>
if it is not user-provided (8.4) and if
</p>
<ul>
<li><p>
class <code>X</code> has no virtual functions (10.3)
and no virtual base classes (10.1), and
</p></li>
<li><p>
the constructor selected to copy<ins>/move</ins>
each direct base class subobject is trivial,
and
</p></li>
<li><p>
for each non-static data <del>memberof</del> <ins>member of</ins> <code>X</code>
that is of class type (or array thereof),
the constructor selected to copy<ins>/move</ins> that member is trivial;
</p></li>
</ul>
<p>
otherwise the copy<ins>/move</ins> constructor is non-trivial.
</p></blockquote>

<p>
After the existing paragraph 6,
add a new paragraph as follows.
</p>

<blockquote><p><ins>
An implicitly-declared copy/move constructor is explicit
if the corresponding constructor of any of its bases or non-static members
is explicit ([class.conv.ctor],[class.conv.fct]).
</ins></p></blockquote>

<p>
Edit paragraph 7 as follows.
</p>

<blockquote><p>
A non-user-provided copy<ins>/move</ins> constructor
is <dfn>implicitly defined</dfn>
if it is used to initialize an object of its class type
from a copy of an object of its class type
or of a class type derived from its class type.
[<i>Footnote:</i>
See 8.5 for more details on direct and copy initialization.
&mdash;<i>end footnote</i>]
[<i>Note:</i>
the copy<ins>/move</ins> constructor is implicitly defined
even if the implementation elided its use (12.2).
&mdash;<i>end note</i>]
A program is ill-formed
if the implicitly-defined copy<ins>/move</ins> constructor
is explicitly defaulted,
but the corresponding implicit declaration would have been deleted.
</p>

<p>
Before the non-user-provided copy<ins>/move</ins> constructor for a class
is implicitly defined,
all non-user-provided copy<ins>/move</ins> constructors
for its direct and virtual base classes and its non-static data members
shall have been implicitly defined.
[<i>Note:</i>
an implicitly-declared copy<ins>/move</ins> constructor
has an exception-specification (15.4).
An explicitly-defaulted definition <ins>([dcl.fct.def.default])</ins>
has no implicit exception-specification.
&mdash;<i>end note</i>]
</p></blockquote>

<p>
Edit paragraph 8 as follows.
</p>

<blockquote><p>
The implicitly-defined or explicitly-defaulted copy constructor
for class <code>X</code>
performs a memberwise copy of its subobjects.
<ins>The implicitly-defined or explicitly-defaulted move constructor
for class <code>X</code>
performs a memberwise move of its subobjects.
In a memberwise move,
source arguments are first statically cast
to an rvalue reference to the destination type.</ins>
[<i>Note:</i>
brace-or-equal-initializers of non-static data members are ignored.
See also the example in 12.6.2.
&mdash;<i>end note</i>]
The order of copying<ins>/moving</ins>
is the same as the order of initialization of bases and members
in a user-defined constructor (see 12.6.2).
Each subobject is copied<ins>/moved</ins> in the manner appropriate to its type:
</p>
<ul>
<li><p> 
if the subobject is of class type,
the copy<ins>/move</ins> constructor for the class is used;
</p></li>
<li><p> 
if the subobject is an array, each element is copied<ins>/moved</ins>,
in the manner appropriate to the element type;
</p></li>
<li><p> 
if the subobject is of scalar type,
the built-in assignment operator is used.
</p></li>
</ul>
<p>
Virtual base class subobjects shall be copied<ins>/moved</ins>
only once
by the implicitly-defined copy<ins>/move</ins> constructor (see 12.6.2).
</p></blockquote>

<p>
Split the existing paragraph 10 into four paragraphs,
the form part, the general part, the <code>deleted</code> part,
and the hiding/using part.
After the first form part, add a new paragraph as follows.
</p>

<blockquote><p><ins>
A user-declared move assignment operator <code>X::operator=</code>
is a non-static non-template member function of class <code>X</code>
with exactly one parameter of type <code>X&amp;&amp;</code>,
<code>const X&amp;&amp;</code>, <code>volatile X&amp;&amp;</code>
or <code>const volatile X&amp;&amp;</code>.
[<i>Note:</i>
an overloaded assignment operator
must be declared to have only one parameter; see 13.5.3.
&mdash;<i>end note</i>]
[<i>Note:</i>
more than one form of move assignment operator may be declared for a class.
&mdash;<i>end note</i>]
</ins></p></blockquote>

<p>
After the above new paragraph, add a new paragraph as follows.
</p>

<blockquote><p><ins>
The default definition of the move assignment operator
for a class <code>X</code>
is well-formed if an only if:
</ins></p>
<ul>
<li><p><ins>
each direct base class <code>B</code> of <code>X</code>
has a move assignment operator, and
</ins></p></li>
<li><p><ins>
for all the non-static data members of <code>X</code>
that are of a class type <code>M</code> (or array thereof),
each such class type has a move assignment operator.
</ins></p></li>
</ul>
<p>
<ins>
If the class definition does not explicitly declare a move assignment operator,
one will be declared implicitly if and only if
</ins>
</p>
<ul>
<li><p><ins>
the default definition of the move assignment operator is well-formed, and
</ins></p></li>
<li><p><ins>
the copy assignment operator is not user-declared.
</ins></p></li>
</ul>
<p>
<ins>
[<i>Example:</i>
The class definition
</ins>
</p>
<blockquote><pre><code>
<ins>struct S {
    int a;
    S&amp; operator=( const S&amp; ) = default;
};</ins>
</code></pre></blockquote>
<p>
<ins>
will not have a default move assignment operator implicitly declared
because the copy assignment operator has been user-declared.
The move assignment operator may be explicitly defaulted.
</ins>
</p>
<blockquote><pre><code>
<ins>struct S {
    int a;
    S&amp; operator=( const S&amp; ) = default;
    S&amp; operator=( S&amp;&amp; ) = default;
};</ins>
</code></pre></blockquote>
<p>
<ins>
&mdash;<i>end cxample</i>]
</ins>
</p>
</blockquote>

<p>
After the above new paragraph, add a new paragraph as follows.
</p>

<blockquote><p><ins>
The implicitly-declared move assignment operator for a class <code>X</code>
will have the form</ins>
</p>
<blockquote><pre><code>
<ins>X&amp; X::operator=(X&amp;&amp;)</ins>
</code></pre></blockquote>
</blockquote>

<p>
Edit the second part of the existing paragraph 10
into a new paragraph as follows.
</p>

<blockquote><p>
The implicitly-declared copy<ins>/move</ins> assignment operator
for class <code>X</code>
has the return type <code>X&amp;</code>;
it returns the object for which the assignment operator is invoked,
that is, the object assigned to.
An implicitly-declared copy<ins>/move</ins> assignment operator
is an inline public member of its class.
</p></blockquote>

<p>
Edit the third part of the existing paragraph 10
into a new paragraph as follows.
</p>

<blockquote><p>
An implicitly-declared copy<ins>/move</ins> assignment operator
for class <code>X</code>
is defined as deleted if <code>X</code> has:
</p>
<ul>
<li><p>
a variant member with a non-trivial
<del>copy</del> <ins>corresponding</ins> assignment operator
and <code>X</code> is a union-like class,
</p></li>
<li><p>
a non-static data member of const non-class type (or array thereof), or
</p></li>
<li><p>
a non-static data member of reference type, or
</p></li>
<li><p>
a non-static data member of class type <code>M</code> (or array thereof)
that cannot be copied<ins>/moved</ins> because overload resolution (13.3),
as applied to <code>M</code>'s
<del>copy</del> <ins>corresponding</ins> assignment operator,
results in an ambiguity
or a function that is deleted
or inaccessible from
the implicitly-declared <del>copy</del> assignment operator, or
</p></li>
<li><p>
a direct or virtual base class <code>B</code>
that cannot be copied because overload resolution (13.3),
as applied to <code>B</code>'s
<del>copy</del> <ins>corresponding</ins> assignment operator,
results in an ambiguity or a function
that is deleted
or inaccessible from
the implicitly-declared <del>copy</del> assignment operator.
</p></li>
</ul>
</blockquote>

<p>
Edit the fourth part of the existing paragraph 10
into a new paragraph as follows.
</p>

<blockquote><p>
Because a copy<ins>move</ins> assignment operator
is implicitly declared for a class if not declared by the user,
a base class copy<ins>/move</ins> assignment operator
is always hidden by the
<del>copy</del> <ins>corresponding</ins> assignment operator
of a derived class (13.5.3).
A using-declaration (7.3.3)
that brings in from a base class
an assignment operator with a parameter type
that could be that of a
<del>copy-assignment</del> <ins>copy/move assignment</ins> operator
for the derived class
is not considered an explicit declaration of
<ins>such</ins> <del>a copy-assignment</del> <ins>an</ins> operator
and does not suppress the implicit declaration of the derived class
<del>copy-assignment</del> operator;
the operator introduced by the using-declaration
is hidden by the implicitly-declared <del>copy-assignment</del> operator
in the derived class.
</p></blockquote>

<p>
Edit paragraph 11 as follows.
</p>

<blockquote><p>
A copy<ins>/move</ins> assignment operator
for class <code>X</code> is <dfn>trivial</dfn>
if it is not user-provided and if
</p>
<ul>
<li><p>
class <code>X</code> has no virtual functions (10.3)
and no virtual base classes (10.1), and
</p></li>
<li><p>
the assignment operator selected to copy<ins>/move</ins>
each direct base class subobject is trivial, and
</p></li>
<li><p>
for each non-static data <del>memberof</del> <ins>member of</ins> <code>X</code>
that is of class type (or array thereof),
the assignment operator selected to copy<ins>/move</ins> that member is trivial;
</p></li>
</ul>
<p>
otherwise the copy<ins>/move</ins> assignment operator
is <dfn>non-trivial</dfn>.
</p></blockquote>

<p>
Edit paragraph 12 as follows.
</p>

<blockquote><p>
A non-user-provided copy<ins>/move</ins> assignment operator
is <dfn>implicitly defined</dfn>
when an object of its class type is assigned
a value of its class type
or a value of a class type derived from its class type.
A program is ill-formed
if the implicitly-defined copy<ins>/move</ins> assignment operator
is explicitly defaulted,
but the corresponding implicit declaration would have been deleted.
Before the non-user-provided copy<ins>/move</ins> assignment operator
for a class is implicitly defined,
all non-user-provided copy assignment operators
for its direct base classes and its non-static data members
shall have been implicitly defined.
[<i>Note:</i>
an implicitly-declared copy<ins>/move</ins> assignment operator
has an exception-specification (15.4).
An explicitly-defaulted definition has no implicit exception-specification.
&mdash;<i>end note</i>]
</p></blockquote>

<p>
Edit paragraph 13 as follows.
</p>

<blockquote><p>
The implicitly-defined or explicitly-defaulted
copy<ins>/move</ins> assignment operator
for class <code>X</code> performs memberwise assignment of its subobjects.
The direct base classes of <code>X</code> are assigned first,
in the order of their declaration in the base-specifier-list,
and then the immediate non-static data members of <code>X</code> are assigned,
in the order in which they were declared in the class definition.
Each subobject is assigned in the manner appropriate to its type:
</p>
<ul>
<li><p>
if the subobject is of class type,
the <del>copy</del> <ins>corresponding</ins> assignment operator for the class
is used
(as if by explicit qualification;
that is, ignoring any possible virtual overriding functions
in more derived classes);
</p></li>
<li><p>
if the subobject is an array, each element is assigned,
in the manner appropriate to the element type;
</p></li>
<li><p>
if the subobject is of scalar type,
the built-in assignment operator is used.
</p></li>
</ul>
<p>
It is unspecified whether subobjects representing virtual base classes
are assigned more than once
by the implicitly-defined or explicitly-defaulted copy assignment operator.
[<i>Example:</i>
</p>
<blockquote><pre><code>
struct  V { };
struct  A : virtual V { };
struct  B : virtual V { };
struct  C : B, A { };
</code></pre></blockquote>
<p>
It is unspecified whether the virtual base class subobject <code>V</code>
is assigned twice by the implicitly-defined copy assignment operator for C.
&mdash;<i>end example</i>]
<ins>In contrast,
a non-trivial move assignment operator shall be invoked exactly once
for virtual base subobjects.</ins>
</p></blockquote>

<p>
Edit paragraph 14 as follows.
</p>

<blockquote><p>
A program is ill-formed
if the copy<ins>/move</ins> constructor
or the copy<ins>/move</ins> assignment operator for an object
is implicitly used
and the special member function is not accessible (Clause 11).
[<i>Note:</i>
Copying<ins>/moving</ins> one object into another
using the copy<ins>/move</ins> constructor
or the copy<ins>/move</ins> assignment operator
does not change the layout or size of either object.
&mdash;<i>end note</i>]
</p></blockquote>

<p>
Edit paragraph 14 as follows.
</p>

<blockquote><p>
When certain criteria are met,
an implementation is allowed to
omit the copy<ins>/move</ins> construction of a class object,
even if the copy<ins>/move</ins> constructor and/or destructor
for the object have side effects.
In such cases, the implementation
treats the source and target of the omitted copy<ins>/move</ins> operation
as simply two different ways of referring to the same object,
and the destruction of that object occurs
at the later of the times when the two objects would have been destroyed
without the optimization.
[<i>Footnote:</i>
Because only one object is destroyed instead of two,
and one copy<ins>/move</ins> constructor is not executed,
there is still one object destroyed for each one constructed.
&mdash;<i>end footnote</i>]
This elision of copy<ins>/move</ins> operations<ins>,
called <dfn>copy elision</dfn>,</ins>
is permitted in the following circumstances
(which may be combined to eliminate multiple copies):
</p>
<ul>
<li><p>
in a return statement in a function with a class return type,
when the expression is the name of a non-volatile automatic object
with the same cv-unqualified type as the function return type,
the copy operation can be omitted
by constructing the automatic object
directly into the function's return value
</p></li>

<li><p>
in a throw-expression,
when the operand is the name of a non-volatile automatic object,
the copy operation from the operand to the exception object (15.1)
can be omitted by constructing the automatic object
directly into the exception object
</p></li>

<li><p>
when a temporary class object that has not been bound to a reference (12.2)
would be copied<ins>/moved</ins> to a class object
with the same cv-unqualified type,
the copy<ins>/move</ins> operation can be omitted
by constructing the temporary object
directly into the target of the omitted copy<ins>/move</ins>
</p></li>

<li><p>
when the exception-declaration of an exception handler (Clause 15)
declares an object of the same type (except for cv-qualification)
as the exception object (15.1),
the copy<ins>/move</ins> operation can be omitted
by treating the exception-declaration as an alias for the exception object
if the meaning of the program will be unchanged
except for the execution of constructors and destructors
for the object declared by the exception-declaration.
</p></li>
</ul>
<p>
[<i>Example:</i>
</p>
<blockquote><pre><code>
class Thing {
public:
    Thing();
    ~Thing();
    Thing(const Thing&);
};
Thing f() {
    Thing t;
    return t;
}
Thing t2 = f();
</code></pre></blockquote>
<p>
Here the criteria for elision
can be combined to eliminate two calls
to the copy constructor of class <code>Thing</code>:
the copying of the local automatic object <code>t</code>
into the temporary object for the return value of function <code>f()</code>
and the copying of that temporary object into object <code>t2</code>.
Effectively, the construction of the local object <code>t</code>
can be viewed as directly initializing the global object <code>t2</code>,
and that object's destruction will occur at program exit.
<ins>Adding a move constructor to <code>Thing</code> has the same effect,
but it is the move construction from the temporary object to <code>t2</code>
that is elided.</ins>
&mdash;<i>end example</i>]
</p></blockquote>

<p>
Paragraph 16 is unchanged as follows.
</p>

<blockquote><p>
When the criteria for elision of a copy operation are met
and the object to be copied is designated by an lvalue,
overload resolution to select the constructor for the copy
is first performed as if the object were designated by an rvalue.
If overload resolution fails,
or if the type of the first parameter of the selected constructor
is not an rvalue reference to the object's type (possibly cv-qualified),
overload resolution is performed again, considering the object as an lvalue.
[<i>Note:</i>
This two-stage overload resolution must be performed
regardless of whether copy elision will occur.
It determines the constructor to be called if elision is not performed,
and the selected constructor must be accessible even if the call is elided.
&mdash;<i>end note</i>]
[<i>Example:</i>
<blockquote><pre><code>
class Thing {
public:
    Thing();
    ~Thing();
    Thing(Thing&amp;&amp;);
private:
    Thing(const Thing&amp;);
};
Thing f(bool b) {
    Thing t;
    if (b)
        throw t;     // OK: Thing(Thing&amp;&amp;) used (or elided) to throw t
    return t;        // OK: Thing(Thing&amp;&amp;) used (or elided) to return t
}
Thing t2 = f(false); // OK: Thing(Thing&amp;&amp;) used (or elided) to construct <del>of</del> t2
</code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
</p></blockquote>


<h3><a name="class.inhctor">12.9 Inheriting Constructors [class.inhctor]</a></h3>

<p>
Edit paragraph 3 as follows.
</p>

<blockquote><p>
For each non-template constructor
in the candidate set of inherited constructors
other than a constructor having no parameters
or a copy<ins>/move</ins> constructor having a single parameter,
a constructor is implicitly declared
with the same constructor characteristics
unless there is a user-declared constructor
with the same signature in the class where the using-declaration appears.
Similarly,
for each constructor template in the candidate set of inherited constructors,
a constructor template is implicitly declared
with the same constructor characteristics
unless there is an equivalent user-declared constructor template (14.6.6.1)
in the class where the using-declaration appears.
[<i>Note:</i>
Default arguments are not inherited.
&mdash;<i>end note</i>]
</p></blockquote>

<p>
Edit paragraph 5 as follows.
</p>

<blockquote><p>
[<i>Note:</i>
Default and copy<ins>/move</ins> constructors
may be implicitly declared as specified in 12.1 and 12.8.
&mdash;<i>end note</i>]
</p></blockquote>

<p>
Edit paragraph 6 as follows.
</p>

<blockquote><p>
[<i>Example:</i>
</p>
<blockquote><pre><code>
struct B1 {
    B1(int);
};

struct B2 {
    B2(int = 13, int = 42);
};

struct D1 : B1 {
    using B1::B1;
};

struct D2 : B2 {
    using B2::B2;
};
</code></pre></blockquote>
<p>
The candidate set of inherited constructors
in <code>D1</code> for <code>B1</code> is
</p>
<ul>
<li><p><code>B1(const B1&amp;)</code></p></li>
<li><p><ins><code>B1(B1&amp;&amp;)</code></ins></p></li>
<li><p><code>B1(int)</code></p></li>
</ul>
<p>
The set of constructors present in <code>D1</code> is
</p>
<ul>
<li><p><code>D1()</code>,
implicitly-declared default constructor, ill-formed if used</p></li>
<li><p><code>D1(const D1&amp;)</code>,
implicitly-declared copy constructor, not inherited</p></li>
<li><p><ins><code>D1(D1&amp;&amp;)</code>,
implicitly-declared move constructor, not inherited</ins></p></li>
<li><p><code>D1(int)</code>,
implicitly-declared inheriting constructor</p></li>
</ul>
<p>
The candidate set of inherited constructors
in <code>D2</code> for <code>B2</code> is
</p>
<ul>
<li><p><code>B2(const B2&amp;)</code></p></li>
<li><p><ins><code>B2(B2&amp;&amp;)</code></ins></p></li>
<li><p><code>B2(int = 13, int = 42)</code></p></li>
<li><p><code>B2(int = 13)</code></p></li>
</ul>
<p>
The set of constructors present in <code>D2</code> is
</p>
<ul>
<li><p><code>D2()</code>,
implicitly-declared default constructor, not inherited</p></li>
<li><p><code>D2(const D2&amp;)</code>,
implicitly-declared copy constructor, not inherited</p></li>
<li><p><ins><code>D2(D2&amp;&amp;)</code>,
implicitly-declared move constructor, not inherited</ins></p></li>
<li><p><code>D2(int, int)</code>,
implicitly-declared inheriting constructor</p></li>
<li><p><code>D2(int)</code>,
implicitly-declared inheriting constructor</p></li>
</ul>
<p>
&mdash;<i>end example</i>]
</p></blockquote>


<h3><a name="over.best.ics">13.3.3.1 Implicit conversion sequences [over.best.ics]</a></h3>

<p>
Edit paragraph 4 as follows.
</p>

<blockquote><p>
However, when considering the argument of a user-defined conversion function
that is a candidate by 13.3.1.3
when invoked for the copying<ins>/moving</ins> of the temporary
in the second step of a class copy-initialization,
by 13.3.1.7
when passing the initializer list as a single argument
or when the initializer list has exactly one element
and a conversion to some class <code>X</code>
or reference to (possibly cv-qualified) <code>X</code>
is considered for the first parameter of a constructor of <code>X</code>,
or by 13.3.1.4, 13.3.1.5, or 13.3.1.6 in all cases,
only standard conversion sequences
and ellipsis conversion sequences are allowed.
</p></blockquote>


<h3><a name="over.ics.user">13.3.3.1.2 User-defined conversion sequences [over.ics.user]</a></h3>

<p>
Edit paragraph 4 as follows.
</p>

<blockquote><p>
A conversion of an expression of class type to the same class type
is given Exact Match rank,
and a conversion of an expression of class type to a base class of that type
is given Conversion rank,
in spite of the fact that a copy<ins>/move</ins> constructor
(i.e., a user-defined conversion function) is called for those cases.
</p></blockquote>


<h3><a name="">13.5.3 Assignment [over.ass]</a></h3>

<p>
Paragraph 1 is unchanged.
The move assignment operator does not change the hiding.
</p>

<blockquote><p>
An assignment operator shall be implemented
by a non-static member function with exactly one parameter.
Because a copy assignment operator <code>operator=</code>
is implicitly declared for a class
if not declared by the user (12.8),
a base class assignment operator
is always hidden by the copy assignment operator of the derived class.
</p></blockquote>

<p>
Edit paragraph 2 as follows.
</p>

<blockquote><p>
Any assignment operator,
even the copy<ins>/move</ins> assignment operator,
can be virtual.
[<i>Note:</i>
for a derived class <code>D</code>
with a base class <code>B</code>
for which a virtual copy<ins>/move</ins> assignment has been declared,
the copy<ins>/move</ins> assignment operator in <code>D</code>
does not override <code>B</code>'s
virtual copy<ins>/move</ins> assignment operator.
[<i>Example:</i>
</p>
<blockquote><pre><code>
struct B {
    virtual int operator= (int);
    virtual B&amp; operator= (const B&amp;);
};

struct D : B {
    virtual int operator= (int);
    virtual D&amp; operator= (const B&amp;);
};

D dobj1;
D dobj2;
B* bptr = &amp;dobj1;
void f() {
    bptr-&gt;operator=(99);    //  calls D::operator=(int)
    *bptr = 99;             //  ditto
    bptr-&gt;operator=(dobj2); //  calls D::operator=(const B&amp;)
    *bptr = dobj2;          //  ditto
    dobj1 = dobj2;          //  calls implicitly-declared
                            //  D::operator=(const D&amp;)
}
</code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
&mdash;<i>end note</i>]
</p></blockquote>


<h3><a name="except.throw">15.1 Throwing an exception [except.throw]</a></h3>

<p>
Edit paragraph 5 as follows.
</p>

<blockquote><p>
When the thrown object is a class object,
the copy<ins>/move</ins> constructor and the destructor shall be accessible,
even if the copy<ins>/move</ins> operation is elided (12.8).
</p></blockquote>


<h3><a name="except.spec">15.4 Exception specifications [except.spec]</a></h3>

<p>
Edit paragraph 13 as follows.
</p>

<blockquote><p>
An implicitly declared special member function (Clause 12)
shall have an <var>exception-specification</var>.
If <code>f</code> is an implicitly declared
default constructor, copy constructor, <ins>move constructor,</ins>
destructor, or copy assignment operator,
its implicit <var>exception-specification</var>
specifies the <var>type-id</var> <code>T</code>
if and only if <code>T</code>
is allowed by the <var>exception-specification</var>
of a function directly invoked by <code>f</code>'s implicit definition;
<code>f</code> shall allow all exceptions
if any function it directly invokes allows all exceptions,
and <code>f</code> shall allow no exceptions
if every function it directly invokes allows no exceptions.
[<i>Example:</i>
</p>
<blockquote><pre><code>
struct A {
    A();
    A(const A&amp;) throw();
<ins>    A(A&amp;&amp;) throw();</ins>
    ~A() throw(X);
};
struct B {
    B() throw();
    B(const B&amp;) throw();
<ins>    B(B&amp;&amp;) throw(Y);</ins>
    ~B() throw(Y);
};
struct D : public A, public B {
    // Implicit declaration of D::D();
    // Implicit declaration of D::D(const D&amp;) throw();
<ins>    // Implicit declaration of D::D(D&amp;&amp;) throw(Y);</ins>
    // Implicit declaration of D::~D() throw(X,Y);
};
</code></pre></blockquote>
<p>
Furthermore,
if <code>A::~A()</code> or <code>B::~B()</code> were virtual,
<code>D::~D()</code> would not be as restrictive as that of <code>A::~A</code>,
and the program would be ill-formed
since a function that overrides a virtual function from a base class
shall have an <var>exception-specification</var>
at least as restrictive as that in the base class.
&mdash;<i>end example</i>]
</p></blockquote>


<h3><a name="structure.specifications">17.5.1.4 Detailed Specifications [structure.specifications]</a></h3>

<p>
Edit paragraph 2 as follows.
</p>

<blockquote><p>
Descriptions of class member functions follow the order (as appropriate):
[<i>Footnote:</i>
To save space, items that do not apply to a class are omitted.
For example, if a class does not specify any comparison functions,
there will be no "Comparison functions" subclause.
&mdash;<i>end footnote</i>]
</p>
<ul>
<li><p>constructor(s) and destructor</p></li>
<li><p>copying<ins>/moving</ins> &amp; assignment functions</p></li>
<li><p>comparison functions</p></li>
<li><p>modifier functions</p></li>
<li><p>observer functions</p></li>
<li><p>operators and other non-member functions</p></li>
</ul>
</blockquote>


<h3><a name="functions.within.classes">17.5.2.2 Functions within classes [functions.within.classes]</a></h3>

<p>
Edit paragraph 1 as follows.
</p>

<blockquote><p>
For the sake of exposition,
Clauses 18 through 30 and Annex D
do not describe copy<ins>/move</ins> constructors, assignment operators,
or (non-virtual) destructors
with the same apparent semantics
as those that can be generated by default (12.1, 12.4, 12.8).
</p></blockquote>


<h3><a name="type.index.overview">18.7.2.1 type_index overview [type.index.overview]</a></h3>

<p>
Edit the synopsis as follows.
</p>

<blockquote><pre><code>
namespace std {
  class type_index {
  public:
     type_index(const type_info&amp; rhs);
     bool operator==(const type_index&amp; rhs) const;
     bool operator!=(const type_index&amp; rhs) const;
     bool operator&lt; (const type_index&amp; rhs) const;
     bool operator&lt;= (const type_index&amp; rhs) const;
     bool operator&gt; (const type_index&amp; rhs) const;
     bool operator&gt;= (const type_index&amp; rhs) const;
     size_t hash_code() const;
     const char* name() const;
  private:
     const type_info* target;         // exposition only
     // Note that the use of a pointer here, rather than a reference,
     // means that the default copy<ins>/move</ins> constructor and assignment
     // operator will be provided and work as expected.
  };
}
</code></pre></blockquote>


<h3><a name="propagation">18.8.5 Exception Propagation [propagation]</a></h3>

<p>
Edit paragraph 2 as follows.
Note that we do not require exceptions to be movable.
</p>

<blockquote><p>
<code>exception_ptr</code> shall be
DefaultConstructible, CopyConstructible,
<ins>Copy</ins>Assignable and EqualityComparable.
<code>exception_ptr</code>'s operations shall not throw exceptions.
</p></blockquote>

<p>
Paragraph 7 is unchanged.
That is, move constructors cannot throw an exception
as per the general rule.
</p>

<blockquote><p>
<i>Returns:</i>
An <code>exception_ptr</code> object
that refers to the currently handled exception (15.3)
or a copy of the currently handled exception,
or a null <code>exception_ptr</code> object if no exception is being handled.
The referenced object shall remain valid
at least as long as there is an <code>exception_ptr</code> object
that refers to it.
If the function needs to allocate memory and the attempt fails,
it returns an <code>exception_ptr</code> object
that refers to an instance of <code>bad_alloc</code>.
It is unspecified whether the return values
of two successive calls to <code>current_exception</code>
refer to the same exception object.
[<i>Note:</i>
that is, it is unspecified whether
<code>current_exception</code> creates a new copy each time it is called.
&mdash;<i>end note</i>]
If the attempt to copy the current exception object throws an exception,
the function returns an <code>exception_ptr</code> object
that refers to the thrown exception
or, if this is not possible, to an instance of <code>bad_exception</code>.
[<i>Note:</i>
The copy constructor of the thrown exception may also fail,
so the implementation is allowed to
substitute a <code>bad_exception</code> object
to avoid infinite recursion.
&mdash;<i>end note</i>]
</p></blockquote>



<h3><a name="utility.arg.requirements">20.1.1 Template argument requirements [utility.arg.requirements]</a></h3>

<p>
The changes in this section are relative to working draft
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2723.pdf">N2723</a>.
</p>

<p>
Edit table 33 as follows.
<p>

<blockquote><table>
<caption>
Table 33 &mdash; <code>MoveConstructible</code> requirements [moveconstructible]
</caption>
<thead>
<tr>
<th>Expression</th>
<th>Post-condition</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>T t = <del>rv</del> <ins>std::move(y)</ins></code></td>
<td><del><code>t</code> is equivalent to
the value of <code>rv</code> before the construction</del>
<ins>The value of <code>t</code>
is equivalent to that of <code>y</code> before construction.
Either <code>y</code> is unchanged
or the construction shall not throw.</ins></td>
</tr>
<tr>
<td colspan=2>
<del>
[<i>Note:</i>
There is no requirement on the value of <code>rv</code> after the construction.
&mdash;<i>end note</i>]
</del></td>
</tr>
</tbody>
</table></blockquote>

<p>
Edit table 34 as follows.
<p>

<blockquote><table>
<caption>
Table 34 &mdash; <code>CopyConstructible</code> requirements [copyconstructible]
</caption>
<thead>
<tr>
<th>Expression</th>
<th>Post-condition</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>T t = <del>u</del> <ins>y</ins></code></td>
<td><del>the value of <code>u</code>
is unchanged and equivalent to <code>t</code></del>
<ins>The value of <code>t</code>
is equivalent to that of <code>y</code>,
which is unchanged.</ins></td>
</tr>
<tr>
<td><ins><code>T t = std::move(y)</code></ins></td>
<td><ins>The value of <code>t</code>
is equivalent to that of <code>y</code> before construction.
Either <code>y</code> is unchanged
or the construction shall not throw.</ins></td>
</tr>
<tr>
<td colspan=2>
[<i>Note:</i>
A type that satisfies the <code>CopyConstructible</code>
requirements also satisfies the <code>MoveConstructible</code> requirements.
&mdash;<i>end note</i>]
</td>
</tr>
</tbody>
</table></blockquote>

<p>
Edit table 35 as follows.
<p>

<blockquote><table>
<caption>
Table 35 &mdash; <code>MoveAssignable</code> requirements [moveassignable]
</caption>
<thead>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Return value</th>
<th>Post-condition</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>t = <del>rv</del> <ins>std::move(y)</ins></code></td>
<td><code>T&amp;</code></td>
<td><code>t</code></td>
<td><del><code>t</code> is equivalent to
the value of <code>rv</code> before the assignment</del>
<ins>The value of <code>t</code>
is equivalent to that of <code>y</code> before construction.
Either <code>y</code> is unchanged
or the construction shall not throw.</ins></td>
</tr>
<tr>
<td colspan=4>
<del>
[<i>Note:</i>
There is no requirement on the value of <del><code>rv</code></del>
<ins><var>r_value</var></ins> after the assignment.
&mdash;<i>end note</i>]
</del>
</td>
</tr>
</tbody>
</table></blockquote>

<p>
Edit table 36 as follows.
<p>

<blockquote><table>
<caption>
Table 36 &mdash; <code>CopyAssignable</code> requirements [copyassignable]
</caption>
<thead>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Return value</th>
<th>Post-condition</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>t = <del>u</del> <ins>y</ins></code></td>
<td><code>T&amp;</code></td>
<td><code>t</code></td>
<td><del><code>t</code> is equivalent to <code>u</code>,
the value of <code>u</code> is unchanged</del>
<ins>The value of <code>t</code>
is equivalent to that of <code>y</code>,
which is unchanged.</ins></td>
</tr>
<tr>
<td><ins><code>t = std::move(y)</code></ins></td>
<td><code>T&amp;</code></td>
<td><code>t</code></td>
<td><ins>The value of <code>t</code>
is equivalent to that of <code>y</code> before construction.
Either <code>y</code> is unchanged
or the construction shall not throw.</ins></td>
</tr>
<tr>
<td colspan=4>
[<i>Note:</i>
A type that satisfies the <code>CopyAssignable</code>
requirements also satisfies the <code>MoveAssignable</code> requirements.
&mdash;<i>end note</i>]
</td>
</tr>
</tbody>
</table></blockquote>


<h3><a name="meta.type.synop">20.6.2 Header &lt;type_traits&gt; synopsis [meta.type.synop]</a></h3>

<p>
Edit within the synopsis as follows.
</p>

<blockquote><pre><code>
// 20.6.4.3, type properties:
template &lt;class T&gt; struct is_const;
template &lt;class T&gt; struct is_volatile;
template &lt;class T&gt; struct is_trivial;
template &lt;class T&gt; struct is_standard_layout;
template &lt;class T&gt; struct is_pod;
template &lt;class T&gt; struct is_empty;
template &lt;class T&gt; struct is_polymorphic;
template &lt;class T&gt; struct is_abstract;
template &lt;class T&gt; struct has_trivial_default_constructor;
template &lt;class T&gt; struct has_trivial_copy_constructor;
<ins>template &lt;class T&gt; struct has_trivial_move_constructor;</ins>
template &lt;class T&gt; struct has_trivial_<ins>copy_</ins>assign;
<ins>template &lt;class T&gt; struct has_trivial_move_assign;</ins>
template &lt;class T&gt; struct has_trivial_destructor;
template &lt;class T&gt; struct has_nothrow_default_constructor;
template &lt;class T&gt; struct has_nothrow_copy_constructor;
<ins>template &lt;class T&gt; struct has_nothrow_move_constructor;</ins>
<ins>template &lt;class T, class ...Args&gt; struct is_nothrow_constructible;</ins>
template &lt;class T&gt; struct has_nothrow_<ins>copy_</ins>assign;
<ins>template &lt;class T&gt; struct has_nothrow_move_assign;</ins>
template &lt;class T&gt; struct has_virtual_destructor;
template &lt;class T&gt; struct is_signed;
template &lt;class T&gt; struct is_unsigned;
template &lt;class T&gt; struct alignment_of;
template &lt;class T&gt; struct rank;
template &lt;class T, unsigned I = 0&gt; struct extent;
</code></pre></blockquote>


<h3><a name="meta.unary.prop">20.6.4.3 Type properties [meta.unary.prop]</a></h3>

<p>
Edit within Table 33 as follows.
</p>

<blockquote><table>
<caption>
Table 33 &mdash; Type property predicates
</caption>
<thead>
<tr>
<th>Template</th>
<th>Condition</th>
<th>Preconditions</th>
</tr>
</thead>

<tbody>
<tr>
<td>....</td>
<td>....</td>
<td>....</td>
</tr>

<tr>
<td><code>template &lt;class T&gt;
struct has_trivial_copy_constructor;</code></td>
<td><code>T</code> is a trivial type (3.9)
or a reference type or a class type
whose copy constructors (12.8) are all trivial.</td>
<td><code>T</code> shall be a complete type, an array of unknown bound,
or (possibly cv-qualified) <code>void</code>.</td>
</tr>

<tr>
<td><ins><code>template &lt;class T&gt;
struct has_trivial_move_constructor;</code></ins></td>
<td><ins><code>T</code> is a trivial type (3.9)
or a reference type or a class type
whose move constructors (12.8) are all trivial.</ins></td>
<td><ins><code>T</code> shall be a complete type, an array of unknown bound,
or (possibly cv-qualified) <code>void</code>.</ins></td>
</tr>

<tr>
<td><code>template &lt;class T&gt;
struct has_trivial_<ins>copy_</ins>assign;</code></td>
<td><code>T</code> is neither <code>const</code> nor a reference type,
and <code>T</code> is a trivial type (3.9) or a class type
whose copy assignment operators (12.8) are all trivial.</td>
<td><code>T</code> shall be a complete type, an array of unknown bound,
or (possibly cv-qualified) <code>void</code>.</td>
</tr>

<tr>
<td><ins><code>template &lt;class T&gt;
struct has_trivial_move_assign;</code></ins></td>
<td><ins><code>T</code> is neither <code>const</code> nor a reference type,
and <code>T</code> is a trivial type (3.9) or a class type
whose move assignment operators (12.8) are all trivial.</ins></td>
<td><ins><code>T</code> shall be a complete type, an array of unknown bound,
or (possibly cv-qualified) <code>void</code>.</ins></td>
</tr>

<tr>
<td>....</td>
<td>....</td>
<td>....</td>
</tr>

<tr>
<td><code>template &lt;class T&gt;
struct has_nothrow_copy_constructor;</code></td>
<td><code>has_trivial_copy_constructor&lt;T&gt;::value</code> is true
or <code>T</code> is a class type whose copy constructors
are all known not to throw any exceptions
or <code>T</code> is an array of such a class type.</td>
<td><code>T</code> shall be a complete type, an array of unknown bound,
or (possibly cv-qualified) <code>void</code>.</td>
</tr>

<tr>
<td><ins><code>template &lt;class T&gt;
struct has_nothrow_move_constructor;</code></ins></td>
<td><ins><code>has_trivial_move_constructor&lt;T&gt;::value</code> is true
or <code>T</code> is a class type whose move constructors
are all known not to throw any exceptions
or <code>T</code> is an array of such a class type.</ins></td>
<td><ins><code>T</code> shall be a complete type, an array of unknown bound,
or (possibly cv-qualified) <code>void</code>.</ins></td>
</tr>

<tr>
<td><code>template &lt;class T&gt;
struct has_nothrow_<ins>copy_</ins>assign;</code></td>
<td><code>T</code> is neither <code>const</code> nor a reference type,
and <code>has_trivial_<ins>copy_</ins>assign&lt;T&gt;::value</code> is true
or <code>T</code> is a class type
whose copy assignment operators
taking an lvalue of type <code>T</code>
are all known not to throw any exceptions
or <code>T</code> is an array of such a class type.</td>
<td><code>T</code> shall be a complete type, an array of unknown bound,
or (possibly cv-qualified) <code>void</code>.</td>
</tr>

<tr>
<td><ins><code>template &lt;class T&gt;
struct has_nothrow_move_assign;</code></ins></td>
<td><ins><code>T</code> is neither <code>const</code> nor a reference type,
and <code>has_trivial_move_assign&lt;T&gt;::value</code> is true
or <code>T</code> is a class type
whose move assignment operators
taking an lvalue of type <code>T</code>
are all known not to throw any exceptions
or <code>T</code> is an array of such a class type.</ins></td>
<td><ins><code>T</code> shall be a complete type, an array of unknown bound,
or (possibly cv-qualified) <code>void</code>.</ins></td>
</tr>

<tr>
<td><ins><code>template &lt;class T, class ...Args&gt;
struct is_nothrow_constructible;</code></ins></td>
<td><ins>The expression <code>T(Args...)</code>
is known not to throw any exceptions.</ins></td>
<td><ins><code>T</code> shall be a complete type.</ins></td>
</tr>

<tr>
<td>....</td>
<td>....</td>
<td>....</td>
</tr>

</tbody>
</table></blockquote>


<h3><a name="refwrap">20.7.5 Class template reference_wrapper [refwrap]</a></h3>

<p>
Edit paragraph 1 as follows.
</p>

<blockquote><p>
<code>reference_wrapper&lt;T&gt;</code>
is a CopyConstructible and <ins>Copy</ins>Assignable wrapper
around a reference to an object of type <code>T</code>.
</p></blockquote>


<h3><a name="func.bind.place">20.7.12.1.4 Placeholders [func.bind.place]</a></h3>

<p>
Edit paragraph 1 as follows.
</p>

<blockquote><p>
All placeholder types
shall be <code>DefaultConstructible</code> and <code>CopyConstructible</code>,
and their default constructors and copy<ins>/move</ins> constructors
shall not throw exceptions.
It is implementation defined whether
placeholder types are <code><ins>Copy</ins>Assignable</code>.
<code><ins>Copy</ins>Assignable</code> placeholders' copy assignment operators
shall not throw exceptions.
</p></blockquote>


<h3><a name="util.smartptr.shared">20.8.13.2 Class template shared_ptr [util.smartptr.shared]</a></h3>

<p>
Edit paragraph 2 as follows.
</p>

<blockquote><p>
Specializations of <code>shared_ptr</code>
shall be CopyConstructible, <ins>Copy</ins>Assignable, and LessThanComparable,
allowing their use in standard containers.
Specializations of <code>shared_ptr</code>
shall be convertible to <code>bool</code>,
allowing their use in boolean expressions and declarations in conditions.
The template parameter <code>T</code> of <code>shared_ptr</code>
may be an incomplete type.
</p></blockquote>


<h3><a name="util.smartptr.weak">20.8.13.3 Class template weak_ptr [util.smartptr.weak]</a></h3>

<p>
Edit paragraph 2 as follows.
</p>


<blockquote><p>
Specializations of <code>weak_ptr</code>
shall be CopyConstructible, <ins>Copy</ins>Assignable, and LessThanComparable,
allowing their use in standard containers.
Specializations of <code>weak_ptr</code>
shall be convertible to <code>bool</code>,
allowing their use in boolean expressions and declarations in conditions.
The template parameter <code>T</code> of <code>weak_ptr</code>
may be an incomplete type.
</p></blockquote>


<h2><a name="Acknowledgments">Acknowledgments</a></h2>

<p>
Howard Hinnant provided many helpful comments on drafts of this paper.
</p>

</body>
</html>
