N2707 = 08-0217
Jens Maurer <Jens.Maurer@gmx.net>
2008-07-25

Expedited core issues handling

Motivation

WG21 has announced that it intends to vote out a Committee Draft (CD) at the end of the San Francisco meeting, which is the next one. Per ISO rules, national bodies are invited to comment and vote on this Committee Draft.

Core issues are usually handled in a multi-step process. When proposed wording has become available, the issue is put in "Review" status. Once the Core Working Group has reviewed the wording and is satisfied with it, the issue is put in "Ready" status. All issues that had been in "Ready" status in the respective pre-meeting mailing are put forward for vote at the corresponding meeting, unless objections have been raised. This process ensures that issues are in "Ready" status for one full between-meetings cycle, giving everybody ample opportunity to review and potentially object to issue resolutions.

A number of core issues are not yet in "Ready" status, but are sufficiently far-reaching that an effort should be made to resolve these issues for the Committee Draft. This paper presents core issues that may be candidates for expedited handling at the San Franciso meeting, giving everybody ample opportunity to review and potentially object to both the faster handling and the issue resolution itself. It is intended to publish an update of this paper in the pre-San Francisco mailing.

A core issue is eligible to be considered in this paper if

A core issue will not be considered in this paper if

The following sections each list one core issue with a summary and a rationale for including the issue in this paper.

624: Overflow in calculating size of allocation

See core issue 624.

Summary: For new T[n], an overflow in the calculation of sizeof(T) * n will now throw an exception (instead of exposing undefined behavior).

Rationale: A new-expression can now throw an exception different from std::bad_alloc, which may have significant impact on applications. Also, implementation may wish to change their ABI to efficiently implement the new requirements.

693: New string types and deprecated conversion

See core issue 693.

Summary: The deprecated conversion from a string literal to non-const pointer-to-char is removed.

Rationale: Removes a C compatibility feature that breaks type-safety, but may also break the translation of existing applications.

683: Requirements for trivial subobject special functions

See core issue 683.

Summary: With "= default", trivial and non-trivial special member functions of the same kind could exist. In order to prevent that, "= default" disallows competing special member functions.

Rationale: Fixes an issue with a new C++0x feature.

Note: A proposed resolution is not yet available in the core issues list.

614: Results of integer / and %

See core issue 614.

Summary: Specify that integer division rounds towards 0.

Rationale: Alignment with C99.

Note: A proposed resolution is not yet available in the core issues list.

664: Direct binding of references to non-class rvalue references

See core issue 664.

Summary: Do not introduce temporaries when binding rvalue references to values originating from non-class rvalue references.

Rationale: Noticeable usability impact on applications; important feature for expression template libraries.

Note: A proposed resolution is not yet available in the core issues list.

690: The dynamic type of an rvalue reference

See core issue 690.

Summary: An rvalue reference can convey a dynamic type, similar to lvalue references.

Rationale: Symbiosis with the resolution of core issue 664.

Note: An agreeable proposed resolution is not yet available in the core issues list.

220: All deallocation functions should be required not to throw

See core issue 220.

Summary: A deallocation function shall not terminate by throwing an exception.

Rationale: Simple fix for a specification hole in the standard.

694: Zero- and value-initialization of union objects

See core issue 694.

Summary: Change the definition of zero-initialization of unions so that all the bytes of the union are set to zero before zero-initializing the first member of the union.

Rationale: Alignment with C99.

Note: A proposed resolution is not yet available in the core issues list.

543. Value initialization and default constructors

See core issue 543.

Summary: Value-initialization still requires a well-formed implicity-defined default constructor.

Rationale: Current implementations differ from the specification in the standard, but agree with the proposed resolution.

688: Constexpr constructors and static initialization

See core issue 688.

Summary: Provide broader reach of constant initialization, i.e. static initialization.

Rationale: Provide necessary core language initialization support for library types such as std::shared_ptr, std::once_flag, and std::atomic_*.

592: Exceptions during construction of local static objects

See core issue 592.

Summary: A confusing sentence in 15.2p2 suggests that only automatic arrays are properly destroyed if the constructor for an element throws.

Rationale: Seriously misleading and confusing standards text with a simple resolution.

Deleted functions and triviality of classes

Lawrence Crowl and Jens Maurer will write a separate paper.