<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>C++ Standard Evolution Closed Issues List</title>
<style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
</style>
</head>
<body>
<table>
<tr>
  <td align="left">Doc. no.</td>
  <td align="left">N3738</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2013-08-27</td>
</tr>
<tr>
  <td align="left">Project:</td>
  <td align="left">Programming Language C++</td>
</tr>
<tr>
  <td align="left">Reply to:</td>
  <td align="left">Ville Voutilainen &lt;<a href="mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt;</td>
</tr>
</table>
<h1>C++ Standard Evolution Closed Issues List (Revision R03)</h1>
<p>Revised 2013-08-27 at 16:08:33 UTC</p>

  <p>Reference ISO/IEC IS 14882:2003(E)</p>
  <p>Also see:</p>
    <ul>
      <li><a href="ewg-toc.html">Table of Contents</a> for all evolution issues.</li>
      <li><a href="ewg-index.html">Index by Section</a> for all evolution issues.</li>
      <li><a href="ewg-status.html">Index by Status</a> for all evolution issues.</li>
      <li><a href="ewg-active.html">Evolution Active Issues List</a></li>
      <li><a href="ewg-complete.html">Evolution Complete Issues List</a></li>
    </ul>

  <p>This document contains only evolution issues which have been closed
  by the Evolution Working Group as duplicates or not defects. That is,
  issues which have a status of <a href="ewg-active.html#Dup">Dup</a> or
  <a href="ewg-active.html#NAD">NAD</a>. See the <a href="ewg-active.html">Evolution Active Issues List</a> active issues and more
  information. See the <a href="ewg-complete.html">Evolution Complete Issues List</a> for issues considered
  accepted extensions.  The introductory material in that document also applies to
  this document.</p>

