N2730=08-0240
Jens Maurer <Jens.Maurer@gmx.net>
2008-08-21

Expedited core issues handling (revision 1)

This paper is a revision of N2707, "Expedited core issues handling", by Jens Maurer.

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.

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.

Thanks to Jan Stephen Adamczyk and William Michael Miller for their comments.

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 of type std::length_error (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.

614: Results of integer / and %

See core issue 614.

Summary: Specify that integer division rounds towards 0.

Rationale: Alignment with C99.

Note: As of the mid-meeting mailing, the following proposed resolution was not available in the core issues list. Should a proposed resolution become available in the core issues list for the pre-meeting mailing, that will take priority.

Change in 5.6 expr.mul paragraph 4, including removing the footnote:

The binary / operator yields the quotient, and the binary % operator yields the remainder from the division of the first expression by the second. If the second operand of / or % is zero the behavior is undefined. For integral operands, the / operator yields the algebraic quotient with any fractional part discarded [ Footnote: This is often called "truncation towards zero". ]; if the quotient a/b is representable in the type of the result, (a/b)*b + a%b is equal to a. ; otherwise (a/b)*b + a%b is equal to a. If both operands are nonnegative then the remainder is nonnegative; if not, the sign of the remainder is implementation-defined [ Footnote: According to work underway toward the revision of ISO C, the preferred algorithm for integer division follows the rules defined in the ISO Fortran standard, ISO/IEC 1539:1991, in which the quotient is always rounded toward zero. ]

681: Restrictions on declarators with late-specified return types

See core issue 681.

Summary: Good intentions for restrictions on the syntax involving late-specified return types were incorrectly represented in the normative wording.

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

606: Template argument deduction for rvalue references

See core issue 606.

Summary: Tweaks a detail of template argument deduction for rvalue references; does not change the behavior for perfect forwarding or move semantics.

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

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.

Discussion on the core reflector has shown additional issues with the semantics of rvalue references as specified in the standard. Together with the fact that no proposed resolution is currently available in the core issues list, it seems unlikely that agreeable wording for a resolution of this issue will be available at the end of the upcoming meeting.

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.

Discussion on the core reflector has shown additional issues with the semantics of rvalue references as specified in the standard. Together with the fact that no proposed resolution is currently available in the core issues list, it seems unlikely that agreeable wording for a resolution of this issue will be available at the end of the upcoming meeting.

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: As of the mid-meeting mailing, the following proposed resolution was not available in the core issues list. Should a proposed resolution become available in the core issues list for the pre-meeting mailing, that will take priority.

Change 8.5 dcl.init paragraph 5 as indicated:

To zero-initialize an object of type T means:

...

...

Drafting notes: See C99 6.7.8p10. Ask a C liason about the progress of DR#16 in WG14. Since the "extended unions" paper, unions may have static data members, therefore the footnote needs to be converted into a normative requirement.

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.