<html>
<head>
<title>Defaulted and Deleted Functions</title>
</head>

<body>
<h1>Defaulted and Deleted Functions</h1>

<p>ISO/IEC JTC1 SC22 WG21 N2346 = 07-0206 - 2007-07-19

<p>Lawrence Crowl, Lawrence@Crowl.org, crowl@google.com

<p>This document is a revision of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2326.html">
N2326</a> = 07-0186 - 2007-06-22.

<h2>Overview</h2>

<p>We propose a syntax and semantics
for explicitly using the default definition of a function.
We also propose a syntax and semantics
for deleting the definition of an otherwise visible function.

<ul>
<li><a href="#problem">Problem Description</a></li>
<li><a href="#prior">Prior Approaches</a><ul>
    <li><a href="#classusing">Class Scope Using Declarations
                              and Private Members</a></li>
    <li><a href="#explicit">Explicit Classes and Default Definitions</a></li>
    <li><a href="#listdflts">List of Class Defaults</a></li>
    <li><a href="#prohibited">Prohibited Access Specifier</a></li>
    </ul></li>
<li><a href="#solution">Proposed Solution</a><ul>
    <li><a href="#default">Default Function Definition</a><ul>
        <li><a href="#trivial">Trivial Definitions</a></li>
        <li><a href="#exception">Exception Specification</a></li>
        <li><a href="#nonimplicit">Non-Implicit Defaults</a></li>
        </ul></li>
    <li><a href="#delete">Delete Function Definition</a><ul>
        <li><a href="#features">Disabling Language Features</a></li>
        <li><a href="#conversions">Disabling Undesired Conversions</a></li>
        </ul></li>
    <li><a href="#comparison">Comparison to Prior Approaches</a></li>
    </ul></li>
<li><a href="#usecase">Use Case - Atomic Types</a></li>
<li><a href="#changes">Changes to the Standard</a><ul>
    <li><a href="#opnew">5.3.4 New [expr.new]</a></li>
    <li><a href="#definitions">8.4 Function definitions [dcl.fct.def]</a></li>
    <li><a href="#initializers">8.5 Initializers [dcl.init]</a></li>
    <li><a href="#aggregates">8.5.1 Aggregates [dcl.init.aggr]</a></li>
    <li><a href="#classes">9 Classes [class]</a></li>
    <li><a href="#members">9.2 Class members [class.mem]</a></li>
    <li><a href="#override">10.3 Virtual functions [class.virtual]</a></li>
    <li><a href="#constructors">12.1 Constructors [class.ctor]</a></li>
    <li><a href="#destructors">12.4 Destructors [class.dtor]</a></li>
    <li><a href="#initializing">12.6.2 Initializing bases and members [class.base.init]</a></li>
    <li><a href="#copying">12.8 Copying class objects [class.copy]</a></li>
    <li><a href="#special">14.7.3 Explicit specialization [temp.expl.spec]</a></li>
    <li><a href="#compat">C.1.8 Clause 12: special member functions [diff.special]</a></li>
    </ul></li>
</ul>



<h2><a name="problem">Problem Description</a></h2>

<p>By default, C++ provides four default special member functions:
<ul>
<li>destructor</li>
<li>default constructor</li>
<li>copy constructor</li>
<li>copy assignment <code>operator =</code></li>
</ul>
Users may override these defaults.

<p>Also by default, C++ applies several global operators to classes:
<ul>
<li>sequence <code>operator ,</code></li>
<li>address-of <code>operator &amp;</code></li>
<li>indirection <code>operator *</code></li>
<li>member access <code>operator -&gt;</code></li>
<li>member indirection <code>operator -&gt;*</code></li>
<li>free-store allocation <code>operator new</code></li>
<li>free-store deallocation <code>operator delete</code></li>
</ul>
Users may provide class-specific operators.

<p>The management of defaults has several problems:
<ul>
<li>Constructor definitions are coupled;
declaring any constructor suppresses the default constructor.</li>
<li>The destructor default is inappropriate to polymorphic classes,
requiring an explicit definition.</li>
<li>Once a default is suppressed, there is no means to resurrect it.</li> 
<li>Default implementations are often more efficient
than manually specified implementations.</li>
<li>Non-default implementations are non-trivial,
which affects type semantics,
e.g. makes a type non-POD.</li>
<li>There is no means to prohibit a special member function or global operator
without declaring a (non-trivial) substitute.</li>
</ul>

<p>The most common encounter with these problems
is when disabling copying of a class.
The accepted technique is to
declare a private copy constructor and a private copy assignment operator,
and then fail to define either.
Unfortunately, the type becomes non-POD
and its default constructor must be explicitly written.
Further,
while diagnostics for non-friend uses are relatively straightforward,
the diagnostics for friend uses are deferred to link time
and a cryptic a <q>missing symbol</q> message.

<p>The specific problem of concisely ensuring that a class is non-copyable
has received attention from <a href="http://www.boost.org/">Boost</a>.
See the
<a href="http://www.boost.org/libs/utility/utility.htm#Class_noncopyable">
documentation</a> and
<a href="http://www.boost.org/boost/noncopyable.hpp">header</a>
for the boost::noncopyable mixin.
This mixin works,
though not with entirely satisfactory results.
First, the mechanism uses a base class,
which under the current language makes the class non-POD.
Second, the error messages can be somewhat misleading.

