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

<body>
N2730=08-0240<br/>
Jens Maurer &lt;Jens.Maurer@gmx.net><br/>
2008-08-21

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

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

<h2>Motivation</h2>

<p>
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.
</p>

<p>
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.
</p>

<p>
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.
</p>

<p>
A core issue is eligible to be considered in this paper if
</p>

<ul>
<li>it causes the ABI to change,
<li>it affects compatibility with C99,
<li>it fixes an issue with a new C++0x feature,
<li>it has significant impact on application code, or
<li>it provides a core language feature for the standard library
</ul>

<p>A core issue will not be considered in this paper if
</p>
<ul>
<li>it merely clarifies language in the standard or
<li>implementations don't differ
</ul>

The following sections each list one core issue with a summary and a rationale
for including the issue in this paper.
<p>
Thanks to Jan Stephen Adamczyk and William Michael Miller for their comments.


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

See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#624">core issue 624</a>.
<p>
Summary: For <code>new T[n]</code>, an overflow in the calculation of
sizeof(T) * n will now throw an exception of type
<code>std::length_error</code> (instead of exposing undefined
behavior).
<p>
Rationale: A <em>new-expression</em> 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.


<h2>693: New string types and deprecated conversion</h2>

See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#693">core issue 693</a>.
<p>
Summary: The deprecated conversion from a string literal to non-const
pointer-to-char is removed.
<p>
Rationale: Removes a C compatibility feature that breaks type-safety,
but may also break the translation of existing applications.


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

See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#683">core issue 683</a>.
<p>
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.
<p>
Rationale: Fixes an issue with a new C++0x feature.


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

See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#614">core issue 614</a>.
<p>
Summary: Specify that integer division rounds towards 0.
<p>
Rationale: Alignment with C99.
<p>
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.
<p>

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

<blockquote>
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<ins>.  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.</ins>

<del>; 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. ]</del>

</blockquote>

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

See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#681">core issue 681</a>.
<p>
Summary: Good intentions for restrictions on the syntax involving
late-specified return types were incorrectly represented in the
normative wording.
<p>
Rationale: Fixes an issue with a new C++0x feature.


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

See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#606">core issue 606</a>.
<p>
Summary: Tweaks a detail of template argument deduction for rvalue
references; does not change the behavior for perfect forwarding or
move semantics.
<p>
Rationale: Fixes an issue with a new C++0x feature.
<p>
Note: A proposed resolution is not yet available in the core issues
list.

<h2>664: Direct binding of references to non-class rvalue references</h2>

See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#664">core issue 664</a>.
<p>
Summary: Do not introduce temporaries when binding rvalue references
to values originating from non-class rvalue references.
<p>
Rationale: Noticeable usability impact on applications; important
feature for expression template libraries.
<p>
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.


<h2>690: The dynamic type of an rvalue reference</h2>

See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#690">core issue 690</a>.
<p>
Summary: An rvalue reference can convey a dynamic type, similar to
lvalue references.
<p>
Rationale: Symbiosis with the resolution of core issue 664.
<p>
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.


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

See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#220">core issue 220</a>.
<p>
Summary: A deallocation function shall not terminate by throwing an exception. 
<p>
Rationale: Simple fix for a specification hole in the standard.


<h2>694: Zero- and value-initialization of union objects</h2>

See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#694">core issue 694</a>.
<p>
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.
<p>
Rationale: Alignment with C99.
<p>
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.
<p>

Change 8.5 dcl.init paragraph 5 as indicated:

<blockquote>
To <em>zero-initialize</em> an object of type T means:
<p>...</p>
<ul>
<li>if T is a union type, <ins>the object's second and subsequent
non-static data members (if any) are zero-initialized, after
which</ins> the object's first named <ins>non-static</ins> data member
<del>[ Footnote: This member must not be static, by virtue of the
requirements in 9.5 class.union. ]</del> is zero-initialized;
</ul>
<p>...</p>

</blockquote>

<em>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.</em>

<h2>543. Value initialization and default constructors</h2>

See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#543">core issue 543</a>.
<p>
Summary: Value-initialization still requires a well-formed
implicity-defined default constructor.
<p>
Rationale: Current implementations differ from the specification in
the standard, but agree with the proposed resolution.


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

See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#688">core issue 688</a>.
<p>
Summary: Provide broader reach of constant initialization, i.e. static
initialization.
<p>
Rationale: Provide necessary core language initialization support for
library types such as std::shared_ptr, std::once_flag, and
std::atomic_*.


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

See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#592">core issue 592</a>.
<p>
Summary: A confusing sentence in 15.2p2 suggests that only automatic
arrays are properly destroyed if the constructor for an element
throws.
<p>
Rationale: Seriously misleading and confusing standards text with a
simple resolution.


<h2>Deleted functions and triviality of classes</h2>

Lawrence Crowl and Jens Maurer will write a separate paper.

