<html>
<head>
<title>Expedited core issues handling (revision 2)</title>
</head>

<body>
N2757 = 08-0267<br/>
Jens Maurer &lt;Jens.Maurer@gmx.net><br/>
William Michael Miller &lt;william.m.miller@gmail.com><br/>
2008-09-17

<h1>Expedited core issues handling (revision 2)</h1>

<p>This paper is a revision of N2730, "Expedited core issues
handling (revision 1)", by Jens Maurer.  It presents those core issues
from N2730 whose resolution the Core Working Group agreed to propose
moving into the C++ working paper at the end of the San Francisco
meeting.</p>

<p>
The following issues brought forward in N2730 have been dropped from
this paper and will be handled in the normal course of issues
processing:
</p>

<ul>
<li>693: New string types and deprecated conversion</li>
<li>664: Direct binding of references to non-class rvalue
references</li>
<li>690: The dynamic type of an rvalue reference</li>
<li>694: Zero- and value-initialization of union objects</li>
</ul>

Core issue 543 "Value initialization and default constructors" is
resolved by the separate paper N2762 "Not so Trivial Issues with
Trivial".


<h2>624: Overflow in calculating size of allocation</h2>

<p>
See N2714
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#624">core issue 624</a>.
The proposed resolution presented hereinafter supersedes the proposed
resolution presented in N2714.
</p>

Change 5.3.4 [expr.new] paragraph 8:

<blockquote>
<del>When</del> <ins>If</ins> the value of the <em>expression</em> in
a <em>direct-new-declarator</em> is zero, the allocation function is
called to allocate an array with no elements.  

<ins>If the value of that <em>expression</em> is such that the size of
the allocated object would exceed the implementation-defined limit, no
storage is obtained and the <em>new-expression</em> terminates by throwing an
exception of a type that would match a handler (15.3 except.handle)
of type <code>std::length_error</code> (19.1.4 length.error).</ins>

</blockquote>

<em>[ Drafting note: <code>std::length_error</code> is thrown by
<code>std::string</code> and <code>std::vector</code> and thus appears
to be the right choice for the exception to be thrown here. ]</em>


<h2>683: Requirements for trivial subobject special functions</h2>

<p>
See N2714
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#683">core
issue 683</a>.

The proposed resolution presented hereinafter supersedes the proposed
resolution presented in N2714. 
</p>

<p>
Change 9 class paragraph 5 as follows:
</p>

<blockquote>
A <em>trivial class</em> is a class that:
<ul>
<li>has a trivial default constructor (12.1),</li>
<li>has <del>a trivial copy constructor</del> <ins>no non-trivial copy
constructors</ins> (12.8),</li>
<li>has <del>a trivial copy assignment operator</del> no non-trivial copy
assignment operators (13.5.3, 12.8), and</li>
<li>has a trivial destructor (12.4).</li>
</ul>
[Note: in particular, a trivial class does not have virtual functions
or virtual base classes. -- end note]
</blockquote>

<p>
Change 12.8 class.copy paragraph 6 as follows:
</p>

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


<p>
Change 12.8 class.copy paragraph 11 as follows:
</p>
<blockquote>
A copy assignment operator for class X is <em>trivial</em> if it is
not user-provided and if
<ul>
<li>class X has no virtual functions (10.3) and no virtual base
classes (10.1), and</li>
<li><del>each direct base class of X has a trivial copy assignment
operator</del>
<ins>the assignment operator selected to copy each direct base class
subobject is trivial</ins>, and</li>
<li>for <del>all the</del> <ins>each</ins> non-static data
<del>members</del> <ins>member</ins> of X
that <del>are</del> <ins>is</ins> of class type (or array thereof),
<del>each such class type has
a trivial copy assignment operator</del> <ins>the assignment operator
selected to copy that member is trivial</ins>;</li>
</ul>
otherwise the copy assignment operator is <em>non-trivial</em>.
</blockquote>


<h2>614: Results of integer / and %</h2>

<p>
Apply the proposed resolution presented in N2714
<a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#614">core
issue 614</a>,
incorporated herein by reference.
</p>


<h2>681: Restrictions on declarators with late-specified return types</h2>

<p>
Apply the proposed resolution presented in N2714
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#681">core issue 681</a>,
incorporated herein by reference.
</p>


<h2>606: Template argument deduction for rvalue references</h2>

<p>
Apply the proposed resolution presented in N2714
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#606">core issue 606</a>,
incorporated herein by reference.
</p>


<h2>220: All deallocation functions should be required not to throw</h2>

<p>
See N2714
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#220">core issue 220</a>.
The proposed resolution presented hereinafter supersedes the proposed
resolution presented in N2714.
</p>

Add at the beginning of 3.7.4.2 basic.stc.dynamic.deallocation
paragraph 3:

