<html>
<head>
<title>n2173 Core Extensions for Evolution</title>
</head>

<body>
<h1>Core Extensions for Evolution</h1>
Document Number: n2173(07-0033)<br/>
2007-03-09<br/>
Alisdair Meredith &lt;alisdair.meredith@uk.renaultf1.com><br/>

<h2>Background</h2>
A number of issues have been resolved by the Core Working Group as <em>extension requests</em> better addressed in a future C++ standard.  These were handed over to the Evolution Working Group at the October 2002 meeting.  Unfortunately it appears the EWG did not pick up these issues and I believe they have been quietly neglected for C++09.  The intent of this paper is to make a hasty review of those issues to confirm that there is nothing important that must be addressed.
<p>
There are currently 10 issues with this status, so I shall try to summarise them quickly below.  For each I recommend one of 3 actions:
<li> Acknowledge issue is important and try to resolve it for C++09</li>
<li> Agree issue is interesting, and 'Open' it to be addressed after C++09</li>
<li> Suggest issue is not interesting enough, or can be met with other proposals - move back to Core as NAD.</li>
<p>
The issues are generally on the scale of a regular defect report, and as such it is recommended that Core take care of the technical work (wording) once the EWG gives a direction.


<h2>Linkage issues</h2>

<strong># 13: extern "C" fns as template params</strong><br/>
Recommend: <em>resolve for C++09</em><p/>
This closes a hole in the type system, and the question still comes up today.
Recommend resolving in C++09, possibly with an attribute-like mechanism (see n2224 in this same mailing)
<p>
<strong>#107: linkage of operator functions</strong><br/>
Recommend <em>NAD</em><br/>
<strong>#168: C linkage of static members</strong><br/>
Recommend: <em>NAD</em><br/>
<p>
Both have issues promoting functions out of class and into global namespace.
<p>


<h2>Memory Management</h2>

<strong>#220: require de-allocation not throw</strong><br/>
Possible link with library issues 206 and 627<br/>
Recommend: <em>resolve for C++09</em><p/>
This should be given a clear answer for C++09, but I don't want to prejudge whether it should be yes or no.
<p>

<strong>#256: overflow calculating size of new array</strong><br/>
Recommend: <em>resolve for C++09</em><p/>
This improves program correctness and robustness for minimal cost - although I have not evaluated ABI concerns.
<p>


<h2>Template Issues</h2>

<strong>#150: template template and default params</strong></br>
Recommend: <em>Open</em><p/>
It could be interesting addition to the language, but is too late to receive suffient attention for C++09
<p>
<strong>#229: partial specialization of function templates</strong><br/>
Recommend: <em>NAD</em><p/>
Most of this functionality can be offered through concept_maps, so I suggest it is not worth the effort to write such a tricky extension purely for the benefit of unconstrained templates in the future.
<p>

<h2>Miscellaneous</h2>

<strong>#6: enhanced support for copy ellision when inlining</strong><br/>
Recommend: <em>Open</em><p/>
This looks like a valid concern, but with ill-defined scope it is probably too big a change to adopt this close to the C++09 deadline.
<p>
<strong>#294: can static_cast drop exception specs</strong><br/>
Recommend: <em>NAD</em><p/>
<p>
<strong>#359: Type definition inside anonymous union</strong><br/>
Recommend: <em>NAD</em><p/>
The functionality on offer seems minor relative to the effort involved to support it.
<p>


<body>
</html>