<p>Any successful solution to these problems
must be relatively easy to learn and implement.



<h2><a name="prior">Prior Approaches</a></h2>

<p>The problems of defaults
has been addressed via four primary approaches,
as described below.
These approaches have significant overlap,
but none provide all of the capabilities of any of the others.


<h3><a name="classusing">Class Scope Using Declarations and Private Members</a></h3>

<p> In
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1602.pdf">
<cite>N1602 Class Scope Using Declarations &amp; private Members</cite></a>,
Francis Glassborow notes that some programmers make problematic
overloads private members to prevent their use.
This approach makes using valid overloads in derived classes an error,
thus inhibiting the technique.
He proposes defering the error diagnostic to the point where a private
overload is selected in a call.

<h3><a name="explicit">Explicit Classes and Default Definitions</a></h3>

<p>In
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1717.pdf">
<cite>N1717 explicit class and default definitions</cite></a>,
Francis Glassborow and Lois Goldthwaite
define syntax to indicate that
a class has none of the four default special member functions
and then to explicitly resurrect the desired defaults.
The paper proposed no change to the default application of global operators.

<p>The explicit class approach
has a significant syntactic burden
for removing a single special member function --
remove them all and rewrite the declarations for the others.
This approach encourages a view that explicit classes are inherently different,
rather than a restriction of regular classes.

<p>The paper states that
<blockquote>
Special member functions
which have been explicitly declared and default-defined
are never trivial.
Therefore an explicit class can never be a POD,
even if its special member functions are default-defined.
(The justification for this restriction
is that the semantics of a class should not change
if its inline default-defined functions are moved out of line.)
</blockquote>
However, this is too much of a restriction.
An inline default-defined function should be trivial
if and only if the implicit definition would be trivial.
Of course, non-inline definitions should be non-trivial.
In essence, we agree with the justification,
but not the restriction.
Fortunately, subsequent work on the definition of PODs
by Beman Dawes in
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2294.html">
<cite>N2294 POD's Revisited;
Resolving Core Issue 568 (Revision 4)</cite></a>)
provides tools to revisit this issue.

<p>The syntax suggested in N1717 for explicit defaults
permits simultaneous specification of a member initializer list,
which is clearly not right.
Rather than add additional restrictive text,
a restrictive syntax is preferable.

<p>The paper left incomplete the specification that
an explicit class without a copy constructor
is deemed to have an inaccessible copy constructor.
This specification was intended to avoid reverse slicing,
where only a sub-object is initialized.
The situation is similar for copy assignment operators.


<h3><a name="listdflts">List of Class Defaults</a></h3>

<p>In
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1890.pdf">
<cite>N1890 Initialization and Initializers</cite></a> section 7,
as elaborated in the draft
<a href="http://wiki.dinkumware.com/twiki/pub/Wg21portland/EvolutionWorkingGroup/controlofdefaults.pdf">
<cite>Control of class defaults</cite></a>,
Bjarne Stroustrup
describes a syntax for controlling defaults,
with more goals than
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1717.pdf">
N1717</a>.
These goals include not only controlling member defaults,
but also controlling the application of global operators,
other possible default implementations,
and control of inheritance.

<p>The paper's proposed syntax is very terse,
and requires a mental mapping from the short codes
of the default control list to the actual functions.
For the most part, this mapping is straightforward,
but still must be memorized.
Further, its different syntactic style will slow adoption
by users and compiler vendors.

<p>In contrast to
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1717.pdf">
N1717</a>,
the paper provides no mechanism
to define a non-inline member using the default definition.

<p>The paper also includes mechanisms for controlling
<q>class defaults</q>,
which essentially involve inheritance.
<ul>
<li>Member functions are non-virtual by default.</li>
<li>Member functions are non-pure by default.</li>
<li>Classes are inheritable by default.</li>
<li>Virtual member functions are overridable by default.</li>
</ul>
In the current language:
<ul>
<li>member functions are easily made virtual, but only individually;</li>
<li>it is possible to prevent inheritance of a class,
but not also allocate variables of that class; and</li>
<li>there is no mechanism to prevent virtual overriding.</li>
</ul>
The paper addresses these inheritance issues as well.


<h3><a name="prohibited">Prohibited Access Specifier</a></h3>

<p>In
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2123.html">
<cite>N2123 Adding the prohibited access specifier to C++09</cite></a>
Alisdair Meredith
describes a <code>prohibited</code> access specifier
that disables undesired operations within classes.
This notion was first introduced by
Daveed Vandevoorde in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1964.pdf">
<cite>N1964 Modules in C++ (revision 3)</cite></a>.

<p>The proposal also enables defining prohibited conversions
via declaration of a prohibited overload.
This aspect of the proposal is probably the most significant,
as it extends into user-defined operations
and addresses a major weakness in C++, agressive conversion.

