<!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">N4103</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2014-07-01</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 R08)</h1>
<p>Revised 2014-07-01 at 21:07:12 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>R08: 2014-07-02 post-Rapperswil mailing<ul>
<li><b>Summary:</b><ul>
<li>74 open issues, down by 12.</li>
<li>60 closed issues, up by 27.</li>
<li>134 issues total, up by 15.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 3 NAD issues: <a href="ewg-closed.html#124">124</a>, <a href="ewg-closed.html#132">132</a>, <a href="ewg-closed.html#133">133</a>.</li>
<li>Added the following 3 New issues: <a href="ewg-active.html#128">128</a>, <a href="ewg-active.html#129">129</a>, <a href="ewg-active.html#130">130</a>.</li>
<li>Added the following 5 Open issues: <a href="ewg-active.html#120">120</a>, <a href="ewg-active.html#122">122</a>, <a href="ewg-active.html#125">125</a>, <a href="ewg-active.html#126">126</a>, <a href="ewg-active.html#127">127</a>.</li>
<li>Added the following 2 Ready issues: <a href="ewg-active.html#121">121</a>, <a href="ewg-active.html#131">131</a>.</li>
<li>Added the following 2 Resolved issues: <a href="ewg-complete.html#123">123</a>, <a href="ewg-complete.html#134">134</a>.</li>
<li>Changed the following 2 issues from New to Dup: <a href="ewg-closed.html#77">77</a>, <a href="ewg-closed.html#103">103</a>.</li>
<li>Changed the following 14 issues from New to NAD: <a href="ewg-closed.html#70">70</a>, <a href="ewg-closed.html#85">85</a>, <a href="ewg-closed.html#89">89</a>, <a href="ewg-closed.html#90">90</a>, <a href="ewg-closed.html#91">91</a>, <a href="ewg-closed.html#95">95</a>, <a href="ewg-closed.html#99">99</a>, <a href="ewg-closed.html#100">100</a>, <a href="ewg-closed.html#104">104</a>, <a href="ewg-closed.html#105">105</a>, <a href="ewg-closed.html#109">109</a>, <a href="ewg-closed.html#110">110</a>, <a href="ewg-closed.html#112">112</a>, <a href="ewg-closed.html#117">117</a>.</li>
<li>Changed the following 11 issues from New to Open: <a href="ewg-active.html#88">88</a>, <a href="ewg-active.html#92">92</a>, <a href="ewg-active.html#96">96</a>, <a href="ewg-active.html#98">98</a>, <a href="ewg-active.html#101">101</a>, <a href="ewg-active.html#102">102</a>, <a href="ewg-active.html#106">106</a>, <a href="ewg-active.html#108">108</a>, <a href="ewg-active.html#113">113</a>, <a href="ewg-active.html#116">116</a>, <a href="ewg-active.html#118">118</a>.</li>
<li>Changed the following issue from WP to Open: <a href="ewg-active.html#22">22</a>.</li>
<li>Changed the following 2 issues from New to Ready: <a href="ewg-active.html#111">111</a>, <a href="ewg-active.html#119">119</a>.</li>
<li>Changed the following 2 issues from New to Resolved: <a href="ewg-complete.html#8">8</a>, <a href="ewg-complete.html#67">67</a>.</li>
<li>Changed the following 4 issues from Ready to Resolved: <a href="ewg-complete.html#40">40</a>, <a href="ewg-complete.html#42">42</a>, <a href="ewg-complete.html#44">44</a>, <a href="ewg-complete.html#45">45</a>.</li>
<li>Changed the following issue from Ready to WP: <a href="ewg-complete.html#46">46</a>.</li>
</ul></li>
</ul>
</li>
<li>R07: 
2014-05-20 pre-Rapperswil mailing
<ul><li><b>Summary:</b><ul>
<li>86 open issues, up by 6.</li>
<li>33 closed issues, up by 0.</li>
<li>119 issues total, up by 6.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 5 New issues: <a href="ewg-active.html#115">115</a>, <a href="ewg-active.html#116">116</a>, <a href="ewg-active.html#117">117</a>, <a href="ewg-active.html#118">118</a>, <a href="ewg-active.html#119">119</a>.</li>
<li>Added the following Open issue: <a href="ewg-active.html#114">114</a>.</li>
</ul></li>
</ul>
</li>
<li>R06: 
2014-02-21 post-Issaquah mailing
<ul><li><b>Summary:</b><ul>
<li>80 open issues, up by 31.</li>
<li>33 closed issues, up by 3.</li>
<li>113 issues total, up by 34.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 3 NAD issues: <a href="ewg-closed.html#87">87</a>, <a href="ewg-closed.html#97">97</a>, <a href="ewg-closed.html#107">107</a>.</li>
<li>Added the following 26 New issues: <a href="ewg-active.html#83">83</a>, <a href="ewg-active.html#85">85</a>, <a href="ewg-active.html#88">88</a>, <a href="ewg-active.html#89">89</a>, <a href="ewg-active.html#90">90</a>, <a href="ewg-active.html#91">91</a>, <a href="ewg-active.html#92">92</a>, <a href="ewg-active.html#93">93</a>, <a href="ewg-active.html#94">94</a>, <a href="ewg-active.html#95">95</a>, <a href="ewg-active.html#96">96</a>, <a href="ewg-active.html#98">98</a>, <a href="ewg-active.html#99">99</a>, <a href="ewg-active.html#100">100</a>, <a href="ewg-active.html#101">101</a>, <a href="ewg-active.html#102">102</a>, <a href="ewg-active.html#103">103</a>, <a href="ewg-active.html#104">104</a>, <a href="ewg-active.html#105">105</a>, <a href="ewg-active.html#106">106</a>, <a href="ewg-active.html#108">108</a>, <a href="ewg-active.html#109">109</a>, <a href="ewg-active.html#110">110</a>, <a href="ewg-active.html#111">111</a>, <a href="ewg-active.html#112">112</a>, <a href="ewg-active.html#113">113</a>.</li>
<li>Added the following 3 Open issues: <a href="ewg-active.html#82">82</a>, <a href="ewg-active.html#84">84</a>, <a href="ewg-active.html#86">86</a>.</li>
<li>Added the following 2 Ready issues: <a href="ewg-active.html#80">80</a>, <a href="ewg-active.html#81">81</a>.</li>
</ul></li>
</ul>
</li>
<li>R05: 
2014-01-17 pre-Issaquah mailing
<ul><li><b>Summary:</b><ul>
<li>49 open issues, up by 3.</li>
<li>30 closed issues, up by 0.</li>
<li>79 issues total, up by 3.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 3 New issues: <a href="ewg-active.html#77">77</a>, <a href="ewg-active.html#78">78</a>, <a href="ewg-active.html#79">79</a>.</li>
<li>Changed the following issue from New to Open: <a href="ewg-active.html#72">72</a>.</li>
<li>Changed the following issue from Ready to Open: <a href="ewg-active.html#41">41</a>.</li>
</ul></li>
</ul>
</li>
<li>R04: 
2013-10-11 post-Chicago mailing
<ul><li><b>Summary:</b><ul>
<li>46 open issues, down by 9.</li>
<li>30 closed issues, up by 12.</li>
<li>76 issues total, up by 3.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 3 Open issues: <a href="ewg-active.html#74">74</a>, <a href="ewg-active.html#75">75</a>, <a href="ewg-active.html#76">76</a>.</li>
<li>Changed the following 4 issues from New to NAD: <a href="ewg-closed.html#12">12</a>, <a href="ewg-closed.html#68">68</a>, <a href="ewg-closed.html#69">69</a>, <a href="ewg-closed.html#73">73</a>.</li>
<li>Changed the following 2 issues from Open to NAD: <a href="ewg-closed.html#32">32</a>, <a href="ewg-closed.html#33">33</a>.</li>
<li>Changed the following 6 issues from New to Open: <a href="ewg-active.html#2">2</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#52">52</a>, <a href="ewg-active.html#71">71</a>.</li>
<li>Changed the following 4 issues from Open to WP: <a href="ewg-complete.html#18">18</a>, <a href="ewg-complete.html#21">21</a>, <a href="ewg-complete.html#22">22</a>, <a href="ewg-complete.html#27">27</a>.</li>
<li>Changed the following 2 issues from Ready to WP: <a href="ewg-complete.html#3">3</a>, <a href="ewg-complete.html#20">20</a>.</li>
</ul></li>
</ul>
</li>
<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>

