<html>
<head>
<title>Expedited core issues handling</title>
</head>

<body>
N2707 = 08-0217<br/>
Jens Maurer &lt;Jens.Maurer@gmx.net><br/>
2008-07-25

<h1>Expedited core issues handling</h1>

<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.
It is intended to publish an update of this paper in the pre-San
Francisco mailing.
</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.


<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 (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.
<p>
Note: A proposed resolution is not yet available in the core issues list.


<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: 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>
Note: A proposed resolution is not yet available in the core issues list.


<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>
Note: An agreeable proposed resolution is not yet available in the
core issues list.


<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: A proposed resolution is not yet available in the core issues list.


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