<p> The technique works because the prohibited functions are still visible.
Syntactically, the specifier also applies to other data members,
for which it does not make sense and requires additional rules.
A more precise mechanism is desirable.

<p>Furthermore, the access specifier does not work for free functions.
This missing feature seems like such an obvious next step
that its absence will be felt.

<p>The <code>prohibited</code> keyword is new,
which will break some programs.
A Google code search yields about 500 hits.
Sensibly reusing an existing keyword will not affect existing programs.

<p>Unlike
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1717.pdf">
N1717</a>,
the paper does not propose a means to specify
non-inline default implementations.
Unlike
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1890.pdf">
N1890</a>,
the paper does not propose a means to specify
default implementations for functions that have no implicit default.



<h2><a name="solution">Proposed Solution</a></h2>

<p>We propose to define two new mechanisms
to explicitly use the default definition of a function
and to delete a function definition.
This solution
<ul>
<li>provides for full control of special member function defaults,</li>
<li>provides maximally trivial special member function definitions
(thus obtaining maximum benefit from
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2294.html">
N2294</a>),</li>
<li>does not require modification of class syntax,</li>
<li>does not introduce new keywords,</li>
<li>does not apply syntactically to data, and</li>
<li>applies to free functions as well as member functions.</li>
</ul>

<p>Syntactically, the proposal uses
<q><code>=default;</code></q> and <q><code>=delete;</code></q>
in alternate rules for <var>function-definition</var>.
We considered the forms
<q><code>default;</code></q>, as suggested by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1717.pdf">
N1717</a>, and
<q><code>{default}</code></q>, as adopted by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1717.pdf">
N1717</a>,
but chose not to use them.
The reasons are that the former introduces
more choice points into the parse of declarations,
while the second introduces either
more choice points in the parse of function blocks
or substantial lookahead to determine that the syntax
<q><code>{default}</code></q> is not a function block.


<h3><a name="default">Default Function Definition</a></h3>

<p>The definition form <q><code>=default;</code></q>
indicates that the function's default definition should be used.
As expected, this works when the definition is inside the class body,
but it also works when the definition is outside the class body,
but as with the current language,
you must declare the function within the class body.

<blockquote><pre><code>
struct type
{
    type() = default; // commonly specified redundancy is now efficent
    virtual ~type(); // virtual requires a declaration
    type( const type &amp; ); // a simple declaration, but
};
inline type::type( const type &amp; ) = default; // now efficient
type::~type() = default; // a non-inline default definition
</code></pre></blockquote>

<h4><a name="trivial">Trivial Definitions</a></h4>

<p>Critical to exploiting the benefits of
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2294.html">
N2294</a>,
a explicitly-defaulted definition within its class is trivial
if and only if the implicit definition would have been trivial.

<blockquote><pre><code>
struct type
{
    type() = default; // trivial
    virtual ~type() = default; // non-trivial because virtual
    type &amp; operator =( const type &amp; ); // non-trivial
    // because not defaulted here
};
inline type &amp; type::operator =( const type &amp; ) = default;
</code></pre></blockquote>

<p>Non-inline definitions may also be defaulted.

<blockquote><pre><code>
struct type
{
    type( const type &amp; ); // not defaulted here
};
type::type( const type &amp; ) = default;
</code></pre></blockquote>

<p>This rule enables efficient execution and concise definition
while enabling a stable binary interface to an evolving implementation.
That is, the machine-level calling sequence remains unchanged
even when the definition changes to a non-default.
For example, consider the header

<blockquote><pre><code>
type.h : struct type { int x; type(); };
</code></pre></blockquote>

<p>and two (mutually exclusive) definitions as the software evolves,

<blockquote><pre><code>
type1.cc : type::type() = default;
type2.cc : type::type() { x = 3; }
</code></pre></blockquote>

<p>In some cases, the class body can change without
requiring a change in member function definition
because the default changes with declaration of additional members.

<h4><a name="exception">Exception Specification</a></h4>

<p>Unlike the implicit default,
the explicit default has normal exception specification semantics.
This inconsistency seems at the surface to be undesireable.
The reason for the change in semantics is twofold.
First, if the explicit default used the implicit exception specification,
there would be no syntax to get back to a <q>throws anything</q> state.
Second, the users of a function
cannot tell if it is defaulted when it is non-inline,
as in the example above.
It would be undesirable to have semantics of use
change due to a change in implementation.
So, the explicit declaration needs to have the the normal
exception semantics.
Users desiring precisely the same exception specification
as the implicit declaration
must specify it.
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1717.pdf">
N1717</a>
reached the same conclusion.

<h4><a name="nonimplicit">Non-Implicit Defaults</a></h4>

<p>So far, this proposal has shown
how to make explicit the implicit default definition.
There is another opportunity,
which is to use a default implementation that is not implicit.
For example,
consider the equality operator.
There is no default equality operator,
but an explicit default definition
would be able to use a standard-defined, if not implicit, default definition.

<blockquote><pre><code>
struct type
{
    bool operator ==( const &amp; type ) = default;
    bool operator !=( const &amp; type ) = default;
};
</code></pre></blockquote>