<h2>Revision History</h2>
<ul>
<li>R03: 2013-08-27 pre-Chicago mailing<ul>
<li><b>Summary:</b><ul>
<li>55 open issues, up by 7.</li>
<li>18 closed issues, up by 0.</li>
<li>73 issues total, up by 7.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 7 New issues: <a href="ewg-active.html#67">67</a>, <a href="ewg-active.html#68">68</a>, <a href="ewg-active.html#69">69</a>, <a href="ewg-active.html#70">70</a>, <a href="ewg-active.html#71">71</a>, <a href="ewg-active.html#72">72</a>, <a href="ewg-active.html#73">73</a>.</li>
</ul></li>
</ul>
</li>
<li>R02: 
2013-05-06 post-Bristol mailing
<ul>
<li><b>Summary:</b><ul>
<li>49 open issues, up by 2.</li>
<li>18 closed issues, up by 17.</li>
<li>67 issues total, up by 19.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 3 NAD issues: <a href="ewg-closed.html#53">53</a>, <a href="ewg-closed.html#54">54</a>, <a href="ewg-closed.html#55">55</a>.</li>
<li>Added the following 6 New issues: <a href="ewg-active.html#49">49</a>, <a href="ewg-active.html#50">50</a>, <a href="ewg-active.html#51">51</a>, <a href="ewg-active.html#52">52</a>, <a href="ewg-active.html#59">59</a>, <a href="ewg-active.html#65">65</a>.</li>
<li>Added the following 7 Open issues: <a href="ewg-active.html#56">56</a>, <a href="ewg-active.html#57">57</a>, <a href="ewg-active.html#58">58</a>, <a href="ewg-active.html#60">60</a>, <a href="ewg-active.html#63">63</a>, <a href="ewg-active.html#66">66</a>, <a href="ewg-active.html#66">66</a>.</li>
<li>Added the following 3 WP issues: <a href="ewg-complete.html#61">61</a>, <a href="ewg-complete.html#62">62</a>, <a href="ewg-complete.html#64">64</a>.</li>
<li>Changed the following 5 issues from New to NAD: <a href="ewg-closed.html#31">31</a>, <a href="ewg-closed.html#36">36</a>, <a href="ewg-closed.html#37">37</a>, <a href="ewg-closed.html#38">38</a>, <a href="ewg-closed.html#47">47</a>.</li>
<li>Changed the following 8 issues from New to Open: <a href="ewg-active.html#14">14</a>, <a href="ewg-active.html#30">30</a>, <a href="ewg-active.html#32">32</a>, <a href="ewg-active.html#33">33</a>, <a href="ewg-active.html#34">34</a>, <a href="ewg-active.html#35">35</a>, <a href="ewg-active.html#43">43</a>, <a href="ewg-active.html#48">48</a>.</li>
<li>Changed the following 6 issues from New to Ready: <a href="ewg-active.html#40">40</a>, <a href="ewg-active.html#41">41</a>, <a href="ewg-active.html#42">42</a>, <a href="ewg-active.html#44">44</a>, <a href="ewg-active.html#45">45</a>, <a href="ewg-active.html#46">46</a>.</li>
<li>Changed the following 2 issues from Open to WP: <a href="ewg-complete.html#16">16</a>, <a href="ewg-complete.html#25">25</a>.</li>
<li>Changed the following 4 issues from Ready to WP: <a href="ewg-complete.html#1">1</a>, <a href="ewg-complete.html#6">6</a>, <a href="ewg-complete.html#7">7</a>, <a href="ewg-complete.html#13">13</a>.</li>
</ul></li>
</ul>
</li>
<li>R01: 
2013-03-18 Pre-Bristol mailing
<ul>
<li><b>Summary:</b><ul>
<li>47 open issues, up by 47.</li>
<li>1 closed issues, up by 1.</li>
<li>48 issues total, up by 48.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issue: <a href="ewg-closed.html#39">39</a>.</li>
<li>Added the following 32 New issues: <a href="ewg-active.html#2">2</a>, <a href="ewg-active.html#5">5</a>, <a href="ewg-active.html#8">8</a>, <a href="ewg-active.html#10">10</a>, <a href="ewg-active.html#11">11</a>, <a href="ewg-active.html#12">12</a>, <a href="ewg-active.html#14">14</a>, <a href="ewg-active.html#15">15</a>, <a href="ewg-active.html#17">17</a>, <a href="ewg-active.html#19">19</a>, <a href="ewg-active.html#23">23</a>, <a href="ewg-active.html#24">24</a>, <a href="ewg-active.html#26">26</a>, <a href="ewg-active.html#28">28</a>, <a href="ewg-active.html#30">30</a>, <a href="ewg-active.html#31">31</a>, <a href="ewg-active.html#32">32</a>, <a href="ewg-active.html#33">33</a>, <a href="ewg-active.html#34">34</a>, <a href="ewg-active.html#35">35</a>, <a href="ewg-active.html#36">36</a>, <a href="ewg-active.html#37">37</a>, <a href="ewg-active.html#38">38</a>, <a href="ewg-active.html#40">40</a>, <a href="ewg-active.html#41">41</a>, <a href="ewg-active.html#42">42</a>, <a href="ewg-active.html#43">43</a>, <a href="ewg-active.html#44">44</a>, <a href="ewg-active.html#45">45</a>, <a href="ewg-active.html#46">46</a>, <a href="ewg-active.html#47">47</a>, <a href="ewg-active.html#48">48</a>.</li>
<li>Added the following 9 Open issues: <a href="ewg-active.html#4">4</a>, <a href="ewg-active.html#9">9</a>, <a href="ewg-active.html#16">16</a>, <a href="ewg-active.html#18">18</a>, <a href="ewg-active.html#21">21</a>, <a href="ewg-active.html#22">22</a>, <a href="ewg-active.html#25">25</a>, <a href="ewg-active.html#27">27</a>, <a href="ewg-active.html#29">29</a>.</li>
<li>Added the following 6 Ready issues: <a href="ewg-active.html#1">1</a>, <a href="ewg-active.html#3">3</a>, <a href="ewg-active.html#6">6</a>, <a href="ewg-active.html#7">7</a>, <a href="ewg-active.html#13">13</a>, <a href="ewg-active.html#20">20</a>.</li>
</ul></li>
</ul>
</li>
</ul>

</li>
</ul>