<h2>Closed Issues</h2>
<hr>
<h3><a name="12"></a>12. 
N3410 Rich Pointers with Dynamic and Static Introspection
</h3>
<p><b>Section:</b> 20.9 [meta] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Dean Michael Berris <b>Opened:</b> 2012-09-18 <b>Last modified:</b> 2014-06-13</p>
<p><b>View other</b> <a href="ewg-index-open.html#meta">active issues</a> in [meta].</p>
<p><b>View all other</b> <a href="ewg-index.html#meta">issues</a> in [meta].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3410.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3410.pdf</a>
<p>To be handled by the Reflection Study Group (SG7).</p>
<p>Discussed by SG7 in Chicago, SG7 doesn't think the paper is going
into the right direction and the paper author has acknowledged so.</p>





<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> 2014-06-13</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="32"></a>32. 
[tiny] Templated constructor accidentally preferred over copy constructor
</h3>
<p><b>Section:</b> 13 [over] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Nevin Liber <b>Opened:</b> 2012-10-19 <b>Last modified:</b> 2014-06-13</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<pre>

struct Silly
{
    template&lt;class... Ts&gt;
    Silly(Ts&amp;&amp;...)
    {}
};

int main()
{
    Silly s;
    Silly t(s);	// Silly::Silly(Ts &amp;&amp;...) [Ts = &lt;Silly &amp;&gt;]
    const Silly u;
    Silly v(u); // calls Silly::Silly(Silly const&amp;)
}
</pre>