<p>Indeed, there are several potential operations
that could have non-implicit default implementations.
However, this paper proposes none.
We believe that at this point in the standards process,
such defaults are best left to a technical report.
However, should such a technical report be forthcoming,
the syntax is ready.


<h3><a name="delete">Delete Function Definition</a></h3>

<p>The definition form <q><code>=delete;</code></q>
indicates that the function may not be used.
However, all lookup and overload resolution
occurs before the deleted definition is noted.
That is, it is the definition that is deleted, not the symbol;
overloads that resolve to that definition are ill-formed.

<p>The primary power of this approach is twofold.
First, use of default language facilities can be made an error
by deleting the definition of functions that they require.
Second, problematic conversions can be made an error
by deleting the definition for the offending conversion
(or overloaded function).

<p>This approach of checking for a delete definition late
has two benefits.
First, it achieves the goal of making a bad overload visible.
Second, it is relativley easy to implement,
requiring no change to the already complicated lookup and overload rules.

<p>The deleted definition of a function must be its first declaration.
This rule prevents inconsistency in interpretation.

<p>The deleted definition is an inline definition,
thus requiring consistent definition throughout the program
via the one-definition rule.

<p>The deleted definition mechanism is orthogonal to access specifiers,
though accessibility is somewhat moot if the function has been deleted.

<p>Deleted functions are trivial.
This rule is necessary to obtain maximum benefit from
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2294.html">
N2294</a>.

<p>One can define a template with a deleted definition.
Specialization and argument deduction occur
as they would with a regular template function,
but explicit specialization is not permitted.

<p>One cannot use a deleted function in a <code>sizeof</code> expression.
We believe the existing language rules will prevent this.

<p>A deleted virtual function may not override a non-deleted virtual function
and vice-versa.

<h4><a name="features">Disabling Language Features</a></h4>

<p>The canonical example of disabling language features is disabling copying.
Simply declare the copy assignment operator and the copy constructor
with deleted definitions.
Because a declaration of any constructor disables the default constructor,
a programmer may choose to add it back with its default definition.

<blockquote><pre><code>
struct type
{
    type &amp; operator =( const type &amp; ) = delete;
    type( const type &amp; ) = delete;
    type() = default;
};
</code></pre></blockquote>

<p>We avoid the problem of reverse slicing identified in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1717.pdf">
N1717</a>
because the declaration for a deleted definition still hides the
base-class copy constructor.

<p>A more subtle example involves
indirectly controlling the allocation of a type.
Deleting the definition of a class-specific <code>operator new</code>
will prevent allocation in free store
because <code>new</code> expressions
involving <code>type</code> will be ill-formed.

<blockquote><pre><code>
struct type {
    void * operator new( std::size_t ) = delete;
};
</code></pre></blockquote>

<p>In contrast,
deleting the definition of a destructor
will require allocation in free store
because static and automatic variables implicitly call the destructor.

<blockquote><pre><code>
struct type {
    ~type() = delete; // disable destructor
};
</code></pre></blockquote>

Unfortunately, the approach also prevents deleting a free-store object,
thus either limiting its use to singletons
or requiring the employment of a garbage collector.

<h4><a name="conversions">Disabling Undesired Conversions</a></h4>

<p>Removing dangerous conversions
is as important as removing undesired language defaults.

<blockquote><pre><code>
struct type
{
    type( long long ); // can initialize with an long long
    type( long ) = delete; // but not anything less
};
extern void bar( type, long long ); // and the same for bad overloads
void bar( type, long ) = delete; // of free functions
</code></pre></blockquote>

<p>Of considerable note
is the interaction of explicit constructors and explicit conversion operators
with deleted definitions.
(Lois Goldthwaite, Michael Wong, and Jens Maurer
describe explicit conversion operators in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n2333.html">
<cite>N2333 Explicit Conversion Operator
Draft Working Paper Revision 1</cite></a>.)
The short answer is that the two facilities are orthogonal,
<code>explicit</code> controls the set of functions considered
and <code>delete</code> comments on the final choice.
The more helpful answer is a bit more subtle.
For example, consider

<blockquote><pre><code>
struct type
{
    type( long long );
    explicit type( long ) = delete;
};
extern void function( type );
</code></pre></blockquote>

<p>Under this proposal, lookup and the semantics of <code>explicit</code>
are unchanged,
so in the overload resoultion for <q><code>type(42)</code></q>,
42 promotes to <code>long</code> in the overload resolution,
and a deleted function is selected, which is an error.

<blockquote><pre><code>
function( type( 42 ) ); // error 42 promotes to long
function( 42 ); // okay type(long long); type(long) not considered
</code></pre></blockquote>

<p>In practice, <code>explicit</code> and <code>delete</code>
will probably not be used together.
Programmers desiring more restrictive diagnostics
will use <code>delete</code> alone
rather than <code>explicit</code>.


<h3><a name="comparison">Comparison to Prior Approaches</a></h3>

<p>Our solution provides all known strengths of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1602.pdf">
N1602</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1717.pdf">
N1717</a> and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2123.html">
N2123</a>
while avoiding many of the identified weakness.
In particular,
the <code>explicit</code> class qualifier and
the <code>prohibited</code> access specifier
would no longer be necessary.