<h2>Closed Issues</h2>
<hr>
<h3><a name="31"></a>31. 
[tiny] constexpr functions must work at runtime
</h3>
<p><b>Section:</b> 5.19 [expr.const] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2012-10-16 <b>Last modified:</b> 2013-04-30</p>
<p><b>View all other</b> <a href="ewg-index.html#expr.const">issues</a> in [expr.const].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
constexpr functions are crippled by the fact that they have to be valid
at runtime.  Things that are tantalizingly close but you can't quite do
include returning a type that depends on the /value/ of a function
parameter:

<pre>
  constexpr auto ptr_array(int N) -> int(*)[N]
  { ... }
</pre>

If we would allow for constexpr functions that can only be evaluated at
compile time, we'd be able to do compile-time computation in a much less
template-heavy way.
</p>
<p>
Bristol 2013: Gregor thought that wrt general direction, constexpr is specifically not to have a constexpr-only model, and this issue would go into the opposite direction. NAD. 
</p>





<hr>
<h3><a name="36"></a>36. 
[tiny] no way to say "prefer this implicit conversion over that"
</h3>
<p><b>Section:</b> 12.3 [class.conv] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2012-10-24 <b>Last modified:</b> 2013-04-30</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
If a type has two implicit conversions, and I call a function with overloads for both target types, there's no way to disambiguate short of writing the conversion explicitly or adding another overload. It would be nice to be able to extend the partial order on conversions.
</p>
<p>
Bristol 2013: The group doesn't see this as something that we should pursue, and thinks it's a design error and users are advised just not to do this. NAD. 
</p>






<hr>
<h3><a name="37"></a>37. 
[tiny] Logical xor operator
</h3>
<p><b>Section:</b> 5 [expr] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2012-10-28 <b>Last modified:</b> 2013-04-30</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I have a low-priority issue for adding the (neglected) logical-xor operator, ^^.
This has traditionally been dismissed as un-necessary, as it is equivalent to boolean operator!=, and there is no short-circuiting benefit to justify adding it.

However, contextual conversions to 'bool' are handled specially for logical operators, and in that context it would be completing a hole in the language.

I wish I had a better example, but pulling from the standard library:
<pre>
   function&lt;void()&gt; a;
   function&lt;void()&gt; b;
   assert(a != b);  // does not compile
   assert(a ^^ b);  // would compile, and assert!
</pre>
</p>
<p>
Bristol 2013: EWG doesn't believe reopening this discussion, it's been tried previously and it's unlikely that a new round would lead to anything. NAD. 
</p>





<hr>
<h3><a name="38"></a>38. 
[tiny] Core issue 1542
</h3>
<p><b>Section:</b> 5.17 [expr.ass] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Mike Miller <b>Opened:</b> 2012-11-02 <b>Last modified:</b> 2013-04-30</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In Portland, CWG categorized a number of issues as "extension," which
I presume you
will automatically look at for potential EWG involvement once the new
revision of the
issues list is out.  I did want to mention one issue for which we will
be resolving part
and referring the other part to EWG: issue 1542 raises the question of
whether the
narrowing rules make sense for a compound assignment, e.g.,
<pre>
    char c;
    c += {1};
</pre>
CWG addressed a similar issue (1078) for an ordinary assignment and
decided that,
although the narrowing error was annoying in that case, it wasn't
worth the effort to
change the language because the workaround was simply to add a cast.  In this
case, however, there's no way to avoid the error (no place to put the
cast).  I think we'd
be happy with a revision of the narrowing rules that addressed both
this case and the
one in 1078; maybe the answer is just "why would you use the { } form
in a case like
this anyway?"
</p>

The Core issue link <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1542">here</a>.

<p>
In Bristol 2013: EWG thinks the answer _is_ just "why would you use the { } form in a case like this anyway?". NAD. 
</p>





<hr>
<h3><a name="39"></a>39. 
[tiny] local class and friendship
</h3>
<p><b>Section:</b> 11.3 [class.friend] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2012-11-10 <b>Last modified:</b> 2013-04-30</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
When we went from C++98 to C++03 we made nested classes implicitly
friend of their enclosing classes.  We seem to have missed doing the same
for local classes defined at member functions scopes.
</p>

Mike Miller explained:
<p>
Hmm.  I think that's already covered by 11p2:
<pre>
    A member of a class can also access all the names to which the class
    has access.  A local class of a member function may access the same
    names that the member function itself may access.
