<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>C++ Standard Evolution Active 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">N4539</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2015-05-22</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 Active Issues List (Revision R12)</h1>
<p>Revised 2015-05-22 at 17:05:15 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-complete.html">Evolution Completed Issues List</a></li>
      <li><a href="ewg-closed.html">Evolution Closed Issues List</a></li>
  </ul>
  <p>The purpose of this document is to record the status of issues
  which have come before the Evolution Working Group (EWG) of the INCITS PL22.16
  and ISO WG21 C++ Standards Committee. Issues represent
  potential defects in the ISO/IEC IS 14882:2003(E) document, 
  and proposed extensions to it.
  </p>

  <p>This document contains only evolution issues which are actively being
  considered by the Evolution Working Group, i.e., issues which have a
  status of <a href="ewg-active.html#New">New</a>, <a href="ewg-active.html#Open">Open</a>, 
  <a href="ewg-active.html#Ready">Ready</a>, or <a href="ewg-active.html#Review">Review</a>. See
  <a href="ewg-complete.html">Evolution Completed Issues List</a> for issues considered completed (adopted) and 
  <a href="ewg-closed.html">Evolution Closed Issues List</a> for issues considered closed (rejected).</p>

  <p>The issues in these lists are not necessarily formal ISO Defect
  Reports (DR's). While some issues will eventually be elevated to
  official Defect Report status, other issues will be disposed of in
  other ways. See <a href="#Status">Issue Status</a>.</p>

  <p>This document includes <i>[bracketed italicized notes]</i> as a
  reminder to the EWG of current progress on issues. Such notes are
  strictly unofficial and should be read with caution as they may be
  incomplete or incorrect. Be aware that EWG support for a particular
  resolution can quickly change if new viewpoints or killer examples are
  presented in subsequent discussions.</p>

  <p>For the most current official version of this document see 
  <a href="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21/</a>.
  Requests for further information about this document should include
  the document number above, reference ISO/IEC 14882:2003(E), and be
  submitted to Information Technology Industry Council (ITI), 1250 Eye
  Street NW, Washington, DC 20005.</p>

  <p>Public information as to how to obtain a copy of the C++ Standard,
  join the standards committee, submit an issue, or comment on an issue
  can be found in the comp.std.c++ FAQ.
  </p>

<p><a name="submit_issue"></a><b>How to submit an issue</b></p>

<ol style="list-style-type:upper-alpha">
<li><a name="submit_issue_A"></a>
Mail your issue to the author of this list.
</li>
<li><a name="submit_issue_B"></a>
Specify a short descriptive title.  If you fail to do so, the subject line of your
mail will be used as the issue title.
</li>
<li><a name="submit_issue_C"></a>
If the "From" on your email is not the name you wish to appear as issue submitter,
then specify issue submitter.
</li>
<li><a name="submit_issue_D"></a>
Provide a brief discussion of the problem you wish to correct.  Refer to the latest
working draft or standard using [section.tag] and paragraph numbers where appropriate.
</li>
<li><a name="submit_issue_E"></a>
Provide proposed wording.  This should indicate exactly how you want the standard
to be changed.  General solution statements belong in the discussion area.  This
area contains very clear and specific directions on how to modify the current
draft.  If you are not sure how to word a solution, you may omit this part.
But your chances of a successful issue greatly increase if you attempt wording.
</li>
<li><a name="submit_issue_F"></a>
It is not necessary for you to use html markup.  However, if you want to, you can
&lt;ins&gt;<ins>insert text like this</ins>&lt;/ins&gt; and &lt;del&gt;<del>delete text like
this</del>&lt;/del&gt;.  The only strict requirement is to communicate clearly to
the list maintainer exactly how you want your issue to look.
</li>
<li><a name="submit_issue_G"></a>
It is not necessary for you to specify other html font/formatting
mark-up, but if you do the list maintainer will attempt to respect your
formatting wishes (as described by html markup, or other common idioms).
</li>
<li><a name="submit_issue_H"></a>
It is not necessary for you to specify open date or last modified date (the date
of your mail will be used).
</li>
<li><a name="submit_issue_I"></a>
It is not necessary for you to cross reference other issues, but you can if you
like.  You do not need to form the hyperlinks when you do, the list maintainer will
take care of that.
</li>
<li><a name="submit_issue_J"></a>
One issue per email is best.
</li>
<li><a name="submit_issue_K"></a>
Between the time you submit the issue, and the next mailing deadline
(date at the top of the Revision History), you <em>own</em> this issue. 
You control the content, the stuff that is right, the stuff that is
wrong, the format, the misspellings, etc.  You can even make the issue
disappear if you want.  Just let the list maintainer know how you want
it to look, and he will try his best to accommodate you.  After the
issue appears in an official mailing, you no longer enjoy exclusive
ownership of it.
</li>
</ol>


<h2>Revision History</h2>
<ul>
<li>R12: 2015-05-22 post-Lenexa mailing<ul>
<li><b>Summary:</b><ul>
<li>99 open issues, up by 1.</li>
<li>90 closed issues, up by 11.</li>
<li>189 issues total, up by 12.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 5 NAD issues: <a href="ewg-closed.html#178">178</a>, <a href="ewg-closed.html#179">179</a>, <a href="ewg-closed.html#183">183</a>, <a href="ewg-closed.html#184">184</a>, <a href="ewg-closed.html#186">186</a>.</li>
<li>Added the following 2 New issues: <a href="ewg-active.html#188">188</a>, <a href="ewg-active.html#189">189</a>.</li>
<li>Added the following 3 Open issues: <a href="ewg-active.html#181">181</a>, <a href="ewg-active.html#182">182</a>, <a href="ewg-active.html#187">187</a>.</li>
<li>Added the following 2 Ready issues: <a href="ewg-active.html#180">180</a>, <a href="ewg-active.html#185">185</a>.</li>
<li>Changed the following issue from New to Dup: <a href="ewg-closed.html#168">168</a>.</li>
<li>Changed the following 2 issues from Open to Dup: <a href="ewg-closed.html#137">137</a>, <a href="ewg-closed.html#159">159</a>.</li>
<li>Changed the following 3 issues from New to NAD: <a href="ewg-closed.html#167">167</a>, <a href="ewg-closed.html#171">171</a>, <a href="ewg-closed.html#176">176</a>.</li>
<li>Changed the following 4 issues from New to Open: <a href="ewg-active.html#169">169</a>, <a href="ewg-active.html#172">172</a>, <a href="ewg-active.html#173">173</a>, <a href="ewg-active.html#174">174</a>.</li>
<li>Changed the following issue from New to Ready: <a href="ewg-active.html#170">170</a>.</li>
<li>Changed the following issue from Open to Ready: <a href="ewg-active.html#142">142</a>.</li>
</ul></li>
</ul>
</li>
<li>R11: 
2015-04-10 pre-Lenexa mailing
<ul><li><b>Summary:</b><ul>
<li>98 open issues, up by 13.</li>
<li>79 closed issues, down by 1.</li>
<li>177 issues total, up by 12.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 12 New issues: <a href="ewg-active.html#166">166</a>, <a href="ewg-active.html#167">167</a>, <a href="ewg-active.html#168">168</a>, <a href="ewg-active.html#169">169</a>, <a href="ewg-active.html#170">170</a>, <a href="ewg-active.html#171">171</a>, <a href="ewg-active.html#172">172</a>, <a href="ewg-active.html#173">173</a>, <a href="ewg-active.html#174">174</a>, <a href="ewg-active.html#175">175</a>, <a href="ewg-active.html#176">176</a>, <a href="ewg-active.html#177">177</a>.</li>
<li>Changed the following 14 issues from WP to C++14: <a href="ewg-complete.html#1">1</a>, <a href="ewg-complete.html#3">3</a>, <a href="ewg-complete.html#6">6</a>, <a href="ewg-complete.html#7">7</a>, <a href="ewg-complete.html#16">16</a>, <a href="ewg-complete.html#18">18</a>, <a href="ewg-complete.html#20">20</a>, <a href="ewg-complete.html#21">21</a>, <a href="ewg-complete.html#25">25</a>, <a href="ewg-complete.html#27">27</a>, <a href="ewg-complete.html#46">46</a>, <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 issue from WP to Open: <a href="ewg-active.html#13">13</a>.</li>
</ul></li>
</ul>
</li>
<li>R10: 
2014-10-29 post-Urbana mailing
<ul><li><b>Summary:</b><ul>
<li>85 open issues, up by 6.</li>
<li>80 closed issues, up by 20.</li>
<li>165 issues total, up by 26.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 6 NAD issues: <a href="ewg-closed.html#140">140</a>, <a href="ewg-closed.html#144">144</a>, <a href="ewg-closed.html#145">145</a>, <a href="ewg-closed.html#150">150</a>, <a href="ewg-closed.html#156">156</a>, <a href="ewg-closed.html#157">157</a>.</li>
<li>Added the following New issue: <a href="ewg-active.html#146">146</a>.</li>
<li>Added the following 13 Open issues: <a href="ewg-active.html#141">141</a>, <a href="ewg-active.html#142">142</a>, <a href="ewg-active.html#143">143</a>, <a href="ewg-active.html#148">148</a>, <a href="ewg-active.html#149">149</a>, <a href="ewg-active.html#151">151</a>, <a href="ewg-active.html#152">152</a>, <a href="ewg-active.html#153">153</a>, <a href="ewg-active.html#158">158</a>, <a href="ewg-active.html#159">159</a>, <a href="ewg-active.html#160">160</a>, <a href="ewg-active.html#162">162</a>, <a href="ewg-active.html#163">163</a>.</li>
<li>Added the following 2 Ready issues: <a href="ewg-active.html#164">164</a>, <a href="ewg-active.html#165">165</a>.</li>
<li>Added the following 4 WP issues: <a href="ewg-complete.html#147">147</a>, <a href="ewg-complete.html#154">154</a>, <a href="ewg-complete.html#155">155</a>, <a href="ewg-complete.html#161">161</a>.</li>
<li>Changed the following issue from New to NAD: <a href="ewg-closed.html#138">138</a>.</li>
<li>Changed the following issue from Open to NAD: <a href="ewg-closed.html#114">114</a>.</li>
<li>Changed the following 2 issues from New to Open: <a href="ewg-active.html#129">129</a>, <a href="ewg-active.html#137">137</a>.</li>
<li>Changed the following issue from Ready to Open: <a href="ewg-active.html#81">81</a>.</li>
<li>Changed the following issue from New to Ready: <a href="ewg-active.html#139">139</a>.</li>
<li>Changed the following issue from Open to Ready: <a href="ewg-active.html#72">72</a>.</li>
<li>Changed the following 4 issues from Open to WP: <a href="ewg-complete.html#63">63</a>, <a href="ewg-complete.html#82">82</a>, <a href="ewg-complete.html#113">113</a>, <a href="ewg-complete.html#126">126</a>.</li>
<li>Changed the following 4 issues from Ready to WP: <a href="ewg-complete.html#80">80</a>, <a href="ewg-complete.html#119">119</a>, <a href="ewg-complete.html#121">121</a>, <a href="ewg-complete.html#131">131</a>.</li>
</ul></li>
</ul>
</li>
<li>R09: 
2014-10-09 pre-Urbana mailing
<ul><li><b>Summary:</b><ul>
<li>79 open issues, up by 5.</li>
<li>60 closed issues, up by 0.</li>
<li>139 issues total, up by 5.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 4 New issues: <a href="ewg-active.html#135">135</a>, <a href="ewg-active.html#137">137</a>, <a href="ewg-active.html#138">138</a>, <a href="ewg-active.html#139">139</a>.</li>
<li>Added the following Open issue: <a href="ewg-active.html#136">136</a>.</li>
</ul></li>
</ul>
</li>
<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><a name="Status"></a>Issue Status</h2>

  <p><b><a name="New">New</a></b> - The issue has not yet been
  reviewed by the EWG. Any <b>Wording available</b> is purely a
  suggestion from the issue submitter, and should not be construed as
  the view of EWG.</p>

  <p><b><a name="Open">Open</a></b> - The EWG has discussed the issue
  but is not yet ready to move the issue forward. There are several
  possible reasons for open status:</p>
     <ul>
        <li>Consensus may have not yet have been reached as to how to deal
            with the issue.</li>
        <li>Informal consensus may have been reached, but the EWG awaits
            exact resolution for review.</li>
        <li>The EWG wishes to consult additional technical experts before
            proceeding.</li>
        <li>The issue may require further study.</li>
     </ul>

  <p>A <b>Wording available</b> for an open issue is still not be
  construed as the view of EWG. Comments on the current state of
  discussions are often given at the end of open issues in an italic
  font. Such comments are for information only and should not be given
  undue importance.</p>

  <p><b><a name="Deferred">Deferred</a></b> - The EWG has discussed the issue,
  is not yet ready to move the issue forward, but neither does it deem the
  issue significant enough to delay publishing a standard or Technical Report.
  A typical deferred issue would be seeking to clarify wording that might be
  technically correct, but easily mis-read.</p>

  <p>A <b>Wording available</b> for a deferred issue is still not be
  construed as the view of EWG. Comments on the current state of
  discussions are often given at the end of open issues in an italic
  font. Such comments are for information only and should not be given
  undue importance.</p>

  <p><b><a name="Dup">Dup</a></b> - The EWG has reached consensus that
  the issue is a duplicate of another issue, and will not be further
  dealt with. A <b>Rationale</b> identifies the duplicated issue's
  issue number.  </p>

  <p><b><a name="NAD">NAD</a></b> - The EWG has reached consensus that
  the issue is not a defect in the Standard nor is it an extension
  the EWG deems acceptable.</p>

  <p><b><a name="Review">Review</a></b> - Exact resolution is now 
  available for review on an issue for which the EWG previously reached 
  informal consensus.</p>

  <p><b><a name="Ready">Ready</a></b> - The EWG has reached consensus
  that the issue is an extension that can go forward to Core, Library,
  or a Study Group for further processing.</p>

  <p><b><a name="Resolved">Resolved</a></b> - The EWG has reached consensus
  that the issue is a defect in or an acceptable extension to the Standard, 
  but the resolution adopted to
  resolve the issue came via some other mechanism than this issue in the
  list - typically by applying a formal paper, occasionally as a side effect
  of consolidating several interacting issue resolutions into a single issue.</p>

  <p><b><a name="DR">DR</a></b> - (Defect Report) - It's not expected
  that the EWG would handle Defect Reports.</p>

  <p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed
  resolution has not been accepted as a Technical Corrigendum, but
  the full WG21/PL22.16 committee has voted to apply the issue's resolution
  to the working paper.</p>

  <p><b>Tentatively</b> - This is a <i>status qualifier</i>.  The issue has
  been reviewed online, or at an unofficial meeting, but not in an official meeting, and some support has been formed
  for the qualified status.  Tentatively qualified issues may be moved to the unqualified status
  and forwarded to full committee (if Ready) within the same meeting.  Unlike Ready issues, Tentatively Ready issues
  will be reviewed in subcommittee prior to forwarding to full committee.  When a status is
  qualified with Tentatively, the issue is still considered active.</p>

  <p><b>Pending</b> - This is a <i>status qualifier</i>.  When prepended to
  a status this indicates the issue has been
  processed by the committee, and a decision has been made to move the issue to
  the associated unqualified status.  However for logistical reasons the indicated
  outcome of the issue has not yet appeared in the latest working paper.</p>

  <p>Issues are always given the status of <a href="ewg-active.html#New">New</a> when
  they first appear on the issues list. They may progress to
  <a href="ewg-active.html#Open">Open</a> or <a href="ewg-active.html#Review">Review</a> while the EWG
  is actively working on them. When the EWG has reached consensus on
  the disposition of an issue, the status will then change to
  <a href="ewg-active.html#Dup">Dup</a>, <a href="ewg-active.html#NAD">NAD</a>, or
  <a href="ewg-active.html#Ready">Ready</a> as appropriate.  Once the full J16 committee votes to
  forward Ready issues to the Project Editor, they are given the
  status of Defect Report ( <a href="ewg-active.html#DR">DR</a>). These in turn may
  become the basis for Technical Corrigenda (<a href="ewg-active.html#TC1">TC1</a>),
  or are closed without action other than a Record of Response
  (<a href="ewg-active.html#Resolved">Resolved</a> ). The intent of this EWG process is that
  issues which are defects in or accepted extensions to the Standard move to the
  formal ISO DR status.
  </p>

<h2>Active Issues</h2>
<hr>
<h3><a name="2"></a>2. N3387 Overload resolution tiebreakers for integer types</h3>
<p><b>Section:</b> 4.13 [conv.rank] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2012-09-12 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3387.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3387.html</a>
</p>
<p>
Deemed post-C++14 material in Chicago 2013.
</p>
<p>
Discussed in Rapperswil 2014. EWG stated that in order to move forward
with such a proposal, it would need to provide data about the 
compatibility/breakage issues, if any.
</p>


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




<hr>
<h3><a name="4"></a>4. N3396 Dynamic memory allocation for over-aligned data</h3>
<p><b>Section:</b> 18.6 [support.dynamic] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Clark Nelson <b>Opened:</b> 2012-08-30 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3396.htm">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3396.htm</a>
</p>
<p>Reviewed by EWG in Portland, author encouraged to revise.</p>
<p>Deemed post-C++14 material in Chicago 2013. Has an associated
NB comment, FI 16, although the comment is rejected for C++14.</p>


<p><b>Wording available:</b></p>
<p>The paper contains the proposed wording that is to be revised.</p>




<hr>
<h3><a name="5"></a>5. 
N3400 A proposal for eliminating the underscore madness that library writers have to suffer</h3>
<p><b>Section:</b> 16.3 [cpp.replace] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan de Boyne Pollard <b>Opened:</b> 2012-09-21 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3400.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3400.html</a>


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




<hr>
<h3><a name="9"></a>9. 
N4469 Template Argument Type Deduction, N3601 Implicit template parameters, N3405 Template Tidbits
</h3>
<p><b>Section:</b> 14 [temp] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Mike Spertus <b>Opened:</b> 2012-09-22 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#temp">active issues</a> in [temp].</p>
<p><b>View all other</b> <a href="ewg-index.html#temp">issues</a> in [temp].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4469.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4469.html</a>
</p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3405.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3405.html</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3601.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3601.html</a>
</p>
<p>EWG review started, not completed yet. Likely needs a follow-up paper.</p>
<p>
Bristol 2013: Encouraged to pursue further. Template parameter deduction
for constructors has been split into EWG Issue <a href="ewg-active.html#60">60</a>.
</p>
<p>
Discussed in Lenexa. The author was encouraged to strive for a syntax
that uses auto. The author will revise and come back.
</p>





<hr>
<h3><a name="10"></a>10. 
N3407 Proposal to Add Decimal Floating Point Support to C++
</h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Dietmar Khl <b>Opened:</b> 2012-09-14 <b>Last modified:</b> 2015-05-22</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#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3407.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3407.html</a>
<p>Handled by the Numerics Study Group (SG6).</p>





<hr>
<h3><a name="11"></a>11. 
N3409 Strict Fork-Join Parallelism
</h3>
<p><b>Section:</b> 1.10 [intro.multithread] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2012-09-24 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#intro.multithread">active issues</a> in [intro.multithread].</p>
<p><b>View all other</b> <a href="ewg-index.html#intro.multithread">issues</a> in [intro.multithread].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3409.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3409.pdf</a>
<p>Handled by the Concurrency Study Group (SG1)</p>





<hr>
<h3><a name="13"></a>13. 
N3639, N3497, N3467, N3412 Runtime-sized arrays with automatic storage duration
</h3>
<p><b>Section:</b> 3.9 [basic.types] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2012-09-19 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#basic.types">active issues</a> in [basic.types].</p>
<p><b>View all other</b> <a href="ewg-index.html#basic.types">issues</a> in [basic.types].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3412.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3412.html</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3467.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3467.html</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3497.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3497.html</a>
</p>
<p>
Reviewed by EWG in Portland 2012, proceeding to CWG. The library part is <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2648.html">N2648 C++ Dynamic Arrays</a>, and that part is proceeding to LWG.
</p>
<p>
<p>Accepted into the Working Draft in Bristol 2013, as N3639.</p>
</p>
<p>
Moved in Chicago 2013 to be designated for an Array Extension TS, which hasn't
materialized yet.
</p>


<p><b>Wording available:</b></p>
The paper contains the proposed wording, as does the Library counterpart.




<hr>
<h3><a name="14"></a>14. 
N3413 Allowing arbitrary literal types for non-type template parameters
</h3>
<p><b>Section:</b> 14.1 [temp.param] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2012-09-19 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#temp.param">active issues</a> in [temp.param].</p>
<p><b>View all other</b> <a href="ewg-index.html#temp.param">issues</a> in [temp.param].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3413.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3413.html</a>
</p>
<p>
Bristol 2013: Maurer expressed surprise at the paper being under discussion, and explained that he doesn't think it can be made to work under current linker environments, and further explained that user-defined equality operators cause confusion and surprises. Maurer said that he'd want Stroustrup to clarify which parts of the paper he would want.
</p>

<p>
Two-way Straw polls:
</p>
<p>
Rules for agument expressions:
</p>
<p>
F: 5 A: 0
</p>
<p>
Structs without operator==
</p>
<p>
F: 0 A: 0
</p>
<p>
Structs with operator==
</p>
<p>
F: 1 A: 3
</p>
<p>
The issue is not pushed at this time. 
</p>
<p>
Deemed post-C++14 material in Chicago 2013, Stroustrup expressed
interest in writing papers about the subject targeting C++17.
</p>


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




<hr>
<h3><a name="15"></a>15. 
N3416 Packaging Parameter Packs
</h3>
<p><b>Section:</b> 14.1 [temp.param] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Mike Spertus <b>Opened:</b> 2012-09-21 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#temp.param">active issues</a> in [temp.param].</p>
<p><b>View all other</b> <a href="ewg-index.html#temp.param">issues</a> in [temp.param].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3416.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3416.html</a>
</p>

<p>
There is a closed (extension status) Core issue for this, see <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1643">Core issue 1643</a>.
</p>





<hr>
<h3><a name="17"></a>17. 
N3419 Vector loops and Parallel Loops
</h3>
<p><b>Section:</b> 1.10 [intro.multithread] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Robert Geva <b>Opened:</b> 2012-09-21 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#intro.multithread">active issues</a> in [intro.multithread].</p>
<p><b>View all other</b> <a href="ewg-index.html#intro.multithread">issues</a> in [intro.multithread].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3419.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3419.pdf</a>
<p>
Handled by the Concurrency Study Group (SG1).
</p>





<hr>
<h3><a name="19"></a>19. 
N3429 A C++ Library Solution To Parallelism
</h3>
<p><b>Section:</b> 30 [thread] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Artur Laksberg <b>Opened:</b> 2012-09-21 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3429.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3429.pdf</a>
<p>
Handled by the Concurrency Study Group (SG1).
</p>


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




<hr>
<h3><a name="22"></a>22. 
N4030, 3745, N3694 Feature-testing recommendations for C++, N3435 Standardized feature-test macros
</h3>
<p><b>Section:</b> 18.1 [support.general] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Clark Nelson <b>Opened:</b> 2012-09-18 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#support.general">active issues</a> in [support.general].</p>
<p><b>View all other</b> <a href="ewg-index.html#support.general">issues</a> in [support.general].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4030.htm">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4030.htm</a>
</p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3745.htm">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3745.htm</a>
</p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3694.htm">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3694.htm</a>
</p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3435.htm">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3435.htm</a>
</p>
<p>
Reviewed by EWG in Portland 2012, proceeding in SG10, Feature Test.
</p>
<p>
Handled by SG10 to the first desired outcome in Chicago2013, no
need for further EWG follow-up.
</p>
<p>
Discussed again in Rapperswil 2014.</p>
<p>Straw poll, has_cpp_attribute as a function-style macro:</p>
<p>SF 7, WF 9, N 4, WA 0, SA 0.</p>
<p>EWG's guidance was for the function-style macro.</p>





<hr>
<h3><a name="23"></a>23. 
N3437 Type Name Strings For C++
</h3>
<p><b>Section:</b> 20.9 [meta] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Axel Naumann <b>Opened:</b> 2012-09-24 <b>Last modified:</b> 2015-05-22</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3437.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3437.pdf</a>
<p>
Not reviewed by EWG yet, to be handled by the Reflection Study Group (SG7).
</p>
<p>In Chicago 2013, EWG decided to let SG7 handle this.</p>





<hr>
<h3><a name="24"></a>24. 
N3441 Call Stack Utilities and std::exception Extension Proposal
</h3>
<p><b>Section:</b> 18.8 [support.exception] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Aurelian Melinte <b>Opened:</b> 2012-09-20 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3441.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3441.html</a>





<hr>
<h3><a name="26"></a>26. 
N3538, N3445 Pass by Const Reference or Value
</h3>
<p><b>Section:</b> 8.3.5 [dcl.fct] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2012-09-23 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#dcl.fct">active issues</a> in [dcl.fct].</p>
<p><b>View all other</b> <a href="ewg-index.html#dcl.fct">issues</a> in [dcl.fct].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3445.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3445.html</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3538.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3538.html</a>
</p>
<p>
Deemed post-C++14 material in Chicago 2013.
</p>





<hr>
<h3><a name="28"></a>28. 
N3449 Open and Efficient Type Switch for C++
</h3>
<p><b>Section:</b> 5.2.7 [expr.dynamic.cast] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Bjarne Stroustrup <b>Opened:</b> 2012-09-23 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3449.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3449.pdf</a>
</p>
<p>
Deemed post-C++14 material in Chicago 2013.
</p>





<hr>
<h3><a name="29"></a>29. 
N4461 Static if resurrected, N3329 Proposal: static if declaration
</h3>
<p><b>Section:</b> 20.9 [meta] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Herb Sutter, Ville Voutilainen <b>Opened:</b> 2012-01-10 <b>Last modified:</b> 2015-05-22</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4461.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4461.html</a>
</p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf</a>
</p>
<p>
Reviewed by EWG in Portland 2012, deemed to be handled by the Concepts Study Group (SG8).
</p>
<p>
Deemed post-C++14 material in Chicago 2013. SG8 isn't including it in their
scope for the near future. Voutilainen is planning to write a simplified
proposal for C++17.
</p>
<p>
Discussed in Lenexa. EWG encouraged the author to come back in Kona
with a more detailed proposal.
</p>





<hr>
<h3><a name="30"></a>30. 
N4235 Selecting from Parameter Packs, [tiny] Efficient/Flexible Access to Argument Packs
</h3>
<p><b>Section:</b> 14.5.3 [temp.variadic] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2012-10-16 <b>Last modified:</b> 2015-05-22</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4235.htm">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4235.htm</a>
</p>
<p>
There are lots of very basic manipulations that are either really hard
or impossible to do with argument packs unless you use something that
causes a big recursive template instantiation, which is expensive at
compile-time and can cause bad error messages.  I want to be able to
index argument packs with integral constant expressions, "take" or
"drop" the first N elements of the pack, etc.
</p>
<p>
In Bristol 2013: N3493 may solve parts of the problem. The submitter is encouraged to write a paper, and practical examples are desirable. 
</p>
<p>N3761 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3761.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3761.html</a> seems related.
</p>
<p>
Discussed in Rapperswil 2014. Vandevoorde expressed desire to write a paper.
</p>
<p>The work done by George Makrydakis at <a href="https://github.com/irrequietus/atpp">https://github.com/irrequietus/atpp</a> is related.</p>
<p>
Discussed in Urbana. The author is encouraged to revise.
</p>





<hr>
<h3><a name="34"></a>34. 
[tiny] Defining hash functions for composite user-defined types is annoying
</h3>
<p><b>Section:</b> 17.6.3.4 [hash.requirements] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2012-10-23 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
We have a hash function for built-in types and for some standard library types, but we don't have automatically generated hash&lt;&gt; specializations for user-defined types like
<pre>
  struct my_type {
    int x;
    std::string y;
    vector&lt;int&gt; z;
  };
</pre>
Defining a good and efficient hash function for composite types takes a fair amount of work. One consequence is that there are a lot of user-defined types with bad hash functions floating around.

One possibility is automatically generating hash&lt;&gt; specializations, but that's tricky. A simpler possibility is providing tools that make it easier for users to do the right thing.
</p>
<p>
Bristol 2013: Austern explained that he didn't envision syntax to automate the generation of hash operations but thought that this could potentially be solved by a library. Stroustrup and Austern thought that reflection would be another way to solve this. Van Winkel thought that for the generation of such things, it's perhaps desirable that they aren't generated by default but can be generated on demand when a user-defined type requests such generation. The guidance of the EWG is to propose a solution that handles equality operators and other such things in a more general manner. 
</p>
<p>
EWG expressed long-term interest in this idea in Chicago 2013 for post-C++14. 
Papers welcome.
</p>





<hr>
<h3><a name="35"></a>35. 
[tiny] Some concise way to generate a unique, unused variable name
</h3>
<p><b>Section:</b> 3.4 [basic.lookup] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2012-10-24 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Sometimes we want to define a variable that's unused except for its
constructor and destructor. lock_guard&lt;mutex&gt; and ScopeGuard are
decent examples of this. In C++11, we have to manually name the
variable something unique. Sometimes we use _some_name_##__LINE__
(suitably wrapped so the concatenation happens after expanding
__LINE__) to try to generate unique names automatically, and gcc/clang
have an extension _some_name_##__COUNTER__
<p>
<a href="http://gcc.gnu.org/onlinedocs/gcc-4.7.2/cpp/Common-Predefined-Macros.html">http://gcc.gnu.org/onlinedocs/gcc-4.7.2/cpp/Common-Predefined-Macros.html</a>
</p>
to allow multiple such variables on the same line. These are pretty
verbose and not convenient for casual use.

Haskell allows _ (underscore) to stand in for a variable that's not
going to be used. Googlemock defines testing::_ to mean "don't care"
as an argument, which is similar but not identical.
</p>
<p>
Bristol 2013: Stroustrup wondered how unique the name needs to be, and wondered whether parallel builds would have problems ensuring the uniqueness. Naumann pointed out that having an unnamed variable is useful also for cases where you don't want the variable's address to be taken etc. Stroustrup and Van Winkel said this is not tiny, and a proper paper is necessary for this issue. 
</p>
<p>
Chicago 2013: Deemed not as C++14 material, Yasskin or someone else
invited to write a paper, straw polls in favor of the feature. Things
to consider in the paper: Consider double underscore "__". Can 
it be used only in local scope? For class members? For globals? 
</p>
<p>
Discussed in Rapperswil 2014. Still encouraging a paper, Dennett to
contact Yasskin about it.</p>





<hr>
<h3><a name="41"></a>41. 
[tiny] In-class explicit specializations forbidden but not partial specializations
</h3>
<p><b>Section:</b> 14.7.3 [temp.expl.spec] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Faisal Vali <b>Opened:</b> 2012-10-27 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#temp.expl.spec">active issues</a> in [temp.expl.spec].</p>
<p><b>View all other</b> <a href="ewg-index.html#temp.expl.spec">issues</a> in [temp.expl.spec].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I had submitted a DR (727) about this in October 2008 - and it was
classified as an extension - I wonder if Spertus' DR (1077) that was
also classified as an extension should be considered along with this
one.


14.7.3 [temp.expl.spec] paragraph 2 requires that explicit
specializations of member templates be declared in namespace scope,
not in the class definition. This restriction does not apply to
partial specializations of member templates; that is,
<pre>
    struct A {
      template&lt;class T&gt; struct B;
      template &lt;class T&gt; struct B&lt;T*&gt; { }; // well-formed
      template &lt;&gt; struct B&lt;int*&gt; { }; // ill-formed
    };
</pre>
There does not seem to be a good reason for this inconsistency.
</p>
<p>
Bristol 2013: Defer to Core, with the guidance to reopen the DR mentioned and remove the restriction. 
</p>
<p>
Before this can go over to Core, it needs wording. It's likely that it
needs a paper. Vali should create either the wording or the paper.
</p>





<hr>
<h3><a name="43"></a>43. 
[tiny] simultaneous iteration with new-style for syntax
</h3>
<p><b>Section:</b> 6.5.4 [stmt.ranged] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2013-01-12 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The new-style 'for' syntax allows us to dispense with administrative
iterator declarations when iterating over a single seuqence.

The burden and noise remain, however, when iterating over two or more
sequences simultaenously.  We should extend the syntax to allow that.
E.g. one should be able to write:
<pre>
    for (auto&amp; x : v; auto&amp; y : w)
       a = combine(v, w, a);
</pre>

instead of the noisier
<pre>
    auto p1 = v.begin();
    auto q1 = v.end();
    auto p2 = w.begin();
    auto q2 = w.end();
    while (p1 &lt; q1 and p2 &lt; q2) {
       a = combine(*p1, *p2, a);
       ++p1;
       ++p2;
    }
</pre>
</p>
<p>
Bristol 2013: Submitter is encouraged to write a paper. 
</p>
<p>EWG expressed reiterated interest in Chicago 2013 for this idea, deeming
it post-C++14 material.</p>
<p>Discussed in Rapperswil 2014. The author is still encouraged to submit
a paper. Vandevoorde to contact Dos Reis and Lavavej about it.</p>




<hr>
<h3><a name="48"></a>48. 
N3867, N3730 Specializations and namespaces (was "Specializing templates in different namespaces" before the paper)
</h3>
<p><b>Section:</b> 14.7.3 [temp.expl.spec] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Mike Spertus <b>Opened:</b> 2013-03-06 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#temp.expl.spec">active issues</a> in [temp.expl.spec].</p>
<p><b>View all other</b> <a href="ewg-index.html#temp.expl.spec">issues</a> in [temp.expl.spec].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3867.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3867.html</a>
</p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3730.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3730.html</a>
</p>
<p>
There is a closed (extension status) Core issue for this, see <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1077">Core issue 1077</a>.
</p>
<p>
This is a proposal to allow specializing templates from within a different namespace. The motivation is that when we declare a new class, it is natural to want to provide associated template specializations. For example, it is really painful that whenever I declare a class, I need to leave my namespace and enter namespace std just to specialize std::less as shown below

<pre>
  namespace A {
    namespace B {
      class C {...};
    }
  }

  namespace std {
    template &lt;&gt;
    struct less&lt;C&gt; : binary_function &lt;C, C, bool&gt; {
       bool operator() (const C &amp; x, const C &amp; y) const {...}
   };
  }

  namespace A {
    namespace B {
      ... // Continue working in A::B
    }
  }
</pre>
 

Instead, I should be able to specialize std::less without having to break out of my namespace:

<pre> 
  namespace A {
    namespace B {
      class C {...};
      template &lt;&gt;
      struct ::std::less&lt;C&gt; : binary_function &lt;C, C, bool&gt; {
        bool operator() (const C &amp; x, const C &amp; y) const {...}
      };
    ... // Continue working in A::B
    }
  }
</pre>
</p>
<p>
Bristol 2013:  Stroustrup expressed concern about unqualified name lookup in the specializations, and Voutilainen thought that that just might be the reason why the current rules don't allow it. Gottschling voiced concern about the implementation impact, and Voutilainen suggested asking for a quick review of the overall idea from Spicer. Austern thought that this could be palatable if it's expressed as a set of rewrite rules. Spertus asked about an alternative which is to be able to open another namespace without having to exit the current namespace. This alternative didn't gain success.

Spertus to write a paper. 
</p>
<p>
In Chicago 2013, EWG guidance was to work based on the current proposal N3730 without the facility of specializing a namespace-scoped template from inside a class. 
</p>
<p>Discussed in Rapperswil 2014.</p>
<p>Gregor and Vandevoorde expressed concern about changing name lookup, and thought that the problem space needs the help of Core experts. Dos Reis expressed concern about expanding the need to do more tentative parsing to resolve ambiguities. Stroustrup requested further study in order to explore the possibilities
to find a solution that doesn't cause issues with lookup, and Spertus
agreed that further exploration seems wise.</p>
<p>EWG encouraged working further on the problem, looking at alternative
solutions.</p>




<hr>
<h3><a name="49"></a>49. 
N3463 Portable Program Source Files
</h3>
<p><b>Section:</b> 2.2 [lex.phases] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2012-11-02 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all other</b> <a href="ewg-index.html#lex.phases">issues</a> in [lex.phases].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3463.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3463.html</a>




<hr>
<h3><a name="50"></a>50. 
N3466 More Perfect Forwarding
</h3>
<p><b>Section:</b> 18.1 [support.general] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Mike Spertus <b>Opened:</b> 2012-11-03 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#support.general">active issues</a> in [support.general].</p>
<p><b>View all other</b> <a href="ewg-index.html#support.general">issues</a> in [support.general].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3466.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3466.html</a>




<hr>
<h3><a name="51"></a>51. 
N3490 ADL Control for C++
</h3>
<p><b>Section:</b> 3.4.2 [basic.lookup.argdep] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2012-10-31 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#basic.lookup.argdep">active issues</a> in [basic.lookup.argdep].</p>
<p><b>View all other</b> <a href="ewg-index.html#basic.lookup.argdep">issues</a> in [basic.lookup.argdep].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3490.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3490.html</a>




<hr>
<h3><a name="52"></a>52. 
N3741, N3515 Toward Opaque Typedefs for C++1Y
</h3>
<p><b>Section:</b> 7.1.3 [dcl.typedef] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2013-01-11 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3741.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3741.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3515.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3515.pdf</a>
</p>
<p>
Reviewed in Chicago 2013, author encouraged to pursue the idea further
with revised papers.
</p>




<hr>
<h3><a name="56"></a>56. 
N3583 	Exploring constexpr at Runtime
</h3>
<p><b>Section:</b> 5.19 [expr.const] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Scott Schurr <b>Opened:</b> 2013-03-13 <b>Last modified:</b> 2015-05-22</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3583.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3583.pdf</a>
</p>
<p>
Bristol 2013: We won't move forward with this at this time, but we might want to see a followup paper focusing on the trait. 
</p>
</p>




<hr>
<h3><a name="57"></a>57. 
N3587 For Loop Exit Strategies
</h3>
<p><b>Section:</b> 6.5 [stmt.iter] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Alan Talbot <b>Opened:</b> 2013-03-17 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#stmt.iter">active issues</a> in [stmt.iter].</p>
<p><b>View all other</b> <a href="ewg-index.html#stmt.iter">issues</a> in [stmt.iter].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3587.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3587.pdf</a>
</p>
<p>
Bristol 2013: Van Winkel pointed out that this allows jumping out of nested 
loops. Naumann expressed doubt over whether the problem is so big that we 
need such a big extension to solve it. Van Winkel and Spertus thought that 
this would likely be a popular feature. Voutilainen thought that it would be 
beneficial to revisit a lambda solution. Talbot expressed doubt whether that's 
a suitable solution, syntax-wise and performance-wise. Austern thought that 
this seems to be in flux, and thought we aren't necessarily ready to choose 
between the various options. Gottschling thought Vandevoorde's option is 
nice, since it's still structured. Spertus said he likes the idea of having 
a control structure be an expression. Austern recommended looking closely 
at Clause 5 in the follow-up paper. 
</p>
<p>
The author is encouraged to write a follow-up paper.
</p>
</p>




<hr>
<h3><a name="58"></a>58. 
N3595 Simplifying Argument-Dependent Lookup Rules
</h3>
<p><b>Section:</b> 3.4.2 [basic.lookup.argdep] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Peter Gottschling <b>Opened:</b> 2013-03-15 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#basic.lookup.argdep">active issues</a> in [basic.lookup.argdep].</p>
<p><b>View all other</b> <a href="ewg-index.html#basic.lookup.argdep">issues</a> in [basic.lookup.argdep].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3595.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3595.pdf</a>
</p>
<p>
Bristol 2013: Looked at briefly, the EWG thinks this should be considered
alongside other ADL proposals.
</p>
</p>




<hr>
<h3><a name="59"></a>59. 
N3596 Code Reuse in Class Template Specialization 	
</h3>
<p><b>Section:</b> 3.4.2 [basic.lookup.argdep] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Peter Gottschling <b>Opened:</b> 2013-03-15 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#basic.lookup.argdep">active issues</a> in [basic.lookup.argdep].</p>
<p><b>View all other</b> <a href="ewg-index.html#basic.lookup.argdep">issues</a> in [basic.lookup.argdep].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3596.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3596.pdf</a>
</p>
</p>




<hr>
<h3><a name="60"></a>60. 
N4471 Template parameter deduction for constructors (Rev 2), N3602 Template parameter deduction for constructors
</h3>
<p><b>Section:</b> 14.8.2 [temp.deduct] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Mike Spertus <b>Opened:</b> 2013-03-14 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#temp.deduct">active issues</a> in [temp.deduct].</p>
<p><b>View all other</b> <a href="ewg-index.html#temp.deduct">issues</a> in [temp.deduct].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
This issue is split from EWG Issue <a href="ewg-active.html#9">9</a>.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4471.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4471.html</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3602.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3602.html</a>
</p>
<p>
Bristol 2013: Reviewed and accepted by EWG, needs redrafting before
ready for core.
</p>
<p>
Core pointed out problems in Bristol. Gregor summarized in Chicago 2013 that
The primary template might not be the right place to pick constructors from. (Partial) specializations might have completely different constructors. 
Stroustrup thought that there's only two ways: all specializations have to be 
in scope, and you look at all of those, or look only at the primary and give 
an error if that doesn't work.  Spertus is encouraged to write a follow-up 
paper.
</p>
<p>
Discussed in Lenexa. EWG gave guidance on the "typed constructors" technique,
and encouraged the author to revise and come back.
</p>




<hr>
<h3><a name="65"></a>65. 
N3617 Lifting overload sets into function objects
</h3>
<p><b>Section:</b> 20.8.2 [func.require] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Philipp Juschka <b>Opened:</b> 2013-03-14 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3617.htm">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3617.htm</a>
</p>




<hr>
<h3><a name="66"></a>66. 
N3599 Literal operator templates for strings
</h3>
<p><b>Section:</b> 2.14.8 [lex.ext] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2013-03-13 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3599.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3599.html</a>
</p>
<p>
Bristol 2013: 
<p>
Straw Poll: Adopt N3599, send to core: SF:2 WF:1 N:6 WA:4 SA:1
</p>
<p>
No consensus for moving forward as is.
</p>
<p>
Straw Poll: Revise with additional machinery for compile time string processing
</p>
<p>
SF: 10 WF: 2 N: 0 WA: 0 SA: 0
</p>
<p>
Encouragement for Smith and Vandevoorde to revise. 
</p>
</p>




<hr>
<h3><a name="71"></a>71. 
N3627 Relaxed switch statement
</h3>
<p><b>Section:</b> 6.4.2 [stmt.switch] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Zhihao Yuan <b>Opened:</b> 2013-02-02 <b>Last modified:</b> 2015-05-22</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3627.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3627.html</a>
</p>
<p>
Reviewed in Chicago 2013, author is encouraged to pursue this further.
</p>




<hr>
<h3><a name="72"></a>72. 
N4150 Alias-Set Attributes: Toward restrict-like aliasing semantics for C++, N3988 Towards restrict-like aliasing semantics for C++ N3635 Towards restrict-like semantics for C++
</h3>
<p><b>Section:</b> 8.3.1 [dcl.ptr] <b>Status:</b> <a href="ewg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Hal Finker, Hubert Tong, M. Wong, R. Silvera, R. Mak, C. Cambly, et al. <b>Opened:</b> 2013-04-29 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4150.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4150.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3988.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3988.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3635.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3635.pdf</a>
</p>
<p>
See also issue <a href="ewg-active.html#26">26</a>.
</p>
<p>
According to Wong, this paper was reviewed on the last day in EWG in Chicago
2013, although with no recorder. The summary was that many people liked the 1st solution (AliasGrouping), and authors are encouraged to develop it further. 
</p>
<p>Discussed further in Rapperswil 2014.</p>
<p>Straw poll: Encourage continued work?</p>
<p>SF 11, WF 9, N 3, WA 0, SA 0.</p>
<p>Carruth enumerated the following questions, which were encouraged
to be answered: should it be ill-formed if this expression has side-effects? Is it an evaluated expression? That changes whether it odr-uses things, whether we have to emit code? Can it be allowed to instantiate templates, and is so what is the point of instantiation?</p>
<p>
Discussed in Urbana. EWG voted to forward the proposal to CWG for
wording review.
</p>




<hr>
<h3><a name="74"></a>74. 
N3723 Extend operator-> to support rvalues
</h3>
<p><b>Section:</b> 13.5.6 [over.ref] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Pascal Costanza <b>Opened:</b> 2013-08-23 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3723.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3723.html</a>
</p>
<p>
Discussed in Chicago 2013: Return object that overloads -> to point to 
subobject. Wrapper that points into itself. Boost "iterator facade" that 
uses curiously recursive template pattern that does this. It's a pain. 
What other motivating use cases demonstrate this is a general problem? 
Has to be a relation to operator. that we've tried to invent a few times. 
Extra integer looks odd, more so than hack for operator++. We're not yet 
convinced problem is general enough to require a language change. Not 
opposed to change, but feels like it's tail end of bigger problem. 
Didn't quite like the syntax. 
</p>




<hr>
<h3><a name="75"></a>75. 
N3744 Proposing [[pure]]
</h3>
<p><b>Section:</b> 7.6.1 [dcl.attr.grammar] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2013-08-30 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3744.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3744.pdf</a>
</p>
<p>
Discussed in Chicago 2013: 

<p>    Poll 4: Conservative approach. SF 3 - 2 - 5 - 0 - 0 SA </p>
<p>    Poll 5: Aggressive approach: SF 6 - 1 - 3 - 0 - 0 SA </p>
<p>    Poll 6: Support both, with different attributes. SF 4 - 2 - 3 - 1 - 0 SA </p>

<p>
Vandevoorde expressed that he likes the idea of having two attributes,
one for memoizing and the other for non-side-effecting. Stroustrup and
Spertus expressed concern about multiple attributes being confusing.
Stroustrup gave his guidance to have a two-part proposal with both
the "aggressive" mode and the more conservative mode. Vandevoorde
promised his assistance for writing the wording.
</p>
</p>




<hr>
<h3><a name="76"></a>76. 
N4035, N3748 Implicit Evaluation of "auto" Variables and Arguments
</h3>
<p><b>Section:</b> 7.1.6.4 [dcl.spec.auto] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Peter Gottschling <b>Opened:</b> 2013-08-30 <b>Last modified:</b> 2015-05-22</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4035.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4035.pdf</a>
</p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3748.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3748.pdf</a>
</p>
<p>
Reviewed in Chicago 2013. Stroustrup recommended looking into Vandevoorde's 
solution of doing a type manipulation instead of running code in a conversion 
since there doesn't seem to a palatable reason for running code, and thought 
that the solution should be simplified, and it should be much better than 
what you can hack today. The author is encouraged to pursue the idea further.
</p>
<p>Discussed in Rapperswil 2014.</p>
<p>Straw poll: On the proposal as is:</p>
<p>SF 0 - WF 1 - N 8 - WA 13 - SA 2</p>
<p>Stroustrup said his reading of this is that we agree there's a problem, but we don't think that this is the solution.</p>
<p>Straw poll: See a new proposal based on this one, but with "using auto" only applying to variable and data member initializers:</p>
<p>SF 2 - WF 8 - N 8 - WA 1 - SA 3</p>
<p>Carruth suggested writing a new paper with more rationale/explanation of the tradeoffs, decisions, etc., and Dennett agreed.</p>




<hr>
<h3><a name="78"></a>78. 
N3820 Working Draft, Technical Specification -- Array Extensions, 
N3810	Alternatives for Array Extensions
</h3>
<p><b>Section:</b> 3.9 [basic.types] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Lawrence Crowl, Bjarne Stroustrup <b>Opened:</b> 2013-10-10 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#basic.types">active issues</a> in [basic.types].</p>
<p><b>View all other</b> <a href="ewg-index.html#basic.types">issues</a> in [basic.types].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3810.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3810.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3820.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3820.html</a>
</p>
<p>See also issue <a href="ewg-active.html#125">125</a>.</p>




<hr>
<h3><a name="79"></a>79. 
[tiny] Core issues with extension status
</h3>
<p><b>Section:</b> 1 [intro] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2014-01-16 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#intro">active issues</a> in [intro].</p>
<p><b>View all other</b> <a href="ewg-index.html#intro">issues</a> in [intro].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#92">92 	Should exception-specifications be part of the type system?</a> -> (SUPERSEDED) Instruct Core to close 92 as NAD. Maurer points out that he's
going to be dealing with the area with TM. The rationale for
closing is that EWG doesn't agree that being able to overload
on noexcept is worth the trouble, nor does EWG think being
able to have pointers-to-functions being different parameter
types if they have different noexcept-specifications.
-> New paper and a new EWG issue, <a href="ewg-active.html#169">169</a>.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#476">476 	Determining the buffer size for placement new</a> -> new EWG issue, <a href="ewg-closed.html#90">90</a>. The EWG issue is NAD -> clarification from CWG requested.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#687">687 	template keyword with unqualified-ids</a> -> new EWG issue, <a href="ewg-active.html#92">92</a>. -> instruct CWG to reopen, Vandevoorde working on wording.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#728">728 	Restrictions on local classes</a> -> new EWG issue, <a href="ewg-active.html#93">93</a>.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#794">794 	Base-derived conversion in member type of pointer-to-member conversion</a> -> Open an EWG issue for 794, <a href="ewg-active.html#94">94</a>. Snyder reports he is interested in authoring
a paper.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#914">914 	Value-initialization of array types</a> -> Open an EWG issue for 914 and 1300, <a href="ewg-active.html#96">96</a>. Instruct Core to close either
(probably 914)as a DUP. Instruct Core not to think EWG has looked at 1300,
because EWG hasn't. Include 1326 in the EWG issue, leave that open in
Core as well.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#944">944 reinterpret_cast for all types with the same size and alignment</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1008">1008 	Querying the alignment of an object</a> -> new EWG issue, <a href="ewg-active.html#98">98</a>.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1048">1048 	auto deduction and lambda return type deduction.</a> -> Instruct Core to reopen 1048 and clarify the issue, since there
is implementation divergence. Ask Merrill whether he has implemented
what he thought was right. clang seems to be consistent. decltype(f())
is const A in gcc, decltype(b()) is A in gcc. in clang, both are
const A.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1077">1077 	Explicit specializations in non-containing namespaces</a> -> EWG has an issue for 1077. Link to the core issue from that (done), and
vice versa if CWG chair so chooses.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1300">1300 	T() for array types</a> -> Open an EWG issue for 914 and 1300, <a href="ewg-active.html#96">96</a>. Instruct Core to close either
(probably 914)as a DUP. Instruct Core not to think EWG has looked at 1300,
because EWG hasn't. Include 1326 in the EWG issue, leave that open in
Core as well.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1326">1326 	Deducing an array bound from an initializer-list</a> -> see above
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1331">1331 	const mismatch with defaulted copy constructor</a> -> Open an EWG issue for 1331, <a href="ewg-active.html#101">101</a>. Needs analysis and implementation vendor
feedback.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1393">1393 	Pack expansions in using-declarations</a> -> Open an EWG issue for 1393, <a href="ewg-active.html#102">102</a>. There are other related extension
almost-proposals that should be considered in addition to the
case in point.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1426">1426 	Allowing additional parameter types in defaulted functions</a> -> new EWG issue, <a href="ewg-closed.html#103">103</a>.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1433">1433 	trailing-return-type and point of declaration</a> -> new EWG issue, <a href="ewg-closed.html#104">104</a>.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1451">1451 	Objects with no linkage in non-type template arguments</a> -> new EWG issue, <a href="ewg-closed.html#105">105</a>.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1463">1463 	extern "C" alias templates</a> -> new EWG issue, <a href="ewg-active.html#106">106</a>, see above about 13.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1469">1469 Omitted bound in array new-expression</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1555">1555 	Language linkage and function type compatibility</a> -> Instruct SG12 to handle 1555. (done, SG12 chair has been notified)
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1561">1561 	Aggregates with empty base classes</a> -> new EWG issue, <a href="ewg-active.html#108">108</a>.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1577">1577 	Unnecessary restrictions on partial specializations</a> -> new EWG issue, <a href="ewg-closed.html#110">110</a>. -> issue is NAD, suggest CWG closes as NAD as well.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1582">1582 Template default arguments and deduction failure</a> -> new EWG issue, <a href="ewg-active.html#111">111</a>. -> EWG wishes to send this back to CWG for drafting Spicer's suggestion.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1643">1643 	Default arguments for template parameter packs</a> -> Link 1643 to EWG issue 15 (done) and vice versa.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1826">1826 const floating-point in constant expressions</a>
</p>
<p>Straw poll, Rapperswil 2014:</p>
<p>To make it consistent by allowing "const float f = 2.0" to allow use of f in constexpr evaluation:</p>
<p>SF 4 - WF 12 - N 1 - WA 0 - SA 0</p>
<p>-> instruct CWG to reopen and resolve so that const floating point
is allowed in constant expressions.</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1790">1790 Ellipsis following function parameter pack</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1864">1864 List-initialization of array objects</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1871">1871 Non-identifier characters in ud-suffix</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1876">1876 Preventing explicit specialization</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1912">1912 exception-specification of defaulted function</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1914">1914 Duplicate standard attributes</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1915">1915 Potentially-invoked destructors in non-throwing constructors</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1923">1923 Lvalues of type void</a>
</p> 
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1931">1931 Default-constructible and copy-assignable closure types</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1934">1934 Relaxing exception-specification compatibility requirements</a></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1957">1957 decltype(auto) with direct-list-initialization</a></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#2097">2097  Lambdas and noreturn attribute</a>
</p>





<hr>
<h3><a name="81"></a>81. 
N3994, N3853 Range-Based For-Loops: The Next Generation
</h3>
<p><b>Section:</b> 6.5 [stmt.iter] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-01-17 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#stmt.iter">active issues</a> in [stmt.iter].</p>
<p><b>View all other</b> <a href="ewg-index.html#stmt.iter">issues</a> in [stmt.iter].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3994.htm">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3994.htm</a>
</p>

<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3853.htm">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3853.htm</a>
</p>
<p>
Issaquah 2014: EWG discussed the paper, and found consensus
to move the proposal forward to Core, and it has wording already.
</p>
<p>
Rejected by the full committee in Urbana. Author is going to revise.
</p>

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




<hr>
<h3><a name="83"></a>83. 
N3863 Private Extension Methods
</h3>
<p><b>Section:</b> 9.3 [class.mfct] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Matthew Fioravante <b>Opened:</b> 2013-12-08 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3863.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3863.html</a>
</p>




<hr>
<h3><a name="84"></a>84. 
N4294 Arrays of run-time bounds as data members, N3875 Run-time bound array data members
</h3>
<p><b>Section:</b> 9.2 [class.mem] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> J. D. Garcia, X. Li <b>Opened:</b> 2014-01-16 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#class.mem">active issues</a> in [class.mem].</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4294.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4294.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3875.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3875.pdf</a>
</p>
<p>
Issaquah 2014: EWG discussed the paper, and the author was present
and received feedback to do further work on the paper.
</p>




<hr>
<h3><a name="86"></a>86. 
N3880 	Improving the Verification of C++ Programs
</h3>
<p><b>Section:</b> 1 [intro] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Michael Price <b>Opened:</b> 2014-01-16 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#intro">active issues</a> in [intro].</p>
<p><b>View all other</b> <a href="ewg-index.html#intro">issues</a> in [intro].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3880.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3880.html</a>
</p>
<p>
Issaquah 2014: The paper was presented to EWG, and the author
was encouraged to continue working on the idea and to come up
with concrete proposals for EWG to vote on.
</p>




<hr>
<h3><a name="88"></a>88. 
[tiny] Uniform handling of operator[] and operator().
</h3>
<p><b>Section:</b> 13.5 [over.oper] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2014-02-14 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#over.oper">active issues</a> in [over.oper].</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In c++std-core-14770, Dos Reis suggests that operator[] and
operator() should both be allowed to be static. In addition
to that, he suggests that both should allow multiple parameters.
It's well known that there's a possibility that this breaks
existing code (foo[1,2] is valid, the thing in brackets
is a comma-expression) but there are possibilities to fix
such cases (by requiring parens if a comma-expression
is desired). EWG should discuss whether such unification
is to be strived for.
</p>
<p>Discussed in Rapperswil 2014. EWG points out that there are more issues to consider here, in terms of other operators, motivations, connections with captureless lambdas, who knows what else, so an analysis paper is requested.
</p>




<hr>
<h3><a name="92"></a>92. 
[tiny] Core issue 687, template keyword with unqualified-ids
</h3>
<p><b>Section:</b> 5.1.1 [expr.prim.general] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Mihai Rusu <b>Opened:</b> 2008-02-27 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#687">Core issue 687</a>.
</p>
<p>Discussed in Rapperswil 2014. EWG thinks the use of a template keyword
in such cases should be allowed. Vandevoorde to write the wording for
CWG review.</p>




<hr>
<h3><a name="93"></a>93. 
[tiny] Core issue 728, Restrictions on local classes
</h3>
<p><b>Section:</b> 14 [temp] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Faisal Vali <b>Opened:</b> 2008-10-05 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#temp">active issues</a> in [temp].</p>
<p><b>View all other</b> <a href="ewg-index.html#temp">issues</a> in [temp].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#728">Core issue 728</a>.
</p>




<hr>
<h3><a name="94"></a>94. 
[tiny] Core issue 794, Base-derived conversion in member type of pointer-to-member conversion
</h3>
<p><b>Section:</b> 4.11 [conv.mem] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> CH, Detlef Vollman <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2015-05-22</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#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#794">Core issue 794</a>. Jeff Snyder reports he is interested in authoring
a paper.
</p>




<hr>
<h3><a name="96"></a>96. 
[tiny] Core issue 914, Value-initialization of array types, Core issue 1300, T() for array types, Core issue 1326, Deducing an array bound from an initializer-list
</h3>
<p><b>Section:</b> 5.2.3 [expr.type.conv] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2009-06-10 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#914">Core issue 914</a>, <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1300">Core issue 1300</a> and <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1326">Core issue 1326</a>. 
</p>
<p>Discussed in Rapperswil 2014. Dos Reis and Kr&uuml;gler encouraged to write a paper.</p>




<hr>
<h3><a name="98"></a>98. 
[tiny] Core issue 1008, Querying the alignment of an object
</h3>
<p><b>Section:</b> 5.3.6 [expr.alignof] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2009-11-27 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1008">Core issue 1008</a>.
</p>
<p>Discussed in Rapperswil 2014. Vandevoorde to write a paper.</p>




<hr>
<h3><a name="101"></a>101. 
[tiny] Core issue 1331, const mismatch with defaulted copy constructor
</h3>
<p><b>Section:</b> 12.8 [class.copy] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-03-18 <b>Last modified:</b> 2015-05-22</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1331">Core issue 1331</a>.
</p>
<p>
Needs analysis and implementation vendor
feedback.
</p>
<p>
Discussed in Rapperswil 2014. Kr&uuml;gler encouraged to write a paper, including motivating examples.
</p>




<hr>
<h3><a name="102"></a>102. 
[tiny] Core issue 1393, Pack expansions in using-declarations
</h3>
<p><b>Section:</b> 14.5.3 [temp.variadic] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-09-10 <b>Last modified:</b> 2015-05-22</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1393">Core issue 1393</a>.
</p>
<p>
There are other related extension
almost-proposals that should be considered in addition to the
case in point.
</p>
<p>
Vandevoorde to write a paper and bring it back to EWG. The guidance is to allow multiple names in using-declarations, and also allowing a pack.
</p>




<hr>
<h3><a name="106"></a>106. 
[tiny] Core issue 1463, extern "C" alias templates, Core issue 13, extern "C" for Parameters of Function Templates
</h3>
<p><b>Section:</b> 14 [temp] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Daveed Vandevoorde <b>Opened:</b> 2011-08-19 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#temp">active issues</a> in [temp].</p>
<p><b>View all other</b> <a href="ewg-index.html#temp">issues</a> in [temp].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1463">Core issue 1463</a> and <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#13">Core issue 13</a>.
</p>
<p>Discussed in Rapperswil 2014. Vandevoorde to write a paper.</p>




<hr>
<h3><a name="108"></a>108. 
N4404 Extension to aggregate initialization, was [tiny] Core issue 1561, Aggregates with empty base classes
</h3>
<p><b>Section:</b> 8.5.1 [dcl.init.aggr] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Gabriel Dos Reis, Oleg Smolsky <b>Opened:</b> 2012-09-29 <b>Last modified:</b> 2015-05-22</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4404.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4404.html</a>
</p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1561">Core issue 1561</a>.
</p>
<p>Discussed in Rapperswil 2014. Daryle Walker has an unpublished paper aiming to solve this <a href="http://htmlpreview.github.io/?https://raw.github.com/CTMacUser/multiarray-iso-proposal/master/expanded-aggregate-proposal.html">here</a>. EWG suggests that Dos Reis works with Walker to get the paper on EWG's plate.</p>
<p>
N4404 was discussed in Lenexa, EWG rejected the paper as such and 
recommended looking at a more comprehensive approach.
</p>




<hr>
<h3><a name="111"></a>111. 
[tiny] Core issue 1582, Template default arguments and deduction failure
</h3>
<p><b>Section:</b> 14.8.2 [temp.deduct] <b>Status:</b> <a href="ewg-active.html#Ready">Ready</a>
 <b>Submitter:</b> John Spicer <b>Opened:</b> 2012-10-31 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#temp.deduct">active issues</a> in [temp.deduct].</p>
<p><b>View all other</b> <a href="ewg-index.html#temp.deduct">issues</a> in [temp.deduct].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1582">Core issue 1582</a>.
</p>
<p>Discussed in Rapperswil 2014. EWG wishes CWG to handle this, and
to draft to implement Spicer's suggestion.</p>




<hr>
<h3><a name="115"></a>115. 
N3899 	Nested Allocation
</h3>
<p><b>Section:</b> 3.8 [basic.life] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#basic.life">active issues</a> in [basic.life].</p>
<p><b>View all other</b> <a href="ewg-index.html#basic.life">issues</a> in [basic.life].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3899.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3899.html</a>.
</p>




<hr>
<h3><a name="116"></a>116. 
N4475 Default comparisons (R2), N4476 Thoughts about Comparisons (R2), N4126, N4114, N3950 Defaulted comparison operators, N4175 Default comparisons, N4176 Thoughts about Comparisons, N4239 Defaulted Comparison Using Reflection
</h3>
<p><b>Section:</b> 8.4.2 [dcl.fct.def.default] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Oleg Smolsky, Bjarne Stroustrup, Andrew Tomazos, Mike Spertus <b>Opened:</b> 2014-02-19 <b>Last modified:</b> 2015-05-22</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4476.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4476.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4475.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4475.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4239.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4239.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4126.htm">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4126.htm</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4175.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4175.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4176.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4176.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4114.htm">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4114.htm</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3950.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3950.html</a>
</p>
<p>Discussed in Rapperswil 2014.</p>
<p>Straw polls:</p>
<p>Proposal + the ability to default as global</p>
<p>SF: 10 F: 9 N: 2 A: 1 SA: 0</p>
<p>Proposal + the ability to default as global + the generation of negated operators</p>
<p>SF: 5 F: 9 N: 3 A: 1 SA: 2</p>
<p>Terse syntaxes only</p>
<p>SF: 7 F: 2 N: 4 A: 8 SA: 1</p>
<p>Terse syntaxes in addition</p>
<p>SF: 6 F: 6 N: 5 A: 4 SA: 1</p>
<p>Library solution</p>
<p>SF: 0 F: 0 N: 1 A: 12 SA: 7</p>
<p>Mutable members are not special (participate in the comparisons)</p>
<p>SF: 2 F: 6 N: 2 A: 5 SA: 6</p>
<p>Mutable members make defaulting ill-formed</p>
<p>SF: 3 F: 7 N: 6 A: 3 SA: 1</p>
<p>Mutable members do not participate in generated comparisons</p>
<p>SF: 7 F: 3 N: 0 A: 7 SA: 4</p>
<p>Proposal + the ability to default as global + mutables ill-formed</p>
<p>SF: 12 F: 7 N: 0 A: 1 SA: 2</p>
<p>
The guidance of the vote is not very clear, but what seems clear is that
EWG more or less encouraged the paper author to come up with a revised
proposal.
</p>
<p>
Discussed in Urbana. EWG voiced preference towards an opt-in approach.
</p>
<p>
Discussed in Lenexa. The design changes that alleviate compatibility
concerns gained EWG support. There is ongoing work to produce Core
wording, but that work raised further design questions. The design
paper needs an update for Kona.
</p>

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




<hr>
<h3><a name="118"></a>118. [tiny] Allow conversion from pointer to array of known bound to pointer to array of unknown bound
</h3>
<p><b>Section:</b> 4 [conv] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2014-02-15 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#conv">active issues</a> in [conv].</p>
<p><b>View all other</b> <a href="ewg-index.html#conv">issues</a> in [conv].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
With core issue 393, we're allowing function parameters to have type 'T (*)[]' or 'T (&amp;)[]'. This has always been allowed for variables, and is useful in practice:
</p>
<p>
<pre>
// guaranteed to be passed an actual array, not just a pointer, but the array can be of any size.
void f(int n, int (&amp;a)[]) {
  ... do stuff with first n elements of a ...
}

extern int arr[];
void g() { f(100, arr); }
void h(int *p) { f(100, p); } // error, not an array!

// elsewhere
int arr[100]; // ok, no problem
void i() { f(100, arr); } // error!
</pre>
</p>
<p>
Note that if you actually know the bound of 'arr', you *cannot* pass it to f, because you can't pass 'int [100]' glvalues to a 'int (&amp;)[]' parameter.
</p>
<p>
So, I'd like EWG to consider this extension:
</p>
<p>
We should allow "array of N T" glvalues to convert to "array of unknown bound of T", and likewise we should allow "cv pointer to array of N T" prvalues to convert to "cv pointer to array of unknown bound of T" prvalues.
</p>
<p>Discussed in Rapperswil 2014. EWG wishes to encourage Smith to write
a paper for EWG review, EWG expects to send it forwards to CWG without much
ado.</p>




<hr>
<h3><a name="120"></a>120. [tiny] CWG 900 and 1498
</h3>
<p><b>Section:</b> 12.2 [class.temporary] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Geoffrey Romer <b>Opened:</b> 2014-05-31 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The discussion thread started at [c++std-core-25298]
</p>
<p>
The core issues are <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#900">CWG 900</a> and <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1498">CWG 1498</a>
</p>
<p>Romer wrote:
</p>

<p>
The current resolutions of CWG 900 and 1498 don't seem right to me. The NAD rationale for CWG 900 appears to be saying that there is no problem, because the lifetime of _expression_ is extended by being bound to a reference. However, that applies only to the value of _expression_ itself; the lifetimes of any proper sub-expressions of _expression_ are not so extended. CWG 900 may be a little ambiguous about which temporaries it's referring to, but CWG 1498 is not; it's quite explicitly concerned with sub-expression temporaries, so the rationale for CWG 900 definitely does not apply.
</p>
<p>
To make this concrete, consider the following example, taken from <a href="https://svn.boost.org/trac/boost/ticket/7630">https://svn.boost.org/trac/boost/ticket/7630</a>:
</p>
<p>
<pre>
<code>
 std::vector&lt;int> vec;
 for (int val : vec | boost::adaptors::reversed
                    | boost::adaptors::uniqued) {
   // Do stuff with val
 }
</code>
</pre>
</p>
<p>
The behavior of this code is undefined, because the temporary returned by the subexpression (vec | boost::adaptors::reversed) is destroyed before the loop body is entered, leaving __range's referent holding a dangling reference to it. The adaptors can mostly fix the issue by overloading on rvalue references, but at the cost of a substantial increase in code complexity.
</p>
<p>Smith suggested handling this as an EWG issue.
</p>
<p>Discussed in Rapperswil 2014. EWG wants a solution, and welcomes
a paper tackling the issue. Vandevoorde raised concerns introducing any 
new lifetime models. Stroustrup pointed out that the end-of-full-expression rule came about to reduce memory footprint compared to the end-of-block rule, and is good for RAII uses. Is it possible to solve the issue by just modifying
the specification of a range-for loop?</p>




<hr>
<h3><a name="122"></a>122. N3986 Adding Standard support to avoid padding within structures
</h3>
<p><b>Section:</b> 9.6 [class.bit] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> S. Davalle, D. Gutson, A. Bustamante <b>Opened:</b> 2014-05-06 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3986.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3986.pdf</a>
</p>
<p><b>Wording available:</b></p>
<p>
The paper contains the proposed wording.
</p>

<p>Discussed in Rapperswil 2014. Not polled yet.</p>
<p>
Garcia thought attributes should be explored as a solution rather than 
using a bitfield of negative width. Stroustrup asked why the facility is 
per-field rather than per-class. Gutson explained that he doesn't always want 
pack whole structures, and Stroustrup and Tomazos pointed out that splitting 
a larger class into smaller ones should solve the problem.
</p>
<p>
Vandevoorde pointed out implementation issues and asked what happens if a 
target architecture doesn't support the resulting padding (or the lack of it). 
It was suggested that the current standard may allow implementations to 
diagnose such cases anyway.
</p>
<p>
Naumann made the point that he thinks code should be portable but that object 
layout cannot be specified in such a strict manner due to architecture 
differences. Smolsky asked whether there are plans to impose endianness 
requirements on the representation of built-in types, and voiced concern 
about a performance impact.
</p>
<p>
Wong expressed doubt whether a standard solution is necessary, since every 
vendor has a solution. Vandevoorde replied that that sounds like a good reason 
to provide a standard solution. 
</p>
<p>
Bos asked why there needs to be this support in classes rather than 
manipulating bits with a function. Dennett pointed out that this proposal 
turns things that aren't bitfields into bitfield-like things, because what 
looks like an int cannot be treated as an int.
</p>
<p>
Vandevoorde pointed out that alignas is almost a solution, but it doesn't 
apply to bitfields, and suggested using arrays instead of plain ints for the 
data that needs to be packed. Stroustrup recommended doing a survey of 
existing practice.
</p>




<hr>
<h3><a name="125"></a>125. N4025 Exploring classes of runtime size
</h3>
<p><b>Section:</b> 3.9.2 [basic.compound] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> J. Snyder, R. Smith <b>Opened:</b> 2014-05-23 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4025.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4025.pdf</a>
</p>
<p>Discussed in Rapperswil 2014, with a fairly long discussion that
didn't yield very concrete conclusions.</p>
<p>Straw polls:</p>
<p>Array of runtime bounds:</p>
<p>SF: 2 F: 2 N: 6 A: 11 SA: 2</p>
<p>Objects of dynamic size:</p>
<p>SF: 1 F: 7 N: 7 A: 6 SA: 2</p>
<p>Magic allocation outside of a type:</p>
<p>SF: 0 F: 11 N: 9 A: 1 SA: 0</p>
<p>Nothing:</p>
<p>SF: 2 F: 10 N: 6 A: 4 SA: 0</p>
<p>The group found it difficult to interpret the results, and where to go from here.</p>
<p>
Carruth pointed out that it doesn't seem we can agree on an evolution path to take, and perhaps that should be our message to the full committee, and if someone disagrees, they should come up with a better evolution path. Voutilainen pointed out that this is not the first time we have failed to find real consensus about dynamic arrays. Smith said having nothing is the status quo of the C++ standard, and ARBs are what the TS proposes, and there would be a possibility to keep ARBs in a TS without integrating them to the main standard. 
</p>




<hr>
<h3><a name="127"></a>127. N4028 Defining a Portable C++ ABI
</h3>
<p><b>Section:</b> 3.5 [basic.link] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2014-05-23 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4028.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4028.pdf</a>
</p>
<p>Discussed in Rapperswil 2014</p>
<p>Straw poll: should we encourage Sutter to go ahead:</p>
<p> SF 10 F 8 N 3 A 3 SA 3</p>
<p>Sutter asked the reason for the votes against, Gregor expressed
doubt on whether the approach is feasible with regards to the amount
of work, Carruth expressed doubt on having two slightly different
standard libraries.</p>
<p>Stra poll: language ABI:</p>
<p>SF 12 F 14 N 0 A 1 SA 0</p>
<p>Wong said something like this would be ideal for a Study Group. Wong
and Sutter expressed interest in continuing to work on the idea.</p>




<hr>
<h3><a name="128"></a>128. N4043 Dynarray Allocation Context
</h3>
<p><b>Section:</b> 23.3 [sequences] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2014-05-22 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#sequences">active issues</a> in [sequences].</p>
<p><b>View all other</b> <a href="ewg-index.html#sequences">issues</a> in [sequences].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4043.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4043.html</a>
</p>




<hr>
<h3><a name="129"></a>129. N4234 0-overhead-principle violations in exception handling - part 2, N4049 0-overhead-principle violations in exception handling
</h3>
<p><b>Section:</b> 15 [except] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> D. Gutson, A. Bustamante, P. Oliva, M. Diaz <b>Opened:</b> 2014-05-27 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4234.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4234.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4049.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4049.pdf</a>
</p>
<p>
Discussed in Urbana. The author is encouraged to work on it further.
</p>




<hr>
<h3><a name="130"></a>130. N4050 Dynarray Semi-Editorial Issues
</h3>
<p><b>Section:</b> 23.3 [sequences] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2014-05-26 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#sequences">active issues</a> in [sequences].</p>
<p><b>View all other</b> <a href="ewg-index.html#sequences">issues</a> in [sequences].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4050.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4050.html</a>
</p>




<hr>
<h3><a name="135"></a>135. 
[tiny] Mutable is part of a lambda-declarator, so when a lambda is mutable, the parentheses aren't optional
</h3>
<p><b>Section:</b> 5.1.2 [expr.prim.lambda] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2014-07-02 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all other</b> <a href="ewg-index.html#expr.prim.lambda">issues</a> in [expr.prim.lambda].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It has been reported that various people have noticed that it's possible to write</p>
<pre>
<code>
auto lambda = []{};
</code>
</pre>
<p>but not</p>
<pre>
<code>
auto lambda2 = [] mutable {};
</code>
</pre>
<p>
In the mutable case, parentheses are required, thus:
</p>
<pre>
<code>
auto lambda3 = []() mutable {};
</code>
</pre>
<p>
The proposed consistency fix is to change the grammar to allow omitting the parentheses
for mutable lambdas as well.
</p>
<p>
An additional question EWG needs to decide is whether the empty parentheses
could be omitted for other cases besides mutable, such as</p>
<p>
<pre>
<code>
[] -> float {return 42;};
[] noexcept {foo();};
</code>
</pre>
</p>

<p><b>Wording available:</b></p>
<strong> Change the grammar in 5.1.2 [expr.prim.lambda] paragraph 1</strong>

<blockquote>
<pre><em>
lambda-expression:
      lambda-introducer lambda-declarator<del><sub>opt</sub></del> compound-statement
...

lambda-declarator:
      ( parameter-declaration-clause ) mutable<sub>opt</sub>
            exception-specification<sub>opt</sub> attribute-specifier-seq<sub>opt</sub> trailing-return-type<sub>opt</sub>
      <ins>mutable<sub>opt</sub> exception-specification<sub>opt</sub> attribute-specifier-seq<sub>opt</sub> trailing-return-type<sub>opt</sub></ins>
</em>
</pre>
</blockquote>


<strong> Remove from 5.1.2 [expr.prim.lambda] paragraph 4</strong>
<blockquote>
<del>If a <em>lambda-expression</em> does not include a <em>lambda-declarator</em>, it is as if the <em>lambda-declarator</em> were (). </del>
</blockquote>

<strong> Modify in 5.1.2 [expr.prim.lambda] paragraph 5</strong>
<blockquote>This function call operator or operator template is declared <code>const</code> (9.3.1) if and only if
the <del><em>lambda-expression</em>'s <em>parameter-declaration-clause</em> is not followed by</del><ins> <em>lambda-declarator</em> does not contain the keyword</ins> <code>mutable</code>. 
</blockquote>




<hr>
<h3><a name="136"></a>136. 
N4072 Fixed Size Parameter Packs
</h3>
<p><b>Section:</b> 14.3 [temp.arg] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Maurice Bos <b>Opened:</b> 2014-05-26 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4072.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4072.html</a>
</p>
<p>
Discussed in Rapperswil 2014.
</p>
<p>
Vote: encourage the author to come back with a more complete proposal for ...[N]: SF 8 - WF 9 - N 5 - WA 1 - SA 0. 
</p>




<hr>
<h3><a name="139"></a>139. 
N4121 Compile-Time String: std::string_literal&lt;n&gt;
</h3>
<p><b>Section:</b> 18.1 [support.general] <b>Status:</b> <a href="ewg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Andrew Tomazos <b>Opened:</b> 2014-07-04 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#support.general">active issues</a> in [support.general].</p>
<p><b>View all other</b> <a href="ewg-index.html#support.general">issues</a> in [support.general].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4121.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4121.pdf</a>
</p>
<p>
Discussed in Urbana. The design was approved by EWG, and the author
was encouraged to proceed to LEWG and CWG.
</p>




<hr>
<h3><a name="141"></a>141. 
N4415 Simple Contracts for C++, N4435 Proposing Contract Attributes, N4378 Language Support for Contract Assertions, N4379 FAQ about N4378, Language Support for Contract Assertions, N4253, N4135 Language Support for Runtime Contract Validation 
</h3>
<p><b>Section:</b> X [contract] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> J. Lakos, A. Zakharov, A. Beels, N. Myers <b>Opened:</b> 2014-10-09 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all other</b> <a href="ewg-index.html#contract">issues</a> in [contract].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4415.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4415.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4435.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4435.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4378.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4378.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4379.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4379.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4253.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4253.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4135.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4135.pdf</a>
</p>
<p>
Discussed at length in Urbana. In general, various paper authors are
encourage to do further work together on contract programming. See also
issue <a href="ewg-closed.html#137">137</a>, <a href="ewg-closed.html#159">159</a> and <a href="ewg-closed.html#168">168</a>.
</p>
<p>
Discussed in Lenexa. EWG's guidance was to allow contracts on both
declarations and definitions, and to unify the proposals.
</p>




<hr>
<h3><a name="142"></a>142. 
N4424 Inline Variables, N4147 Inline variables, or encapsulated expressions
</h3>
<p><b>Section:</b> 7.1.2 [dcl.fct.spec] <b>Status:</b> <a href="ewg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Hal Finkel, Richard Smith, David Krauss <b>Opened:</b> 2014-09-15 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4424.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4424.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4147.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4147.pdf</a>
</p>
<p>
Discussed in Urbana. EWG encouraged solving the problem, and wanted
the shared constants to be separated from expression aliases, so that
the former can be solved sooner than the latter.
</p>
<p>
N4424 was discussed in Lenexa and accepted by EWG. The authors are encouraged
to take a wording paper to CWG.
</p>




<hr>
<h3><a name="143"></a>143. 
N4148 Disallowing Inaccessible Operators From Trivially Copyable
</h3>
<p><b>Section:</b> 3.9 [basic.types] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Matheus Izvekov <b>Opened:</b> 2014-09-24 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#basic.types">active issues</a> in [basic.types].</p>
<p><b>View all other</b> <a href="ewg-index.html#basic.types">issues</a> in [basic.types].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4148.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4148.html</a>
</p>
<p>
Discussed in Urbana. The author is encouraged to revise the paper.
EWG suggested splitting the core language concept of trivially copyable
into trivially copyable and trivially movable, and gave guidance against
adding new library traits for the latter, since such a trait would not
have use cases.
</p>




<hr>
<h3><a name="146"></a>146. 
N4160 Value constraints
</h3>
<p><b>Section:</b> 8.3.5 [dcl.fct] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Andrzej Krzemienski <b>Opened:</b> 2014-10-03 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#dcl.fct">active issues</a> in [dcl.fct].</p>
<p><b>View all other</b> <a href="ewg-index.html#dcl.fct">issues</a> in [dcl.fct].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4160.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4160.html</a>
</p>




<hr>
<h3><a name="148"></a>148. 
N4474 Unified Call Syntax: x.f(y) and f(x,y), N4165 Unified Call Syntax, N4174 Call syntax: x.f(y) vs. f(x,y)
</h3>
<p><b>Section:</b> 5.2.2 [expr.call] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Herb Sutter, Bjarne Stroustrup <b>Opened:</b> 2014-10-04 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4474.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4474.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4165.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4165.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4174.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4174.pdf</a>
</p>
<p>
Discussed in Urbana. EWG favored being able to invoke non-members with
the member call syntax, and was undecided on the other aspects. Authors
are encouraged to follow up.
</p>
<p>
Discussed in Lenexa. EWG didn't reach consensus on the proposal. Straw
poll numbers were SF/WF/N/WA/SA 9/8/3/4/6. There is strong opposition
to the proposal with concerns about maintainability of code when
new free functions are added.
</p>




<hr>
<h3><a name="149"></a>149. 
N4166 Movable initializer lists
</h3>
<p><b>Section:</b> 18.9 [support.initlist] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> David Krauss <b>Opened:</b> 2014-10-06 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#support.initlist">active issues</a> in [support.initlist].</p>
<p><b>View all other</b> <a href="ewg-index.html#support.initlist">issues</a> in [support.initlist].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4166.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4166.pdf</a>
</p>
<p>
Discussed in Urbana. EWG thought the problem is worth solving, but
expressed doubt about this proposal being the right approach. Further
work is encouraged.
</p>




<hr>
<h3><a name="151"></a>151. 
N4477 Operator Dot (R2), N4173 Operator Dot
</h3>
<p><b>Section:</b> 13.5 [over.oper] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> B. Stroustrup, G. Dos Reis <b>Opened:</b> 2014-10-11 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#over.oper">active issues</a> in [over.oper].</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4477.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4477.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4173.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4173.pdf</a>
</p>
<p>
Discussed in Urbana, the authors are encouraged to continue working further
on it.
</p>
<p>Discussed in Lenexa. The author is encouraged to revise and come back
to EWG with a paper that has wording in it, the overall design was accepted by
EWG.
</p>




<hr>
<h3><a name="152"></a>152. 
N4186 	Supporting Custom Diagnostics and SFINAE
</h3>
<p><b>Section:</b> 8.4.3 [dcl.fct.def.delete] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Matthias Kretz <b>Opened:</b> 2014-10-10 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4186.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4186.pdf</a>
</p>
<p>
Discussed in Urbana. EWG thought the problem is worth solving, and the author is encouraged to follow up.
</p>




<hr>
<h3><a name="153"></a>153. 
N4188 	Proposal for classes with runtime size
</h3>
<p><b>Section:</b> 9.2 [class.mem] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> L. Deniau, A. Naumann <b>Opened:</b> 2014-10-01 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#class.mem">active issues</a> in [class.mem].</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4188.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4188.pdf</a>
</p>
<p>
Discussed in Urbana. The proposed approach was found to have
some issues, authors are encouraged to continue to try and
find a solution for runtime-sized types.
</p>




<hr>
<h3><a name="158"></a>158. 
N4228 	Refining Expression Evaluation Order for Idiomatic C++
</h3>
<p><b>Section:</b> 5 [expr] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> G. Dos Reis, H. Sutter, J. Caves <b>Opened:</b> 2014-10-13 <b>Last modified:</b> 2015-05-22</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4228.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4228.pdf</a>
</p>
<p>Discussed in Urbana. Author is encouraged to pursue further, with
the aim of adopting this proposal into C++17.
</p>




<hr>
<h3><a name="160"></a>160. 
N4393 Noop Constructors and Destructors, N4158 Destructive Move (Rev 1), N4034 Destructive Move
</h3>
<p><b>Section:</b> 3.8 [basic.life] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2014-10-12 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#basic.life">active issues</a> in [basic.life].</p>
<p><b>View all other</b> <a href="ewg-index.html#basic.life">issues</a> in [basic.life].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4393.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4393.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4158.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4158.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4034.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4034.pdf</a>
</p>
<p>
Discussed in Urbana. The author is encouraged to revise.
</p>
<p>
Discussed again in Lenexa. Great concerns about the impact on lifetime,
progress postponed until the paper author and some experts review whether
there are solutions that do not require language changes.
</p>




<hr>
<h3><a name="162"></a>162. 
N4357 Introduce the [[noexit]] attribute for main as a hint to eliminate destructor calls for objects with static storage duration, N4226 Apply the [[noreturn]] attribute to main as a hint to eliminate global object destructor calls
</h3>
<p><b>Section:</b> 3.6.1 [basic.start.main] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> D. Diaz, E. Bringas, D. Gutson, J. Maurer <b>Opened:</b> 2014-10-10 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4357.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4357.html</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4226.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4226.pdf</a>
</p>
<p>
Discussed in Urbana. EWG was supportive of the idea, CWG pointed out
various issues related to multiple translation units. Authors are
encouraged to revise.
</p>




<hr>
<h3><a name="163"></a>163. 
N4465 A Module System for C++ (Revision 3), N4466 Wording for Modules, N4214 A Module System for C++ (Revision 2), N4047 A Module System for C++
</h3>
<p><b>Section:</b> X [modules] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> G. Dos Reis, M. Hall, G. Nishanov <b>Opened:</b> 2014-05-27 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4466.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4466.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4465.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4465.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4047.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4047.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4214.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4214.pdf</a>
</p>
<p>
Discussed in Urbana. Authors are encouraged to work further, and implementation
vendors are encouraged to gain implementation experience with the proposed
syntax and semantics.
</p>
<p>
Discussed in Lenexa. The overall notational model was supported by EWG,
but there are fairly many technical details to solve. The authors are
encouraged to talk to other implementation vendors before Kona and
update the design paper.
</p>




<hr>
<h3><a name="164"></a>164. 
N4129 Source-Code Information Capture
</h3>
<p><b>Section:</b> 18.1 [support.general] <b>Status:</b> <a href="ewg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Robert Douglas <b>Opened:</b> 2014-10-10 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#support.general">active issues</a> in [support.general].</p>
<p><b>View all other</b> <a href="ewg-index.html#support.general">issues</a> in [support.general].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4129.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4129.pdf</a>
</p>
<p>
Discussed in Urbana. EWG voted to forward the proposal to LEWG and CWG.
</p>




<hr>
<h3><a name="165"></a>165. 
N4229 Pointer Ordering
</h3>
<p><b>Section:</b> 20.8.5 [comparisons] <b>Status:</b> <a href="ewg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2014-10-13 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4229.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4229.pdf</a>
</p>
<p>
Discussed in Urbana. EWG voted to forward the proposal to LWG.
</p>




<hr>
<h3><a name="166"></a>166. 
N4402 Resumable Functions (revision 4), N4403 Draft Wording for Resumable Functions, N4286 Resumable Functions, N4287 Threads, Fibers and Couroutines (slides deck) 
</h3>
<p><b>Section:</b> X [coroutine] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Gor Nishanov, Jim Radigan <b>Opened:</b> 2014-11-11 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all other</b> <a href="ewg-index.html#coroutine">issues</a> in [coroutine].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4286.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4286.pdf</a>
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4287.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4287.pdf</a>
</p>
<p>
Discussed in Urbana. Further proposals expected.
</p>
<p>
Discussed in Lenexa, EWG gave guidance related to what sort of keywords
to use, and recommended continuing the work on the wording. The design
is accepted, but the library-magic parts have been requested to be
taken through LEWG.
</p>




<hr>
<h3><a name="169"></a>169. 
N4320 Make exception specifications be part of the type system 
</h3>
<p><b>Section:</b> 4 [conv] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2014-11-20 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#conv">active issues</a> in [conv].</p>
<p><b>View all other</b> <a href="ewg-index.html#conv">issues</a> in [conv].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4320.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4320.html</a>
</p>
<p>
Discussed in Lenexa, accepted by EWG. The motion was postponed to Kona in 
the full committee, the library and ABI impact needs to be studied further.
</p>




<hr>
<h3><a name="170"></a>170. 
N4340 Remove Deprecated Use of the register Keyword 
</h3>
<p><b>Section:</b> 2.12 [lex.key] <b>Status:</b> <a href="ewg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2014-11-26 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4340.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4340.html</a>
</p>
<p>
Discussed in Lenexa. EWG supported making the use of register invalid but
keeping it as a reserved word. The author is to go to Core
with wording.
</p>




<hr>
<h3><a name="172"></a>172. 
N4358 Unary Folds and Empty Parameter Packs 
</h3>
<p><b>Section:</b> 5.1.3 [expr.prim.fold] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Thibaut Le Jehan <b>Opened:</b> 2015-01-20 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4358.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4358.pdf</a>
</p>
<p>
Discussed in Lenexa. EWG was interested in fixing some parts of the problem,
but didn't agree to the paper as presented. The author is encouraged to
talk to the authors of the fold expression design (Sutton, Smith) and
revise.
</p>




<hr>
<h3><a name="173"></a>173. 
N4360 Delayed Evaluation Parameters
</h3>
<p><b>Section:</b> 8.3.5 [dcl.fct] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Douglas Boffey <b>Opened:</b> 2015-01-22 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#dcl.fct">active issues</a> in [dcl.fct].</p>
<p><b>View all other</b> <a href="ewg-index.html#dcl.fct">issues</a> in [dcl.fct].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4360.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4360.pdf</a>
</p>
<p>
Discussed in Lenexa. Summary of straw polls:
</p>
<p>
Straw poll: Are you intrigued by a notion of delayed parameter evaluation?
</p>
<p>
SF: 6 F: 7 N: 2 A: 3 SA: 1
</p>
<p>
Straw poll: Annotation at the call site?
</p>
<p>
SF: 1 F: 0 N: 9 A: 0 SA: 7
</p>
<p>
Straw poll: Pass by lambda rather than evaluate on first use?
</p>
<p>
SF: 5 F: 4 N: 5 A: 0 SA: 3 
</p>
<p>
EWG expressed interest in the idea, but various people were very concerned
about the impact of such a facility, voicing caution that it is not just
syntactic sugar but rather something much more significant, and suggested
that a much more comprehensive analysis paper should be produced.
</p>




<hr>
<h3><a name="174"></a>174. 
N4367 Comparison in C++ 
</h3>
<p><b>Section:</b> 5.9 [expr.rel] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2015-02-08 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all other</b> <a href="ewg-index.html#expr.rel">issues</a> in [expr.rel].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4367.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4367.html</a>
</p>
<p>
Discussed in Lenexa. EWG didn't think this approach should block the
generated operators proposal (see <a href="ewg-active.html#116">116</a>), and thought that
the library parts look interesting. The author is encouraged to continue
progress on the library parts.
</p>




<hr>
<h3><a name="175"></a>175. 
[tiny] pointer to void as template non-type parameter
</h3>
<p><b>Section:</b> 14.1 [temp.param] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> RS <b>Opened:</b> 2014-10-11 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#temp.param">active issues</a> in [temp.param].</p>
<p><b>View all other</b> <a href="ewg-index.html#temp.param">issues</a> in [temp.param].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to 14.1 [temp.param] paragraph 4,
</p>
<p>
<blockquote>
<pre>
A non-type template-parameter shall have one of the following (optionally
cv-qualified) types:
- integral or enumeration type,
- pointer to object or pointer to function,
- lvalue reference to object or lvalue reference to function,
- pointer to member,
- std::nullptr_t.
</pre>
</blockquote>
</p>
<p>
Since void* isn't a pointer-to-object type, this prohibits using them as
template non-type parameters, which disallows constructs like
</p>
<code>
<blockquote>
     template&lt;typename T, std::enable_if_t&lt;std::is_array&lt;T&gt;::value&gt;* =
nullptr>
     void foo(T&amp;) {}
</blockquote>
</code>
<p>
(Though the above does compile in Clang, GCC, and MSVC with no warnings.)
</p>
<p>
There doesn't seem to be a good reason for this prohibition. While a void*
template parameter can only have a single value (the null pointer),
the same is true for a non-type parameter of type std::nullptr_t, which is
allowed.
</p>

<p><b>Wording available:</b></p>
<p>
Change the second bullet point of 14.1 [temp.param] paragraph 4 as
indicated:
</p>
<p>
<blockquote>
- <del>pointer to object or pointer to function</del><ins>object pointer or
function pointer</ins>,
</blockquote>
</p>
<p>
Change the second bullet point of 14.3.2 [temp.arg.nontype] paragraph 5 as
indicated:
</p>
<p>
<blockquote>
- for a non-type template-parameter of <del>type pointer to
object</del><ins>object pointer type</ins>, qualification conversions...
</blockquote>
</p>




<hr>
<h3><a name="177"></a>177. 
[tiny] LWG 2432
</h3>
<p><b>Section:</b> 18.9 [support.initlist] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> David Krauss <b>Opened:</b> 2014-09-30 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#support.initlist">active issues</a> in [support.initlist].</p>
<p><b>View all other</b> <a href="ewg-index.html#support.initlist">issues</a> in [support.initlist].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://cplusplus.github.io/LWG/lwg-toc.html#2432">LWG 2432</a>.
</p>




<hr>
<h3><a name="180"></a>180. 
N4429 Core issue 1941 - rewording inherited constructors 
</h3>
<p><b>Section:</b> 7.3.3 [namespace.udecl] <b>Status:</b> <a href="ewg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2015-04-10 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4429.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4429.html</a>
</p>
<p>
Discussed in Lenexa. The paper was accepted, the author is to take the wording
to CWG.
</p>




<hr>
<h3><a name="181"></a>181. 
N4433 Flexible static_assert messages 
</h3>
<p><b>Section:</b> 7 [dcl.dcl] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Michael Price <b>Opened:</b> 2015-04-09 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all other</b> <a href="ewg-index.html#dcl.dcl">issues</a> in [dcl.dcl].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4433.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4433.html</a>
</p>
<p>
Discussed in Lenexa. EWG expressed interest in the paper, but thought
that it might benefit from other facilities that are currently considered,
including reflection facilities. The author is encouraged to continue
working on the problem.
</p>




<hr>
<h3><a name="182"></a>182. 
N4434 Tweaks to Streamline Concepts Lite Syntax, other Concepts TS issues
</h3>
<p><b>Section:</b> X [concepts] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2015-04-10 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4434.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4434.pdf</a>
</p>
<p>
FI 14: 
</p>
<p>
It seems unfortunate that concepts cannot be declared as members of class 
templates. This seemingly makes it impossible to define concepts for 
constraining multiple template parameter packs (if concepts as static member 
functions were possible, one could provide e.g. two packs so that the class 
template gets the first pack and the member function template gets the second. 
That can't be done with a namespace-scope concept because multiple packs in 
function templates require deduction, and concepts don't take arguments that 
could be deduced.). As an example, practical needs for such constraining arise 
in standard library implementations, when constraining the variadic converting 
constructors of std::tuple.
</p>
<p>
US 13:
</p>
<p>
The following requirement seems overly restrictive, as it can be fairly 
easily (but tediously) be worked around:  
<blockquote>
A requires-expression shall appear only within a concept definition (7.1.7), 
or within the requires-clause of a template-declaration (Clause 14) or 
function declaration (8.3.5).
</blockquote> 
(The tedious workaround for each concept C is to define an overload set 
consisting of two function templates, one unconstrained and returning 
false, the other constrained by C and returning true.
</p>
<p>
US 15/16:
</p>
<p>
We believe that (generally speaking) the non-throwing of 
exceptions is a part of the runtime 
contract of a function, not
something that should 
be advertised in the type system outside a few 
very specific cases related to move operations.  
As a 'requires' expression is always free to invoke 
the 'noexcept' operator to
produce a predicate, 
we believe that is sufficient support for exception 
constraints in the language, and directly 
supporting this additional term in the grammar 
would be harmful, encouraging compile-time 
contracts taking away an important library 
implementer freedom.  As the TS is intended to 
provide feedback, we believe it would be better to
proceed without this, and see how much demand 
arises from using the alternate form, and whether 
that alternate form alone is too cumbersome for 
real world use.
</p>
<p>
If we retain exception constraints, the optional 
noexcept specifier should support the full range of 
the noexcept grammar.
</p>
<p>
US 24:
</p>
<p>
The syntactic 
distinction between a function 
concept and a variable concept seems to serve 
no useful purpose.  A single concept syntax 
seems sufficient, and especially so once 
redundant elements are removed.
</p>
<p>
US 36:
</p>
<p>
This paragraph introduces implicit conversion constraints to specify (via the 
trailing-return-type notation -> )
that a constraint is satisfied iff an expression E
is convertible to a type T.  It would 
be very useful to have similar constraints that are 
satisfied iff decltype(E) is exactly the type T. 
</p>
<p>
Discussed in Lenexa. There was interest in going forward with
the design of Concepts as-is, and open EWG issues for various comments
for future discussion. This issue tracks those comments/issues.
</p>




<hr>
<h3><a name="185"></a>185. 
N4462 	LWG 2089, Towards more perfect forwarding
</h3>
<p><b>Section:</b> 20.6.9.1 [allocator.members] <b>Status:</b> <a href="ewg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2015-04-07 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://cplusplus.github.io/LWG/lwg-toc.html#2089">LWG 2089</a>.
</p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4462.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4462.html</a>
</p>
<p>
Discussed in Lenexa. EWG didn't see any need for a language change, and
considered the library approach to be ok. Jonathan Wakely is writing an LWG
proposal to resolve the library issue.
</p>




<hr>
<h3><a name="187"></a>187. 
N4473 noexcept(auto), again
</h3>
<p><b>Section:</b> 15.4 [except.spec] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2015-04-10 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all other</b> <a href="ewg-index.html#except.spec">issues</a> in [except.spec].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4473.html">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4473.html</a>
</p>
<p>
Discussed in Lenexa. EWG's guidance was to modify the original wording
by Merrill so that it would talk about potentially-evaluated full-expressions
rather than unevaluated contexts. The author is encouraged to revise and
come back.
</p>




<hr>
<h3><a name="188"></a>188. 
LEWG Bug 95 - std::decay_copy(), suggestion to support an "auto cast".
</h3>
<p><b>Section:</b> 4 [conv] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Zhihao Yuan <b>Opened:</b> 2015-04-30 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="ewg-index-open.html#conv">active issues</a> in [conv].</p>
<p><b>View all other</b> <a href="ewg-index.html#conv">issues</a> in [conv].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="https://issues.isocpp.org/show_bug.cgi?id=95#c1">LEWG bug 95</a>.
</p>
<p>
<blockquote>
Or consider a language feature for that?
<pre>
    <code>  auto(y)  // cast to itself</code>
</pre>
</blockquote>
</p>




<hr>
<h3><a name="189"></a>189. 
Unions with differing access control are not standard layout
</h3>
<p><b>Section:</b> 9 [class] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Michael Reilly <b>Opened:</b> 2015-05-21 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all other</b> <a href="ewg-index.html#class">issues</a> in [class].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Proposes to allow unions with non-static data members of differing
access control to be considered a standard-layout union, provided they
meet the other criteria of such.
</p>
<p>
The project that motivated this defect report is located here:
</p>
<p>
<a href="http://preshing.com/20150324/safe-bitfields-in-cpp/">http://preshing.com/20150324/safe-bitfields-in-cpp/</a>
</p>
<p>
<a href="https://github.com/preshing/cpp11-on-multicore/blob/master/common/bitfield.h">https://github.com/preshing/cpp11-on-multicore/blob/master/common/bitfield.h</a>
</p>
<p>
Originally, the union had both public and private members. This caused
the union to be not standard-layout, which in turn caused the program
to technically have undefined behavior.
</p>
<p>
I argue that this defect is important to address because there seems
to be only one guarantee about the behavior of unions when accessing
the "wrong" member, and this guarantee only applies to standard-layout
unions.  So if the definition of a standard-layout union is too strict
then it can cause undefined behavior in places where it strictly does
not need to be.
</p>




</body>
</html>