<p>The solution addresses most of the goals of
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1890.pdf">
N1890(7)</a>,
specifically those related to function definitions,
but not those related to <q>class defaults</q> of inheritance.
We have chosen not to address class defaults for the following reasons.
<ul>
<li>Member functions can be specified virtual or pure
with very little additional syntax.
We do not believe that the syntactic savings
justifies having to look in two places for the full declaration,
which is particularly problematic for visual development environments
that wish to warp the screen to 'the' definition.</li>
<li>Class inheritance and blocking virtual overrides
is better handled by some form of 'final' syntax or attribute.
The current proposal is focussed on alternate function definitions,
and should leave other problems to other papers.</li>
</ul>
Our proposed syntax is more tedious than that of
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1890.pdf">
N1890(7)</a>,
but also more general,
applying to user-defined member and free functions as well.


<h2><a name="usecase">Use Case - Atomic Types</a></h2>

<p>Paper
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2145.html">
<cite>N2145 C++ Atomic Types and Operations</cite></a>
described a failure to achieve desired semantics
for atomic types with with C++ 2003.
With this proposal and others,
an effective and correct definition is defined in 
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2324.html">
<cite>N2324 C++ Atomic Types and Operations</cite></a>
and thus is a motivating use case for the proposal.

<p>The following code,
as defined in this proposal and in conjunction with
<cite><a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2215.pdf">
N2215 Initializer lists (Rev.3)</a></cite>,
<cite><a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2230.html">
N2294 POD's Revisited; Resolving Core Issue 568 (Revison 4)</a></cite>, and
<cite><a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2235.pdf">
N2235 Generalized Constant Expressions &mdash; Revision 5</a></cite>,
appears to satisfy the requirements of
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2145.html">
N2145</a>.

<blockquote><pre><code>
typedef struct atomic_int
{
#ifdef __cplusplus
    // destructor implicitly declared and defined
    atomic_int() = default; // otherwise suppressed by other constructors
    constexpr atomic_int( int v ) : f ( v ) { } // construct from value
    int operator =( int v ) volatile; // assign from value
    atomic_int( const atomic_int &amp; ) = delete; // too dangerous
    atomic_int &amp; operator =( const atomic_int &amp; ) = delete; // also
    operator int(); // load the value
private:
#endif
    int f;
} atomic_int;</code>
</code></pre></blockquote>

<p> The destructor is implicitly-defaulted and trivial.
The default constructor is explicitly-defaulted and trivial.
The copy constructor and copy assignment operators are deleted
and therefore trivial.

<p><a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2235.pdf">
N2235</a> and the <code>constexpr</code> value constructor
together permit static initialization.
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2215.pdf">
N2215</a> permits aggregate initialization syntax.

<p> The erroneous defaults for copying are deleted, preventing their use.
One can still copy from one atomic to another,
but only going through a non-atomic value,
which makes clear that a copy between two atomics is not itself atomic.

<blockquote><pre><code>
atomic_int w = { 3 }; // static initialization
atomic_int x; // default zero initialization
void function( atomic_int * p ) {
    atomic_int y( *p ); // error copy constructor is deleted
    atomic_int z( int(*p) ); // okay copy construct through value
    *p = x; // error copy assignment is deleted
    *p = int(x); // okay copy assignment through value
}
</code></pre></blockquote>


<h2><a name="changes">Changes to the Standard</a></h2>

<p>We propose the following changes to the standard.
The base document is
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2315.pdf">
<cite>N2315 Working Draft, Standard for Programming Language C++</cite></a>.


<h3><a name="opnew">5.3.4 New [expr.new]</a></h3>

<p>Within paragraph 16, edit
<blockquote>
A <dfn>new-expression</dfn> that creates an object of type <code>T</code>
initializes that object as follows:
<ul>
<li>If the <dfn>new-initializer</dfn> is omitted:
<ul>
<li>If <code>T</code>
is a (possibly cv-qualified) non-POD class type (or array thereof),
the object is default-initialized (8.5).
If <code>T</code> is a const-qualified type,
the underlying class type shall have
a <del>user-declared</del> <ins>user-provided</ins> default constructor.
<li>Otherwise, the object created has indeterminate value.
If <code>T</code> is a const-qualified type,
or a (possibly cv-qualified) POD class type (or array thereof)
containing (directly or indirectly) a member of const-qualified type,
the program is ill-formed;
</ul>
</ul>
</blockquote>


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

<p>In paragraph 1, edit

<blockquote>
Function definitions have the form
<blockquote>
<dl>
<dt><var>function-definition:</var></dt>
<dd><var>decl-specifier-seq<sub>opt</sub>
declarator ctor-initializer<sub>opt</sub>
function-body</var></dd>
<dd><var>decl-specifier-seq<sub>opt</sub>
declarator function-try-block</var></dd>
<dd><ins><var>decl-specifier-seq<sub>opt</sub>
declarator</var> <code>&nbsp;= default ;</code></ins></dd>
<dd><ins><var>decl-specifier-seq<sub>opt</sub>
declarator</var> <code>&nbsp;= delete ;</code></ins></dd>
</dl>
</blockquote>
</blockquote>