<blockquote>
<ins>If a deallocation function terminates by throwing an exception,
the behavior is undefined.</ins>
The value of the first argument supplied to a deallocation functions
may be a null pointer value; if so, and if the deallocation function
is one supplied in the standard library, the call has no effect. ...
</blockquote>


<h2>688: Constexpr constructors and static initialization</h2>

<p>
See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#688">core issue 688</a>.
The proposed resolution presented hereinafter supersedes the proposed
resolution presented in N2714.  Due to the significant wording
overlap, the following proposed resolution also addresses
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#684">core
issue 684</a>
"Constant expressions involving the address of an automatic variable".
</p>


Change 3.6.2 [basic.start.init] paragraph 2 as follows:

<blockquote>
Objects with static storage duration (3.7.1 basic.stc.static) or
thread storage duration (3.7.2 basic.stc.thread) shall be zero-initialized (8.5
dcl.init) before any other initialization takes place.  <del>A reference
with static or thread storage duration and an object of trivial or
literal type with static or thread storage duration can be initialized
with a constant expression (5.19 expr.const); this is called
constant initialization.</del>

<ins><em>Constant initialization</em> is performed:
<ul>
<li>if each full-expression (including implicit conversions) that appears
in the initializer of a reference with static or thread storage
duration is a constant expression and the reference is bound to an
lvalue designating an object with static storage duration or to a
temporary (see 12.2 class.temporary)</li>
<li>if an object with static or thread storage duration is initialized
such that the initialization satisfies the requirements for the
object being declared with constexpr (7.1.5 dcl.constexpr).</li>
</ul></ins>
Together, zero-initialization and constant initialization... 
</blockquote>


Add the following in 5.19 [expr.const] paragraph 2:

<blockquote>
<ul>
<li>an lvalue-to-rvalue conversion (4.1 conv.lval) unless it is applied to ...
<li><ins>an array-to-pointer conversion (4.2 conv.array) that is applied
to an lvalue that designates an object with thread or automatic
storage duration</ins></li>
<li><ins>a unary operator &amp; (5.3.1 expr.unary.op) that is applied
to an lvalue that designates an object with thread or automatic storage
duration</ins></li>
<li>an id-expression that refers to a variable or data member of reference type;
</li>
<li>...</li>
</ul>
</blockquote>

Change 6.7 [stmt.dcl] paragraph 4 as follows:

<blockquote>
... <del>A local object of trivial or literal type (3.9 [basic.types]) with
static storage duration initialized with constant-expressions is
initialized</del> <ins>Constant initialization (3.6.2
[basic.start.init]) of a local entity with static storage duration, if
applicable, is performed</ins> before its block is first entered ...
</blockquote>

Change 7.1.5 [dcl.constexpr] paragraph 7 as follows:

<blockquote>
A <code>constexpr</code> specifier used in an object declaration
declares the object as <code>const</code>. Such an object shall be
initialized, and <del>every</del> <ins>each</ins> expression that appears in its initializer (8.5
[dcl.init]) shall be a constant expression. <del>Every</del> <ins>Each</ins> implicit conversion
used in converting the initializer expressions <ins>and each
constructor call used for the initialization</ins> shall be one of
those allowed in a constant expression (5.19 [expr.const])...
</blockquote>


Replace 8.5.1 [dcl.init.aggr] paragraph 14 as follows:

<blockquote>
<del>When an aggregate with static storage duration is initialized
with a brace-enclosed initializer-list, if all the member initializer
expressions are constant expressions, and the aggregate is a trivial
type, the initialization shall be done during the static phase of
initialization (3.6.2 [basic.start.init]); otherwise, it is
unspecified whether the initialization of members with constant
expressions takes place during the static phase or during the dynamic
phase of initialization.</del> <ins>[ Note: Whether the initialization
of aggregates with static storage duration is static or dynamic is
specified in 3.6.2 [basic.start.init] and 6.7 [stmt.dcl]. --- end note ]</ins>
</blockquote>



<h2>592: Exceptions during construction of local static objects</h2>

<p>
See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#592">core
issue 592</a>.
The proposed resolution presented hereinafter supersedes the proposed
resolution presented in N2714.
</p>

Change 15.2 [except.ctor] paragraph 2 as follows:

<blockquote>
An object that is partially constructed or partially destroyed will
have destructors executed for all of its fully constructed subobjects,
that is, for subobjects for which the principal constructor (12.6.2
[class.base.init]) has completed execution and the destructor has not
yet begun execution. Similarly, if the non-delegating constructor for
an object has completed execution and a delegating constructor for
that object exits with an exception, the object's destructor will be
invoked. <del>Should a constructor for an element of an automatic array
throw an exception, only the constructed elements of that array will
be destroyed.</del> If the object <del>or array</del> was allocated in a
new-expression, the matching deallocation function (3.7.3.2
[basic.stc.dynamic.deallocation], 5.3.4 [expr.new], 12.5
[class.free]), if any, is called to free the storage occupied by the
object.
</blockquote>


</body>
</html>