The problem is that users expect the copy constructor to be called in both situations.

Note:  you do not need variadics for this; it made the example smaller.  Also, this issue existed in C++03, but rarely happened in practice because templated parameters were usually declared const T&amp;.
</p>
<p>
Bristol 2013: Sutton and Gregor proposed various work-arounds, like additional overloads and constraints. Stroustrup asked whether having a copying template have different semantics from a copy constructor isn't an error, and Gregor explained that tuples run into that issue and they have different semantics for the template. The submitter is encouraged to write a paper, and practical examples are desirable. 
</p>
<p>
The EWG decided to close this issue as a NAD in Chicago 2013.
</p>





<hr>
<h3><a name="33"></a>33. 
[tiny] contextual bool conversion from scoped enum
</h3>
<p><b>Section:</b> 7.2 [dcl.enum] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2012-10-20 <b>Last modified:</b> 2014-06-13</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 Beman's filesystem code, I found the following problem, which he
didn't see because he's been building with MSVC 10:

A scoped enum defined at
<p>
<a href="https://github.com/Beman/filesystem-proposal/blob/master/include/boost/filesystem/operations.hpp#L230">https://github.com/Beman/filesystem-proposal/blob/master/include/boost/filesystem/operations.hpp#L230</a>
</p>
is used like

<p>
if (opts &amp; copy_options::skip_existing) ++ct;
</p>

at 
<p>
<a href="https://github.com/Beman/filesystem-proposal/blob/master/src/operations.cpp#L773">https://github.com/Beman/filesystem-proposal/blob/master/src/operations.cpp#L773</a>.
</p>

This causes an error like:

<p>../../../libs/filesystem/src/operations.cpp:773:9: error: value of
type 'boost::filesystem::copy_options' is not contextually convertible
to 'bool'
</p>

I believe it makes sense to define a contextual conversion to bool for
certain scoped enumerations, but I don't see a way to do it. I do see
a way to overload &amp; to return bool, but that seems to prevent using &amp;
to remove bits from a value, which shouldn't always be prevented.
</p>
<p>
Bristol 2013: Stroustrup pointed out that the existing behavior is deliberately trying to avoid supporting anything like this, in order to play safe. He further explained that allowing member functions for scoped enums has been attempted but the attempts failed. Gregor pointed out that not all scoped enums have a zero value, so doing it generally is hard. Stroustrup said he would want to have member functions for enums. Yasskin said he's not interested in writing a paper. Other people are invited to do so. 
</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> 2014-06-13</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> 2014-06-13</p>
<p><b>View all other</b> <a href="ewg-index.html#expr">issues</a> in [expr].</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> 2014-06-13</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> 2014-06-13</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> 2014-06-13</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> 2014-06-13</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. 
N3746, 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> 2014-06-13</p>
<p><b>View all other</b> <a href="ewg-index.html#over.oper">issues</a> in [over.oper].</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://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3746.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3746.pdf</a>
</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. 
N3839, Proposing the Rule of Five, v2, 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> 2014-06-13</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/2014/n3839.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3839.pdf</a>
</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>
Issaquah 2014: Brown pointed out that he wasn't in Bristol. Vandevoorde
explained that users rely on the current semantics, and that there's
existing code in various library headers that would break with this
change, and users cannot necessarily fix that breakage due to licensing
issues that prevent modifying such code. Voutilainen pointed out that
while there are cases where not suppressing copy operations when
a destructor is declared leads to incorrect code, there's also quite
many cases where the code is correct. Brown opined that he doesn't
want to close the door for this kind of changes forever, but EWG
didn't see a practical way to be able to enable this rule. The
issue therefore stays closed.
</p>
</p>