<p>Add a new paragraph 7.

<blockquote>
A function definition of the form:
<blockquote>
<var>decl-specifier-seq<sub>opt</sub> declarator</var> <code>= default ;</code>
</blockquote>
is called an explicitly-defaulted definition.
Only special member functions may be explicitly defaulted,
and the implementation will define them
as if they had implicit definitions
(12.1, 12.4, 12.8).
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.
[ <i>Note</i>:
While an implicitly-declared special member function is inline (clause 12),
an explicitly-defaulted definition may be non-inline.
Non-inline definitions are user-provided,
and hence non-trivial (12.1, 12.4, 12.8).
This rule enables efficient execution and concise definition
while enabling a stable binary interface to an evolving codebase.
&mdash; <i>end note</i> ]
[ <i>Example:</i>
<blockquote><pre><code>
struct trivial {
    trivial() = default;
    trivial( const trivial &amp; ) = default;
    trivial &amp; operator =( const trivial &amp; ) = default;
    ~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>
&mdash; <i>end example</i> ]
</blockquote>

<p>Add a new paragraph 8.

<blockquote>
A function definition of of the form:
<blockquote>
<var>decl-specifier-seq<sub>opt</sub> declarator</var> <code>= delete ;</code>
</blockquote>
is called a deleted definition.
A function with a deleted definition is also called a deleted function.
A deleted definition of a function
shall be the first declaration of the function.
[ <i>Example:</i>
<blockquote><pre><code>
struct sometype {
    sometype();
};
sometype::sometype() = delete; // ill-formed; not first declaration
</code></pre></blockquote>
&mdash; <i>end example</i> ]
A deleted function is implicitly inline.
[ <i>Note:</i> The one-definition rule (3.2 [basic.def.odr])
applies to deleted definitions. &mdash; <i>end note</i> ]
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 explicitly or implicitly
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> ]
[ <i>Example:</i>
One can enforce non-default initialization
and non-integral initialization with
<blockquote><pre><code>
struct sometype {
    sometype() = delete ; // redundant, but legal
    sometype( std::intmax_t ) = delete;
    sometype( double );
};
</code></pre></blockquote>
&mdash; <i>end example</i> ]
[ <i>Example:</i>
One can prevent use of a class in certain <code>new</code> expressions
by using deleted definitions of a user-declared <code>operator new</code>
for that class.
<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>
&mdash; <i>end example</i> ]
</blockquote>

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

<p>Within paragraph 5, edit
<blockquote>
To <dfn>value-initialize</dfn> an object of type <code>T</code> means:
<ul>
<li>if <code>T</code> is a class type (clause 9)
with a <del>user-declared</del> <ins>user-provided</ins> constructor (12.1),
then the default constructor for <code>T</code> is called
(and the initialization is ill-formed
if <code>T</code> has no accessible default constructor);
</li>
<li>
if <code>T</code> is a non-union class type
without a <del>user-declared</del> <ins>user-provided</ins> constructor,
then every non-static data member and base-class component of <code>T</code>
is value-initialized;
</li>
</ul>
</blockquote>

<p>In paragraph 9, edit
<blockquote>
If no initializer is specified for an object,
and the object is of (possibly cv-qualified)
non-POD class type (or array thereof),
the object shall be default-initialized;
if the object is of const-qualified type,
the underlying class type shall have
a <del>user-declared</del> <ins>user-provided</ins> default constructor.
Otherwise, if no initializer is specified for a non-static object,
the object and its subobjects, if any,
have an indeterminate initial value<sup>92)</sup>;
if the object or any of its subobjects are of const-qualified type,
the program is ill-formed.
</blockquote>

<h3><a name="aggregates">8.5.1 Aggregates [dcl.init.aggr]</a></h3>

<p>In paragraph 1, edit

<blockquote>
An <dfn>aggregate</dfn> is an array or a class (clause 9)
with no <del>user-declared</del> <ins>user-provided</ins> constructors (12.1),
no private or protected non-static data members (clause 11),
no base classes (clause 10),
and no virtual functions (10.3).
</blockquote>

<p>In paragraph 13, edit
<blockquote>
[ <i>Note:</i> An aggregate array or an aggregate class
may contain members of a class type
with a <del>user-declared</del> <ins>user-provided</ins> constructor (12.1).
Initialization of these aggregate objects is described in 12.6.1.
&mdash; <i>end note</i> ]
</blockquote>

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

<p>In paragraph 4, edit
<blockquote>
A <dfn>union</dfn> is a class
defined with the <dfn>class-key</dfn> <code>union</code>;
it holds only one data member at a time (9.5).
[ <i>Note:</i> aggregates of class type are described in 8.5.1.
&mdash; <i>end note</i> ]
A <dfn>POD class</dfn> is an aggregate class
that has no non-static data members of
non-POD type (or array of such a type) or reference,
and has no <del>user-declared</del> <ins>user-provided</ins>
copy assignment operator
and no <del>user-declared</del> <ins>user-provided</ins> destructor.
A <dfn>POD-struct</dfn> is a POD class
defined with the <dfn>class-key</dfn> <code>struct</code>
or the <dfn>class-key</dfn> <code>class</code>.
A <dfn>POD-union</dfn> is a POD class
defined with the <dfn>class-key</dfn> <code>union</code>.
</blockquote>

