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

Expedited core issues handling (revision 2)

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.

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

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

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

624: Overflow in calculating size of allocation

See N2714 core issue 624. The proposed resolution presented hereinafter supersedes the proposed resolution presented in N2714.

Change 5.3.4 [expr.new] paragraph 8:

~~When~~ If the value of the expression in a direct-new-declarator is zero, the allocation function is called to allocate an array with no elements. If the value of that expression is such that the size of the allocated object would exceed the implementation-defined limit, no storage is obtained and the new-expression terminates by throwing an exception of a type that would match a handler (15.3 except.handle) of type std::length_error (19.1.4 length.error).

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

683: Requirements for trivial subobject special functions

See N2714 core issue 683. The proposed resolution presented hereinafter supersedes the proposed resolution presented in N2714.

Change 9 class paragraph 5 as follows:

A trivial class is a class that:

has a trivial default constructor (12.1),

has ~~a trivial copy constructor~~ no non-trivial copy constructors (12.8),

has ~~a trivial copy assignment operator~~ no non-trivial copy assignment operators (13.5.3, 12.8), and

has a trivial destructor (12.4).

[Note: in particular, a trivial class does not have virtual functions or virtual base classes. -- end note]

Change 12.8 class.copy paragraph 6 as follows:

A copy constructor for class X is trivial if it is not user-provided (8.4) and if

class X has no virtual functions (10.3) and no virtual base classes (10.1), and

~~each direct base class of X has a trivial copy constructor~~ the constructor selected to copy each direct base class subobject is trivial, and

for ~~all the~~ each non-static data ~~members~~ member of X that ~~are~~ is of class type (or array thereof), ~~each such class type has a trivial copy constructor~~ the constructor selected to copy that member is trivial;

otherwise the copy constructor is non-trivial.

Change 12.8 class.copy paragraph 11 as follows:

A copy assignment operator for class X is trivial if it is not user-provided and if

class X has no virtual functions (10.3) and no virtual base classes (10.1), and

~~each direct base class of X has a trivial copy assignment operator~~ the assignment operator selected to copy each direct base class subobject is trivial, and

for ~~all the~~ each non-static data ~~members~~ member of X that ~~are~~ is of class type (or array thereof), ~~each such class type has a trivial copy assignment operator~~ the assignment operator selected to copy that member is trivial;

otherwise the copy assignment operator is non-trivial.

614: Results of integer / and %

Apply the proposed resolution presented in N2714 core issue 614, incorporated herein by reference.

681: Restrictions on declarators with late-specified return types

Apply the proposed resolution presented in N2714 core issue 681, incorporated herein by reference.

606: Template argument deduction for rvalue references

Apply the proposed resolution presented in N2714 core issue 606, incorporated herein by reference.

220: All deallocation functions should be required not to throw

See N2714 core issue 220. The proposed resolution presented hereinafter supersedes the proposed resolution presented in N2714.

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

If a deallocation function terminates by throwing an exception, the behavior is undefined. 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. ...

688: Constexpr constructors and static initialization

See core issue 688. The proposed resolution presented hereinafter supersedes the proposed resolution presented in N2714. Due to the significant wording overlap, the following proposed resolution also addresses core issue 684 "Constant expressions involving the address of an automatic variable".

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

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. 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. Constant initialization is performed:

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)

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).

Together, zero-initialization and constant initialization...

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

an lvalue-to-rvalue conversion (4.1 conv.lval) unless it is applied to ...
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

a unary operator & (5.3.1 expr.unary.op) that is applied to an lvalue that designates an object with thread or automatic storage duration

an id-expression that refers to a variable or data member of reference type;

...

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

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

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

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

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

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. [ 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 ]

592: Exceptions during construction of local static objects

See core issue 592. The proposed resolution presented hereinafter supersedes the proposed resolution presented in N2714.

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

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. ~~Should a constructor for an element of an automatic array throw an exception, only the constructed elements of that array will be destroyed.~~ If the object ~~or array~~ 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.