<hr>
<h3><a name="68"></a>68. 
[tiny] C++ DR about global placement array new
</h3>
<p><b>Section:</b> 5.3.4 [expr.new] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Thomas Koeppe <b>Opened:</b> 2013-04-22 <b>Last modified:</b> 2014-06-13</p>
<p><b>View all other</b> <a href="ewg-index.html#expr.new">issues</a> in [expr.new].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Basically, I would like to file a Defect Report: The global array placement new, as described in C++11, 5.3.4/10-12, is unusable. The reason for this is that the standard allows the operator to consume an arbitrary amount of memory, which is impossible for the user to learn, and thus impossible to provide. The fix is to remove the ability for placement-new to require more size than required for the array itself to the allocation function.
</p>
<p>
Current wording, in 5.3.4/12 says:
<pre>
    new(2,f) T[5] results in a call of operator new[](sizeof(T)*5+y,2,f)
</pre>
    Here, x and y are non-negative unspecified values representing array allocation overhead; the result of the new-expression will be offset by this amount from the value returned by operator new[].
</p>
<p>
Unfortunately, the presence of "y" means that it is impossible to pass a usable address to placement-array-new:
<pre>
    void * addr = std::malloc(?);
    new (addr) T[10];
</pre>
</p>
<p>
In the above, it is impossible to know the required argument for malloc, since the placement-new can ask for sizeof(T) * 10 + y bytes for any y.
</p>
<p>
The fix would be to remove the possiblity of placement-new requiring more memory for arrays, i.e. insert into 5.3.4/10 something like:
<pre>
    A new-expression passes the amount of space requested to the allocation 
    function as the first argument of type std::size_t. That argument shall 
    be no less than the size of the object being created; it may be greater 
    than the size of the object being created only if the object is an array 
    and the new-expression is a default new-expression.
</pre>
</p>
<p>
What do you think? I don't think the change could break anything, since nothing could be using placement-array-new at the moment, and it makes sense that a placement version doesn't require extra space, since the caller already knows the array size and has to perform destruction manually anyway.
</p>
<p> Mike Miller points out the following:
</p>
<p>
You're not the first one to notice a problem with this; see
</p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#476">http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#476</a>
</p>
<p>
To summarize, CWG agreed that that's a problem but felt that the
resolution was more appropriately handled in EWG, since it requires
evaluations of the tradeoffs of various possible options to address it.
Your approach, for example, focuses on the placement operator new
provided by the library, which simply runs the constructor(s) on a
previously-allocated buffer.  However, that's not the only use of the
placement new syntax, which can pass arbitrary arguments to
allocation functions that actually do allocate memory, and it's not
clear that none of those will need to add padding similar to the way
the standard allocation function does.
</p>
<p>
In Chicago 2013, EWG deemed this NAD. Remarks from the discussion:
"The problem is in trying to use array new to put an array into pre-existing storage. We don't need to use array new for that; just construct them." 
and "You can find what padding was used after the fact, because new returns a pointer to the start of the first element of the array. But that can happen only after UB. "
</p>




<hr>
<h3><a name="69"></a>69. 
[tiny] Returning a void expression from a constructor or destructor
</h3>
<p><b>Section:</b> 6.6.3 [stmt.return] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2013-07-02 <b>Last modified:</b> 2014-06-13</p>
<p><b>View all other</b> <a href="ewg-index.html#stmt.return">issues</a> in [stmt.return].</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 thread on std-discussion[1] has highlighted that
<pre>
  return E;
</pre>
</p>
<p>
where E has type void is valid in a function with a return type of 'void' but not valid in a constructor or destructor. There is implementation variance here, and we have examples of code which very reasonably wants to use "return E;" in a constructor, from within the expansion of a macro, and fails on some compilers due to this rule. The inconsistency between "return;" and "return void();" seems extremely jarring here, and I'd like to propose that we treat this as a defect.
</p>
<p>
(I'm not suggesting that we treat constructors and destructors as having a return type of 'void', as was suggested on the thread on std-discussion, but I'm not opposed to it.)
</p>
<p>
[1] <a href="https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/ehqGBMsswjk">https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/ehqGBMsswjk</a>
</p>
<p>Discussed in Chicago 2013 (as the NB comment FI 6), no consensus
to make a change, NB comment rejected, the issue is NAD. Vandevoorde said this rubs him the wrong way, because this suggests that a constructor returns nothing even though that's not the case.</p>