<h3><a name="members">9.2 Class members [class.mem]</a></h3>

<p>Paragraph 14, unchanged.
<blockquote>
In addition, if class <code>T</code>
has a user-declared constructor (12.1),
every non-static data member of class <code>T</code>
shall have a name different from <code>T</code>.
</blockquote>

<h3><a name="override">10.3 Virtual functions [class.virtual]</a></h3>

<p>At the end of the section, add a new paragraph

<blockquote>
A function with a deleted definition ([dcl.fct.def])
shall not override a function that does not have a deleted definition.
Likewise, a function that does not have a deleted definition
shall not override a function with a deleted definition.
</blockquote>

<h3><a name="constructors">12.1 Constructors [class.ctor]<a></h3>

<p>Within paragraph 5, edit

<blockquote>
A default constructor is <dfn>trivial</dfn>
if it is <del>implicitly-declared</del> <ins>not user-provided</ins>
(8.4 [dcl.fct.def])
and if:
</blockquote>

<p>In paragraph 7, edit

<blockquote>
An <del>implicitly-declared</del> <ins>non-user-provided</ins>
default constructor for a class
is <dfn>implicitly defined</dfn>
when it is used (3.2) to create an object of its class type (1.8).
The implicitly-defined <ins>or explicitly-defaulted</ins> default constructor
performs the set of initializations of the class
that would be performed by a user-written default constructor for that class
with an empty <var>mem-initializer-list</var> (12.6.2)
and an empty function body.
If that user-written default constructor would be ill-formed,
the program is ill-formed.
Before the <del>implicitly-declared</del> <ins>non-user-provided</ins>
default constructor for a class
is implicitly defined,
all the <del>implicitly-declared</del> <ins>non-user-provided</ins>
default constructors
for its base classes and its non-static data members
shall have been implicitly defined.
[ <i>Note:</i> an implicitly-declared
default constructor has an <dfn>exception-specification</dfn> (15.4).
<ins>An explicitly-defaulted definition
has no implicit <dfn>exception-specification</dfn>.</ins>
&mdash; <i>end note</i> ]
</blockquote>

<h3><a name="destructors">12.4 Destructors [class.dtor]</a></h3>

<p>Within paragraph 3, edit

<blockquote>
If a class has no user-declared destructor,
a destructor is declared implicitly.
An implicitly-declared destructor is an inline public member of its class.
A destructor is trivial if it is <del>implicitly-declared</del>
<ins>not user-provided</ins> (8.4 [dcl.fct.def]) and if:
</blockquote>

<p>In paragraph 5, edit

<blockquote>
An <del>implicitly-declared</del> <ins>non-user-provided</ins> destructor
is implicitly defined
when it is used to destroy an object of its class type (3.7).
A program is ill-formed if the class for which a destructor is
implicitly defined <ins>or explicitly defaulted</ins> has:
<ul>
<li>a non-static data member of class type (or array thereof) with
an inaccessible destructor, or</li>
<li>a base class with an inaccessible destructor.</li>
</ul>
Before the <del>implicitly-declared</del> <ins>non-user-provided</ins>
destructor for a class is implicitly defined,
all the <del>implicitly-declared</del> <ins>non-user-provided</ins>
destructors for its base classes and its non-static data members
shall have been implicitly defined.
[ <i>Note:</i> an implicitly-declared destructor
has an exception-specification (15.4).
<ins>An explicitly-defaulted definition
has no implicit <dfn>exception-specification</dfn>.</ins>
&mdash; <i>end note</i> ]

</blockquote>

<h3><a name="initializing">12.6.2 Initializing bases and members [class.base.init]</a></h3>

<p>Within paragraph 4, edit
<blockquote>
If a given non-static data member or base class
is not named by a <dfn>mem-initializer-id</dfn>
(including the case where there is no <dfn>mem-initializer-list</dfn>
because the constructor has no <dfn>ctor-initializer</dfn>),
then
<ul>
<li>If the entity is a non-static data member
of (possibly cv-qualified) class type (or array thereof)
or a base class,
and the entity class is a non-POD class,
the entity is default-initialized (8.5).
If the entity is a non-static data member of a const-qualified type,
the entity class shall have
a <del>user-declared</del> <ins>user-provided</ins> (8.4 [dcl.fct.def])
default constructor.
</li>
</ul>
</blockquote>

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

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

<p>Within paragraph 6, edit
<blockquote>
A copy constructor for class <code>X</code> is trivial
if it is <del>implicitly declared</del> <ins>not user-provided</ins>
(8.4 [dcl.fct.def])
and if
</blockquote>