</pre>
By the definition of "private" in 11p1, a nested class has access to the
private members of the containing class; a member function of the nested
class therefore also has access to the private members of the containing
class; a local class of such a member function has the same access as
the member function; and a member function of the local class has the
same access as the local class, the same access as the containing
member function, and the same access as the nested class.
</p>





<hr>
<h3><a name="47"></a>47. 
[tiny] Fix the relation operators on standard templated types
</h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Nevin Liber <b>Opened:</b> 2013-02-05 <b>Last modified:</b> 2013-04-30</p>
<p><b>View all other</b> <a href="ewg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In C++11, all the containers, pair, tuple, etc. always have the relation operators defined for them (==, !=, &lt;, &gt;, &lt;=, &gt;=), even if the contained type does not have them; they just fail to compile if one tries to invoke them.  It would be better if those operators were SFINAEed out, so that generic code can then detect it and apply alternate strategies.
<p>
A use case I've have for this is when holding stateless objects that don't normally have the relation operators defined for them.
</p>
</p>
<p>
Bristol 2013: NAD. The operators have no opportunity for substitution failure.
</p>




<hr>
<h3><a name="53"></a>53. 
N3526 	Uniform initialization for arrays and class aggregate types
</h3>
<p><b>Section:</b> 8.5.1 [dcl.init.aggr] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Michael Price <b>Opened:</b> 2013-01-21 <b>Last modified:</b> 2013-04-30</p>
<p><b>View all other</b> <a href="ewg-index.html#dcl.init.aggr">issues</a> in [dcl.init.aggr].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3526.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3526.html</a>
</p>
<p>
Bristol 2013:  Stroustrup thought that the proposal is too aggressive and removes structure, and thought that the existing limitations are deliberate. Stroustrup and Sutton also pointed out that there are existing matrix types that deduce the shape of the matrix from the initializers, and this change would break such existing code.

No recommendation to move forward, considered NAD. 
</p>




<hr>
<h3><a name="54"></a>54. 
N3553 Proposing a C++1Y Swap Operator
</h3>
<p><b>Section:</b> 13.5 [over.oper] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2013-03-13 <b>Last modified:</b> 2013-04-30</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3553.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3553.pdf</a>
</p>
<p>
Bristol 2013: 
<p>
 Point d in "the basics": left operand is a modifiable lvalue expression and the right operand a modifiable glvalue. Why the asymmetry? JC: it's because the operator returns the lhs.
</p>
<p>
Bjarne: do we really need a new operator?
</p>
<p>
Matt: Maybe. swap() has annoying ADL problems.
</p>
<p>
Daveed: does it really solve them? The operator will still be found by ADL. Matt: maybe, since this would use an intrinsic in place of the general std::swap template.
</p>
<p>
Bjarne: But swap() isn't going away because of backward compatibility, so now we'll have swap() and operator:=:. "Probably a good idea if we had a time machine". Introducing a new operator, it has to be really central and helpful. If it got us out of our swap problem it might be good enough, but it isn't. Libraries aren't going to stop calling swap and if they did then all the specialized swap functions people have written wouldn't get invoked. Problems are real, but the benefits it would have (i.e. what problem it would actually solve) aren't sufficiently explained. Too likely that swap and :=: would coexist indefinitely and that all the problems of swap would persist.
</p>
<p>
General agreement that this is a real problem but that it's not clear why this would solve them. We will not proceed with this. 
</p>
<p>
No recommendation to move forward, considered NAD. 
</p>
</p>




<hr>
<h3><a name="55"></a>55. 
N3578 Proposing the Rule of Five
</h3>
<p><b>Section:</b> 12.8 [class.copy] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2013-03-12 <b>Last modified:</b> 2013-04-30</p>
<p><b>View all other</b> <a href="ewg-index.html#class.copy">issues</a> in [class.copy].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3578.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3578.pdf</a>
</p>
<p>
Bristol 2013: Considered NAD, too early for such a breaking change after
C++11, breaks valid programs that use C++11 semantics (defaulted destructor
outside class definition, otherwise generated members, used with various
smart pointer members).
</p>
</p>




</body>
</html>