<hr>
<h3><a name="70"></a>70. 
[tiny] Const in expressions
</h3>
<p><b>Section:</b> 5.2 [expr.post] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2013-06-06 <b>Last modified:</b> 2014-06-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>
Example:
<pre>
#include &lt;string>
using namespace std;
int main() {
 const string{ "Hello" };                   // 1: error
 "xyzzy" + const string{"Hello"};           // 2: error
 typedef const string const_string;
 const_string{"Hello"};                     // 3: ok
 "xyzzy" + const_string{"Hello"};           // 4: ok
 unsigned long{0};                          // 5: error
 42ul + unsigned long{0};                   // 6: error

 typedef unsigned long unsigned_long;
 unsigned_long{0};                          // 7: ok
 42ul + unsigned_long{0};                   // 8: ok

}
</pre>
Sutter says:
<p>
The issue is "lines 1 to 8 below should all work." That they don't is just because of the reason Nikolay pointed out using line 1 below as an example:
<p>
> The error is purely syntactic: 'const string' is not a simple-type-specifier
</p>
</p>
</p>
<p>
Richard Smith points out the following:
<p>
I can't comment on what was noticed in the abstract, but I was certainly aware of all the above cases. And the rules make sense to me: function-style casts are supposed to be function-style, and the above error cases doesn't look like a function call (and not just because you've put the paren next to the type in the function-call-like cases, and added an extra space in the other cases!).
<p>
I'm not sure exactly what rules you're proposing, but I hope we don't make this valid:
</p>
<pre>
  struct A { int n; }; // ok, struct definition
  struct A { 0 }; // might now be an expression?
</pre>
</p>
</p>
<p>
Regarding using a parenthesized type as a work-around, Sutter explained:
<p>
I think it needs to be an open EWG issue after all, because as Johannes pointed out the workaround doesn't work because it can't call multi-argument constructors, such as that
<pre>
    (const vector&lt;int>)( 1, 2  )
</pre>
drops the 1 on the floor and creates a vector containing two zeroes.
And that it doesn't work for list initializations, such as that
<pre>
    (unsigned int){ 1, 2, 3, 4 }   // C compound literal(?!)
</pre>
doesn't work.
</p>
</p>
<p>
Deemed post-C++14 material in Chicago 2013. A paper is needed.
</p>
<p>Discussed in Rapperswil 2014. The consensus of EWG is that this is not a promising direction. The workaround is to add a typedef. Closing the issue as NAD.
</p>




<hr>
<h3><a name="73"></a>73. 
N3681 Auto and braced-init lists
</h3>
<p><b>Section:</b> 7.1.6.4 [dcl.spec.auto] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2013-05-02 <b>Last modified:</b> 2014-06-13</p>
<p><b>View all other</b> <a href="ewg-index.html#dcl.spec.auto">issues</a> in [dcl.spec.auto].</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/n3681.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3681.html</a>
</p>
<p>
Discussed in Chicago 2013 (as FI 3 NB comment), no consensus to change
(concerns about breaking existing code), the NB comment is rejected, the
issue is NAD.
</p>




<hr>
<h3><a name="77"></a>77. 
N3772 Changing the type of address-of-member expression
</h3>
<p><b>Section:</b> 5.3 [expr.unary] <b>Status:</b> <a href="ewg-active.html#Dup">Dup</a>
 <b>Submitter:</b> David Rodrguez Ibeas <b>Opened:</b> 2013-09-05 <b>Last modified:</b> 2014-07-02</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Dup">Dup</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3772.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3772.pdf</a>
</p>
<p>The issue was discussed in Rapperswil 2014. See issue <a href="ewg-closed.html#89">89</a>. Closing as a duplicate.</p>




<hr>
<h3><a name="85"></a>85. 
N3879 Explicit Flow Control: break label, goto case and explicit switch
</h3>
<p><b>Section:</b> 6.4.2 [stmt.switch] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Andrew Tomazos <b>Opened:</b> 2014-01-16 <b>Last modified:</b> 2014-07-02</p>
<p><b>View all other</b> <a href="ewg-index.html#stmt.switch">issues</a> in [stmt.switch].</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/2014/n3879.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3879.pdf</a>
</p>
<p>Discussed in Rapperswil 2014.</p>
<p>Straw poll, proposal as a whole:</p>
<p>SF 1 - WF 1 - N 1 - WA 13 - SA 10</p>
<p>"break label;" + "continue label;":</p>
<p>SF 3 - WF 8 - N 4 - WA 9 - SA 3</p>
<p>Proposal not adopted, closing as NAD.</p>




<hr>
<h3><a name="87"></a>87. 
N3897 Auto-type members
</h3>
<p><b>Section:</b> 9.2 [class.mem] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-06-13</p>
<p><b>View all other</b> <a href="ewg-index.html#class.mem">issues</a> in [class.mem].</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/2014/n3897.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3897.html</a>
</p>
<p>
This paper captures the reasoning why Faisal Vali came to the
conclusion that we do not want to strive for having auto-typed
members.
</p>




<hr>
<h3><a name="89"></a>89. 
[tiny] Core issue 203, Type of address-of-member expression
</h3>
<p><b>Section:</b> 5.3.1 [expr.unary.op] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Lisa Lippincott <b>Opened:</b> 2000-02-08 <b>Last modified:</b> 2014-06-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>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#203">Core issue 203</a>.
</p>
<p>
Discussed in Rapperswil 2014. EWG thought that the change to existing
semantics would practically require a time machine, and noted that
these semantics didn't appear by accident. Changing the semantics
was estimated to break too much existing code, so closing as NAD.
</p>




<hr>
<h3><a name="90"></a>90. 
[tiny] Core issue 476, Determining the buffer size for placement new
</h3>
<p><b>Section:</b> 5.3.4 [expr.new] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Ben Hutchings <b>Opened:</b> 2004-09-14 <b>Last modified:</b> 2014-06-30</p>
<p><b>View all other</b> <a href="ewg-index.html#expr.new">issues</a> in [expr.new].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#476">Core issue 476</a>.
</p>
<p>
Discussed in Rapperswil 2014. EWG thinks there's no design defect here,
and suggests that a placement array new should not have such 
implementation-defined overhead. EWG suggests that CWG should
clarify that placement array new T[n] needs n*sizeof(T) bytes of memory, 
and clarify that an operator delete must only be called if the corresponding operator new has been called. Ask James Dennett/Chandler Carruth for any more feedback. 
</p>




<hr>
<h3><a name="91"></a>91. 
[tiny] Core issue 622, Relational comparisons of arbitrary pointers
</h3>
<p><b>Section:</b> 5.9 [expr.rel] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2007-02-26 <b>Last modified:</b> 2014-06-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>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#622">Core issue 622</a>.
</p>
<p>
Discussed in Rapperswil 2014. EWG finds that there's a preference for defining this, but some architectures have separate memory spaces for data/code/constants, it's non-trivial to define.</p>
<p>
Closing as NAD. If someone wants to argue that the results of such
pointer comparisons should be implementation-defined, papers are welcome.
</p>




<hr>
<h3><a name="95"></a>95. 
[tiny] Core issue 822, Additional contexts for template aliases
</h3>
<p><b>Section:</b> 4.11 [conv.mem] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> UK <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2014-06-30</p>
<p><b>View all other</b> <a href="ewg-index.html#conv.mem">issues</a> in [conv.mem].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#822">Core issue 822</a>. 
</p>
<p>
Discussed in Rapperswil 2014. EWG failed to find sufficient motivation
for this extension, closing as NAD.
</p>




<hr>
<h3><a name="97"></a>97. 
[tiny] Core issue 947, Deducing type template arguments from default function arguments
</h3>
<p><b>Section:</b> 14.8.3 [temp.over] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2009-07-27 <b>Last modified:</b> 2014-06-13</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#947">Core issue 947</a>.
</p>
<p>
Issaquah 2014: EWG doesn't think it's generally implementable. A restricted
implentation could be separately explored.
</p>




<hr>
<h3><a name="99"></a>99. 
[tiny] Core issue 1259, Deleting a POD via a pointer to base
</h3>
<p><b>Section:</b> 5.3.5 [expr.delete] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2010-03-10 <b>Last modified:</b> 2014-06-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>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1259">Core issue 1259</a>.
</p>
<p>See also the discussion thread starting at <a href="https://groups.google.com/a/isocpp.org/d/msg/std-proposals/9PxiUu0Tr1k/3gextFEMi8sJ">https://groups.google.com/a/isocpp.org/d/msg/std-proposals/9PxiUu0Tr1k/3gextFEMi8sJ</a>.
</p>
<p>
Discussed in Rapperswil 2014. Dennett pointed out that this idea doesn't
work with sized deallocations, which we voted in. Voutilainen pointed
out that sanitizers can catch such misuses if it's undefined behaviour.
Closing as NAD.
</p>




<hr>
<h3><a name="100"></a>100. 
[tiny] Core issue 1272, Implicit definition of static data member of const literal type
</h3>
<p><b>Section:</b> 9.4.2 [class.static.data] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2011-03-18 <b>Last modified:</b> 2014-06-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>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1272">Core issue 1272</a>.
</p>
<p>
Discussed in Rapperswil 2014. Vandevoorde pointed out that there are
backwards compatibility issues, Dennett pointed out that the proposed
resolution makes the language more irregular and less teachable. Closing
as NAD.
</p>




<hr>
<h3><a name="103"></a>103. 
[tiny] Core issue 1426, Allowing additional parameter types in defaulted functions
</h3>
<p><b>Section:</b> 8.4.2 [dcl.fct.def.default] <b>Status:</b> <a href="ewg-active.html#Dup">Dup</a>
 <b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2011-12-08 <b>Last modified:</b> 2014-07-02</p>
<p><b>View all other</b> <a href="ewg-index.html#dcl.fct.def.default">issues</a> in [dcl.fct.def.default].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Dup">Dup</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1426">Core issue 1426</a>.
</p>
<p>Covered by the paper we expect from <a href="ewg-active.html#101">101</a>.</p>




<hr>
<h3><a name="104"></a>104. 
[tiny] Core issue 1433, trailing-return-type and point of declaration
</h3>
<p><b>Section:</b> 3.3.2 [basic.scope.pdecl] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Jason Merrill <b>Opened:</b> 2011-12-20 <b>Last modified:</b> 2014-07-02</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1433">Core issue 1433</a>.
</p>
<p>Discussed in Rapperswil 2014. EWG is sympathetic to the request, but we have significant concerns about the implementation and specification complexity. Close as NAD without prejudice. We'd need more detail. Asking vendors including Microsoft and Oracle how implementable this is for them would be a courtesy.</p>




<hr>
<h3><a name="105"></a>105. 
[tiny] Core issue 1451, Objects with no linkage in non-type template arguments
</h3>
<p><b>Section:</b> 14.3.2 [temp.arg.nontype] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-02-01 <b>Last modified:</b> 2014-06-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>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1451">Core issue 1451</a>.
</p>
<p>Discussed in Rapperswil 2014. It's not clear whether this is limited to static storage duration objects. EWG is worried about implications beyond that, and for Type&lt;"abs">. How would this work with function templates? For (non-template) functions, a workaround is to declare the object at namespace scope, but then you don't get the lazy initialization guarantees.</p>
<p>Vandevoorde states that he'd like to actively vote against this. This would open special cases w.r.t. how we handle address constant expressions. 5.19 uses the same mechanism for string literals and static variables, both with no linkage. And we don't want to get into Type&lt;"abs"> being distinct form Type&lt;"abs">.</p> 




<hr>
<h3><a name="107"></a>107. 
[tiny] Core issue 1519, Conflicting default and variadic constructors
</h3>
<p><b>Section:</b> 14.5.3 [temp.variadic] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2012-07-09 <b>Last modified:</b> 2014-06-13</p>
<p><b>View other</b> <a href="ewg-index-open.html#temp.variadic">active issues</a> in [temp.variadic].</p>
<p><b>View all other</b> <a href="ewg-index.html#temp.variadic">issues</a> in [temp.variadic].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1519">Core issue 1519</a>.
</p>
<p>
Issaquah 2014: there is a SFINAE work-around
and Concepts Lite will make the work-around much easier.
</p>




<hr>
<h3><a name="109"></a>109. 
[tiny] Core issue 1564, Template argument deduction from an initializer list
</h3>
<p><b>Section:</b> 7.1.6.4 [dcl.spec.auto] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Faisal Vali <b>Opened:</b> 2012-10-09 <b>Last modified:</b> 2014-07-01</p>
<p><b>View all other</b> <a href="ewg-index.html#dcl.spec.auto">issues</a> in [dcl.spec.auto].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1564">Core issue 1564</a>.
</p>
<p>Discussed in Rapperswil 2014. EWG points out that auto deduction is moving
to the opposite direction, and there's a reason why the suggested deduction
isn't done, Vandevoorde showed an example of an overload set including
an unconstrained template and a function taking a vector, and explained that 
the rules currently choose the function taking a vector, and advised against
changing that. Closing as NAD.</p>




<hr>
<h3><a name="110"></a>110. 
[tiny] Core issue 1577, Unnecessary restrictions on partial specializations
</h3>
<p><b>Section:</b> 14.5.5 [temp.class.spec] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Jeremiah Willcock <b>Opened:</b> 2012-10-19 <b>Last modified:</b> 2014-06-30</p>
<p><b>View all other</b> <a href="ewg-index.html#temp.class.spec">issues</a> in [temp.class.spec].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1577">Core issue 1577</a>.
</p>
<p>
Discussed in Rapperswil 2014. EWG considers the issue NAD, and suggests
using Concepts instead.
</p>




<hr>
<h3><a name="112"></a>112. 
[tiny] Core issue 1586, Naming a destructor via decltype
</h3>
<p><b>Section:</b> 12.4 [class.dtor] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2012-11-14 <b>Last modified:</b> 2014-06-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>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1586">Core issue 1586</a>.
</p>
<p>Discussed in Rapperswil 2014. EWG found insufficient motivation for
this extension. Dennett pointed out that work-arounds are straightforward
and rarely needed. Closing as NAD.</p>




<hr>
<h3><a name="117"></a>117. 
N3955 Group Member Specifiers
</h3>
<p><b>Section:</b> 9.2 [class.mem] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Andrew Tomazos <b>Opened:</b> 2014-02-25 <b>Last modified:</b> 2014-06-30</p>
<p><b>View all other</b> <a href="ewg-index.html#class.mem">issues</a> in [class.mem].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3955.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3955.pdf</a>.
</p>
<p>
Discussed in Rapperswil 2014. A fairly long discussion, with lots of
concerns about the motivation.
</p>
<p>Straw polls:</p>
<p>Proposal as stated:</p>
<p> SF 1 - WF 1 - N 2 - WA 8 - SA 15</p> 
<p>Just the virtual parts, in a new paper:</p> 
<p>SF 4 - WF 3 - N 5 - WA 6 - SA 7</p>
<p>Virtual parts and some others:</p>
<p> SF 1 - WF 4 - N 1 - WA 9 - SA 10</p>
<p>We're done for this meeting. We don't actually encourage this proposal to come back, but there are people who'd like improvements for virtual functions. </p>
<p>Closing as NAD, no consensus to adopt.</p>

<p><b>Wording available:</b></p>
The paper contains the proposed wording.




<hr>
<h3><a name="124"></a>124. N4014 Uniform Copy Initialization
</h3>
<p><b>Section:</b> 8.5 [dcl.init] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2014-05-25 <b>Last modified:</b> 2014-06-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/2014/n4014.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4014.pdf</a>
</p>
<p>Discussed in Rapperswil 2014.</p>
<p>
Voutilainen pointed out that it seems important to be able to express 
whether explicit operations are ok or not. Vandevoorde said there's a 
difference between conversions and initializations. Dennett pointed out that 
this proposal clashes with the direction of N3912, and showed an example 
of the different directions; N3912 makes copy vs. direct initialization 
more significant with auto, whereas the Josuttis proposal makes it less 
significant. Josuttis in addition mentioned that it's unfortunate that we 
have no guidelines for when to use explicit and when not, and that makes 
things difficult for the library.
</p>
<p>Straw poll, accept the proposal:</p>
<p>SF: 1 F: 2 N: 6 A: 8 SA: 1</p>
<p>No consensus to adopt, closing as NAD.</p>




<hr>
<h3><a name="132"></a>132. Core Issue 1754 Declaration of partial specialization of static data member template
</h3>
<p><b>Section:</b> 14.5.5 [temp.class.spec] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2013-09-19 <b>Last modified:</b> 2014-06-30</p>
<p><b>View all other</b> <a href="ewg-index.html#temp.class.spec">issues</a> in [temp.class.spec].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1754">Core Issue 1754</a>
</p>
<p>
Discussed in Rapperswil 2014. EWG consider the issue esoteric, and failed
to see the motivation of the change. Closing as NAD for now, if this
should be reopened, stronger motivation should be provided.
</p>




<hr>
<h3><a name="133"></a>133. Core Issue 1798,  exception-specifications of template arguments
</h3>
<p><b>Section:</b> 15.4 [except.spec] <b>Status:</b> <a href="ewg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2013-10-16 <b>Last modified:</b> 2014-06-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>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1798">Core Issue 1798</a>
</p>
<p>
Discussed in Rapperswil 2014. EWG previously decided that exception
specifications should not become part of the type system. On this
issue, EWG thought that the exception specification in a template
parameter is effectively ignored, and that's fine. Closing as NAD 
for now, if this should be reopened, a paper should be written
to consider the impact of any suggested change.
</p>




</body>
</html>