<p>In paragraph 7, edit
<blockquote>
An <del>implicitly-declared</del> <ins>non-user-provided</ins> copy constructor
is implicitly defined 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<sup>108)</sup>.
[ <i>Note:</i> the copy 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 class for which a copy constructor
is implicitly defined<ins>, or explictly defaulted,</ins> has:
<ul>
<li>a non-static data member of class type (or array thereof)
with an inaccessible or ambiguous copy constructor, or</li>
<li>a base class with an inaccessible or ambiguous copy constructor.</li>
</ul>
Before the <del>implicitly-declared</del> <ins>non-user-provided</ins>
copy constructor for a class is implicitly defined,
all <del>implicitly-declared</del> <ins>non-user-provided</ins>
copy 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 constructor
has an exception-specification (15.4).
<ins>An explicitly-defaulted definition
has no implicit <dfn>exception-specification</dfn>.</ins>
&mdash; <i>end note</i> ]
</blockquote>

<p>Within paragraph 8, edit

<blockquote>
The implicitly-defined <ins>or explicitly-defaulted</ins> copy constructor
for class <code>X</code> performs a memberwise copy of its subobjects.
</blockquote>

<p>Within paragraph 9, unchanged.

<blockquote>
A user-declared <dfn>copy</dfn> 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</code>, <code>X&amp;</code>, <code>const X&amp;</code>,
<code>volatile X&amp;</code> or
<code>const volatile X&amp;</code>.<sup>109)</sup>
</blockquote>

<p>Within paragraph 11, edit

<blockquote>
A copy assignment operator for class <code>X</code> is trivial
if it is <del>implicitly declared</del> <ins>not user-provided</ins>
and if
</blockquote>

<p>In paragraph 12, edit

<blockquote>
An <del>implicitly-declared</del> <ins>non-user-provided</ins>
copy assignment operator
is implicitly defined 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 class for which a
copy assignment operator is implicitly defined<ins>
or explicitly defaulted,</ins> has:
<ul>
<li>a non-static data member of const type, or</li>
<li>a non-static data member of reference type, or</li>
<li>a non-static data member of class type (or array thereof) with
an inaccessible copy assignment operator, or</li>
<li>a base class with an inaccessible copy assignment operator.</li>
</ul>
Before the <del>implicitly-declared</del> <ins>non-user-provided</ins>
copy assignment operator for a class is implicitly defined,
all <del>implicitly-declared</del> <ins>non-user-provided</ins>
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 assignment operator
has an <dfn>exception-specification</dfn> (15.4).
<ins>An explicitly-defaulted definition
has no implicit <dfn>exception-specification</dfn>.</ins>
&mdash; <i>end note</i> ]
</blockquote>

<p>Within paragraph 13, edit

<blockquote>
The implicitly-defined <ins>or explicitly-defaulted</ins>
copy assignment operator for class X
performs memberwise assignment of its subobjects.
....
<del>it</del> <ins>It</ins> is unspecified
whether subobjects representing virtual base classes
are assigned more than once by the implicitly-defined
<ins>or explicitly-defaulted</ins> copy assignment operator.
</blockquote>


<h3><a name="special">14.7.3 Explicit specialization [temp.expl.spec]</a></h3>

<p>In paragraph 1, edit

<blockquote>
An explicit specialization of any of the following:
<ul>
<li><ins>non-deleted</ins> function template</li>
<li>class template</li>
<li><ins>non-deleted</ins> member function of a class template</li>
<li>static data member of a class template</li>
<li>member class of a class template</li>
<li>member class template of a class template</li>
<li><ins>non-deleted</ins> member function template of a class template</li>
</ul>
can be declared by a declaration introduced by template<>;
</blockquote>

<h3><a name="compat">C.1.8 Clause 12: special member functions [diff.special]</a></h3>

<p>In paragraph 1, edit
<blockquote>
12.8 (copying class objects)
<dl>
<dt>Change:</dt>
<dd>
The implicitly-declared copy constructor
and implicitly-declared copy assignment operator
cannot make a copy of a volatile lvalue.
For example, the following is valid in ISO C:
<blockquote><pre><code>
struct X { int i; };
struct X x1, x2;
volatile struct X x3 = {0};
x1 = x3; // invalid C++
x2 = x3; // also invalid C++
</code></pre></blockquote>
</dd>
<dt>Rationale:</dt>
<dd>
Several alternatives were debated at length.
Changing the parameter to <code>volatile const X&amp;</code>
would greatly complicate the generation of efficient code for class objects.
Discussion of providing two alternative signatures
for these implicitly-defined operations raised unanswered concerns
about creating ambiguities and complicating the rules
that specify the formation of these operators
according to the bases and members.
</dd>
<dt>Effect on original feature:</dt>
<dd>
Deletion of semantically well-defined feature.
</dd>
<dt>Difficulty of converting:</dt>
<dd>
Semantic transformation.
If volatile semantics are required for the copy,
a user-declared constructor or assignment must be provided.
<ins>[ <i>Note:</i>
This user-declared constructor may be explicitly defaulted.
&mdash; <i>end note</i> ]</ins>
If non-volatile semantics are required, an explicit const_cast can be used.
</dd>
<dt>How widely used:</dt>
<dd>
Seldom.
</dd>

</blockquote>

</body></html>
