This paper is a revision of N2707, "Expedited core issues handling", by Jens Maurer.
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
Thanks to Jan Stephen Adamczyk and William Michael Miller for their comments.
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.
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.
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.
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. ]
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.
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.
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.
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.
Summary: A deallocation function shall not terminate by throwing an exception.
Rationale: Simple fix for a specification hole in the standard.
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....
- if T is a union type, the object's second and subsequent non-static data members (if any) are zero-initialized, after which the object's first named non-static data member
[ Footnote: This member must not be static, by virtue of the requirements in 9.5 class.union. ]is zero-initialized;...
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.
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_*.
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.