<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>C++ Standard Library 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">N4117</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2014-07-08</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">Alisdair Meredith &lt;<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>&gt;</td>
</tr>
</table>
<h1>C++ Standard Library Active Issues List (Revision R89)</h1>
<p><p>Revised 2014-07-08 at 16:07:00 UTC</p>
</p>
  <p>Reference ISO/IEC IS 14882:2011(E)</p>
  <p>Also see:</p>
  <ul>
      <li><a href="lwg-toc.html">Table of Contents</a> for all library issues.</li>
      <li><a href="lwg-index.html">Index by Section</a> for all library issues.</li>
      <li><a href="lwg-status.html">Index by Status</a> for all library issues.</li>
      <li><a href="lwg-defects.html">Library Defect Reports List</a></li>
      <li><a href="lwg-closed.html">Library Closed Issues List</a></li>
  </ul>
  <p>The purpose of this document is to record the status of issues
  which have come before the Library Working Group (LWG) of the INCITS PL22.16
  and ISO WG21 C++ Standards Committee. Issues represent
  potential defects in the ISO/IEC IS 14882:2011(E) document.  
  </p>

  <p>This document contains only library issues which are actively being
  considered by the Library Working Group, i.e., issues which have a
  status of <a href="lwg-active.html#New">New</a>, <a href="lwg-active.html#Open">Open</a>, 
  <a href="lwg-active.html#Ready">Ready</a>, or <a href="lwg-active.html#Review">Review</a>. See
  <a href="lwg-defects.html">Library Defect Reports List</a> for issues considered defects and 
  <a href="lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</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>Prior to Revision 14, library issues lists existed in two slightly
  different versions; a Committee Version and a Public
  Version. Beginning with Revision 14 the two versions were combined
  into a single version.</p>

  <p>This document includes <i>[bracketed italicized notes]</i> as a
  reminder to the LWG 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 LWG 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:2011(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>R89: 2014-07-08 post-Rapperswil mailing<ul>
<li><b>Summary:</b><ul>
<li>196 open issues, up by 14.</li>
<li>1742 closed issues, up by 12.</li>
<li>1938 issues total, up by 26.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 6 Ready issues: <a href="lwg-active.html#2396">2396</a>, <a href="lwg-active.html#2399">2399</a>, <a href="lwg-active.html#2400">2400</a>, <a href="lwg-active.html#2401">2401</a>, <a href="lwg-active.html#2404">2404</a>, <a href="lwg-active.html#2408">2408</a>.</li>
<li>Added the following 15 New issues: <a href="lwg-active.html#2391">2391</a>, <a href="lwg-active.html#2392">2392</a>, <a href="lwg-active.html#2393">2393</a>, <a href="lwg-active.html#2394">2394</a>, <a href="lwg-active.html#2398">2398</a>, <a href="lwg-active.html#2402">2402</a>, <a href="lwg-active.html#2403">2403</a>, <a href="lwg-active.html#2406">2406</a>, <a href="lwg-active.html#2407">2407</a>, <a href="lwg-active.html#2410">2410</a>, <a href="lwg-active.html#2411">2411</a>, <a href="lwg-active.html#2412">2412</a>, <a href="lwg-active.html#2413">2413</a>, <a href="lwg-active.html#2414">2414</a>, <a href="lwg-active.html#2415">2415</a>.</li>
<li>Added the following Open issue: <a href="lwg-active.html#2397">2397</a>.</li>
<li>Added the following 3 WP issues: <a href="lwg-defects.html#2390">2390</a>, <a href="lwg-defects.html#2395">2395</a>, <a href="lwg-defects.html#2409">2409</a>.</li>
<li>Added the following NAD issue: <a href="lwg-closed.html#2405">2405</a>.</li>
<li>Changed the following issue to Ready (from New): <a href="lwg-active.html#2377">2377</a>.</li>
<li>Changed the following 2 issues to Ready (from Deferred): <a href="lwg-active.html#2253">2253</a>, <a href="lwg-active.html#2255">2255</a>.</li>
<li>Changed the following 2 issues to Tentatively Ready (from New): <a href="lwg-active.html#2325">2325</a>, <a href="lwg-active.html#2387">2387</a>.</li>
<li>Changed the following issue to Tentatively NAD (from New): <a href="lwg-active.html#2382">2382</a>.</li>
<li>Changed the following 3 issues to Review (from New): <a href="lwg-active.html#2364">2364</a>, <a href="lwg-active.html#2378">2378</a>, <a href="lwg-active.html#2380">2380</a>.</li>
<li>Changed the following 2 issues to Review (from Open): <a href="lwg-active.html#2118">2118</a>, <a href="lwg-active.html#2160">2160</a>.</li>
<li>Changed the following 3 issues to Open (from New): <a href="lwg-active.html#2168">2168</a>, <a href="lwg-active.html#2238">2238</a>, <a href="lwg-active.html#2273">2273</a>.</li>
<li>Changed the following 3 issues to Open (from Deferred): <a href="lwg-active.html#2254">2254</a>, <a href="lwg-active.html#2264">2264</a>, <a href="lwg-active.html#2277">2277</a>.</li>
<li>Changed the following 3 issues to WP (from New): <a href="lwg-defects.html#2371">2371</a>, <a href="lwg-defects.html#2374">2374</a>, <a href="lwg-defects.html#2389">2389</a>.</li>
<li>Changed the following 4 issues to Resolved (from Deferred): <a href="lwg-defects.html#2282">2282</a>, <a href="lwg-defects.html#2283">2283</a>, <a href="lwg-defects.html#2287">2287</a>, <a href="lwg-defects.html#2333">2333</a>.</li>
<li>Changed the following issue to NAD (from Deferred): <a href="lwg-closed.html#2305">2305</a>.</li>
</ul></li>
</ul>
</li>
<li>R88: 
2014-05-24 pre-Rapperswil mailing
<ul>
<li><b>Summary:</b><ul>
<li>182 open issues, up by 29.</li>
<li>1730 closed issues, up by 0.</li>
<li>1912 issues total, up by 29.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 3 Tentatively Ready issues: <a href="lwg-active.html#2361">2361</a>, <a href="lwg-active.html#2365">2365</a>, <a href="lwg-active.html#2376">2376</a>.</li>
<li>Added the following 26 New issues: <a href="lwg-active.html#2362">2362</a>, <a href="lwg-active.html#2363">2363</a>, <a href="lwg-active.html#2364">2364</a>, <a href="lwg-active.html#2366">2366</a>, <a href="lwg-active.html#2367">2367</a>, <a href="lwg-active.html#2368">2368</a>, <a href="lwg-active.html#2369">2369</a>, <a href="lwg-active.html#2370">2370</a>, <a href="lwg-active.html#2371">2371</a>, <a href="lwg-active.html#2372">2372</a>, <a href="lwg-active.html#2373">2373</a>, <a href="lwg-active.html#2374">2374</a>, <a href="lwg-active.html#2375">2375</a>, <a href="lwg-active.html#2377">2377</a>, <a href="lwg-active.html#2378">2378</a>, <a href="lwg-active.html#2379">2379</a>, <a href="lwg-active.html#2380">2380</a>, <a href="lwg-active.html#2381">2381</a>, <a href="lwg-active.html#2382">2382</a>, <a href="lwg-active.html#2383">2383</a>, <a href="lwg-active.html#2384">2384</a>, <a href="lwg-active.html#2385">2385</a>, <a href="lwg-active.html#2386">2386</a>, <a href="lwg-active.html#2387">2387</a>, <a href="lwg-active.html#2388">2388</a>, <a href="lwg-active.html#2389">2389</a>.</li>
<li>Changed the following 5 issues to Tentatively Ready (from Open): <a href="lwg-active.html#2106">2106</a>, <a href="lwg-active.html#2129">2129</a>, <a href="lwg-active.html#2212">2212</a>, <a href="lwg-active.html#2230">2230</a>, <a href="lwg-active.html#2233">2233</a>.</li>
</ul></li>
</ul>
</li>
<li>R87: 
2014-03-03 post-Issaquah mailing
<ul>
<li><b>Summary:</b><ul>
<li>153 open issues, down by 60.</li>
<li>1730 closed issues, up by 65.</li>
<li>1883 issues total, up by 5.</li>
</ul></li>
<li><b>Details:</b>
<ul>
<li>Added the following New issue: <a href="lwg-active.html#2358">2358</a>.</li>
<li>Added the following 4 C++14 issues: <a href="lwg-defects.html#2356">2356</a>, <a href="lwg-defects.html#2357">2357</a>, <a href="lwg-defects.html#2359">2359</a>, <a href="lwg-defects.html#2360">2360</a>.</li>
<li>Changed the following issue to Ready (from Review): <a href="lwg-active.html#2170">2170</a>.</li>
<li>Changed the following 3 issues to Ready (from New): <a href="lwg-active.html#2319">2319</a>, <a href="lwg-active.html#2340">2340</a>, <a href="lwg-active.html#2354">2354</a>.</li>
<li>Changed the following issue to Ready (from Open): <a href="lwg-active.html#2016">2016</a>.</li>
<li>Changed the following 2 issues to Tentatively Ready (from New): <a href="lwg-active.html#2217">2217</a>, <a href="lwg-active.html#2266">2266</a>.</li>
<li>Changed the following issue to Tentatively NAD (from New): <a href="lwg-active.html#2302">2302</a>.</li>
<li>Changed the following issue to Review (from Open): <a href="lwg-active.html#2111">2111</a>.</li>
<li>Changed the following issue to New (from Open): <a href="lwg-active.html#2117">2117</a>.</li>
<li>Changed the following 4 issues to Open (from New): <a href="lwg-active.html#2241">2241</a>, <a href="lwg-active.html#2321">2321</a>, <a href="lwg-active.html#2328">2328</a>, <a href="lwg-active.html#2331">2331</a>.</li>
<li>Changed the following 5 issues to Open (from Deferred): <a href="lwg-active.html#1213">1213</a>, <a href="lwg-active.html#2095">2095</a>, <a href="lwg-active.html#2139">2139</a>, <a href="lwg-active.html#2202">2202</a>, <a href="lwg-active.html#2230">2230</a>.</li>
<li>Changed the following 3 issues to Pending NAD Editorial (from Tentatively NAD Editorial): <a href="lwg-closed.html#2125">2125</a>, <a href="lwg-closed.html#2126">2126</a>, <a href="lwg-closed.html#2134">2134</a>.</li>
<li>Changed the following 11 issues to C++14 (from Ready): <a href="lwg-defects.html#2135">2135</a>, <a href="lwg-defects.html#2142">2142</a>, <a href="lwg-defects.html#2252">2252</a>, <a href="lwg-defects.html#2257">2257</a>, <a href="lwg-defects.html#2268">2268</a>, <a href="lwg-defects.html#2271">2271</a>, <a href="lwg-defects.html#2272">2272</a>, <a href="lwg-defects.html#2278">2278</a>, <a href="lwg-defects.html#2280">2280</a>, <a href="lwg-defects.html#2285">2285</a>, <a href="lwg-defects.html#2291">2291</a>.</li>
<li>Changed the following 3 issues to C++14 (from Review): <a href="lwg-defects.html#2132">2132</a>, <a href="lwg-defects.html#2182">2182</a>, <a href="lwg-defects.html#2299">2299</a>.</li>
<li>Changed the following 28 issues to C++14 (from New): <a href="lwg-defects.html#2104">2104</a>, <a href="lwg-defects.html#2205">2205</a>, <a href="lwg-defects.html#2213">2213</a>, <a href="lwg-defects.html#2258">2258</a>, <a href="lwg-defects.html#2263">2263</a>, <a href="lwg-defects.html#2288">2288</a>, <a href="lwg-defects.html#2293">2293</a>, <a href="lwg-defects.html#2301">2301</a>, <a href="lwg-defects.html#2304">2304</a>, <a href="lwg-defects.html#2306">2306</a>, <a href="lwg-defects.html#2308">2308</a>, <a href="lwg-defects.html#2313">2313</a>, <a href="lwg-defects.html#2314">2314</a>, <a href="lwg-defects.html#2315">2315</a>, <a href="lwg-defects.html#2316">2316</a>, <a href="lwg-defects.html#2317">2317</a>, <a href="lwg-defects.html#2320">2320</a>, <a href="lwg-defects.html#2322">2322</a>, <a href="lwg-defects.html#2323">2323</a>, <a href="lwg-defects.html#2324">2324</a>, <a href="lwg-defects.html#2329">2329</a>, <a href="lwg-defects.html#2330">2330</a>, <a href="lwg-defects.html#2332">2332</a>, <a href="lwg-defects.html#2339">2339</a>, <a href="lwg-defects.html#2341">2341</a>, <a href="lwg-defects.html#2344">2344</a>, <a href="lwg-defects.html#2346">2346</a>, <a href="lwg-defects.html#2350">2350</a>.</li>
<li>Changed the following 5 issues to C++14 (from Open): <a href="lwg-defects.html#1450">1450</a>, <a href="lwg-defects.html#2003">2003</a>, <a href="lwg-defects.html#2112">2112</a>, <a href="lwg-defects.html#2186">2186</a>, <a href="lwg-defects.html#2188">2188</a>.</li>
<li>Changed the following issue to C++14 (from EWG): <a href="lwg-defects.html#2193">2193</a>.</li>
<li>Changed the following 97 issues to C++14 (from WP): <a href="lwg-defects.html#1214">1214</a>, <a href="lwg-defects.html#2005">2005</a>, <a href="lwg-defects.html#2009">2009</a>, <a href="lwg-defects.html#2010">2010</a>, <a href="lwg-defects.html#2011">2011</a>, <a href="lwg-defects.html#2013">2013</a>, <a href="lwg-defects.html#2015">2015</a>, <a href="lwg-defects.html#2018">2018</a>, <a href="lwg-defects.html#2021">2021</a>, <a href="lwg-defects.html#2028">2028</a>, <a href="lwg-defects.html#2033">2033</a>, <a href="lwg-defects.html#2039">2039</a>, <a href="lwg-defects.html#2044">2044</a>, <a href="lwg-defects.html#2045">2045</a>, <a href="lwg-defects.html#2047">2047</a>, <a href="lwg-defects.html#2048">2048</a>, <a href="lwg-defects.html#2049">2049</a>, <a href="lwg-defects.html#2050">2050</a>, <a href="lwg-defects.html#2053">2053</a>, <a href="lwg-defects.html#2056">2056</a>, <a href="lwg-defects.html#2058">2058</a>, <a href="lwg-defects.html#2061">2061</a>, <a href="lwg-defects.html#2064">2064</a>, <a href="lwg-defects.html#2065">2065</a>, <a href="lwg-defects.html#2067">2067</a>, <a href="lwg-defects.html#2069">2069</a>, <a href="lwg-defects.html#2071">2071</a>, <a href="lwg-defects.html#2074">2074</a>, <a href="lwg-defects.html#2078">2078</a>, <a href="lwg-defects.html#2080">2080</a>, <a href="lwg-defects.html#2081">2081</a>, <a href="lwg-defects.html#2083">2083</a>, <a href="lwg-defects.html#2085">2085</a>, <a href="lwg-defects.html#2086">2086</a>, <a href="lwg-defects.html#2087">2087</a>, <a href="lwg-defects.html#2091">2091</a>, <a href="lwg-defects.html#2092">2092</a>, <a href="lwg-defects.html#2093">2093</a>, <a href="lwg-defects.html#2094">2094</a>, <a href="lwg-defects.html#2096">2096</a>, <a href="lwg-defects.html#2097">2097</a>, <a href="lwg-defects.html#2098">2098</a>, <a href="lwg-defects.html#2099">2099</a>, <a href="lwg-defects.html#2100">2100</a>, <a href="lwg-defects.html#2102">2102</a>, <a href="lwg-defects.html#2103">2103</a>, <a href="lwg-defects.html#2105">2105</a>, <a href="lwg-defects.html#2109">2109</a>, <a href="lwg-defects.html#2110">2110</a>, <a href="lwg-defects.html#2120">2120</a>, <a href="lwg-defects.html#2122">2122</a>, <a href="lwg-defects.html#2123">2123</a>, <a href="lwg-defects.html#2128">2128</a>, <a href="lwg-defects.html#2130">2130</a>, <a href="lwg-defects.html#2138">2138</a>, <a href="lwg-defects.html#2140">2140</a>, <a href="lwg-defects.html#2141">2141</a>, <a href="lwg-defects.html#2143">2143</a>, <a href="lwg-defects.html#2144">2144</a>, <a href="lwg-defects.html#2145">2145</a>, <a href="lwg-defects.html#2147">2147</a>, <a href="lwg-defects.html#2148">2148</a>, <a href="lwg-defects.html#2149">2149</a>, <a href="lwg-defects.html#2150">2150</a>, <a href="lwg-defects.html#2159">2159</a>, <a href="lwg-defects.html#2162">2162</a>, <a href="lwg-defects.html#2163">2163</a>, <a href="lwg-defects.html#2169">2169</a>, <a href="lwg-defects.html#2172">2172</a>, <a href="lwg-defects.html#2174">2174</a>, <a href="lwg-defects.html#2175">2175</a>, <a href="lwg-defects.html#2176">2176</a>, <a href="lwg-defects.html#2177">2177</a>, <a href="lwg-defects.html#2180">2180</a>, <a href="lwg-defects.html#2185">2185</a>, <a href="lwg-defects.html#2187">2187</a>, <a href="lwg-defects.html#2190">2190</a>, <a href="lwg-defects.html#2194">2194</a>, <a href="lwg-defects.html#2196">2196</a>, <a href="lwg-defects.html#2197">2197</a>, <a href="lwg-defects.html#2200">2200</a>, <a href="lwg-defects.html#2203">2203</a>, <a href="lwg-defects.html#2207">2207</a>, <a href="lwg-defects.html#2209">2209</a>, <a href="lwg-defects.html#2210">2210</a>, <a href="lwg-defects.html#2211">2211</a>, <a href="lwg-defects.html#2222">2222</a>, <a href="lwg-defects.html#2225">2225</a>, <a href="lwg-defects.html#2229">2229</a>, <a href="lwg-defects.html#2231">2231</a>, <a href="lwg-defects.html#2235">2235</a>, <a href="lwg-defects.html#2246">2246</a>, <a href="lwg-defects.html#2247">2247</a>, <a href="lwg-defects.html#2275">2275</a>, <a href="lwg-defects.html#2284">2284</a>, <a href="lwg-defects.html#2298">2298</a>, <a href="lwg-defects.html#2300">2300</a>.</li>
<li>Changed the following issue to Resolved (from Ready): <a href="lwg-defects.html#2240">2240</a>.</li>
<li>Changed the following 2 issues to Resolved (from Open): <a href="lwg-defects.html#2052">2052</a>, <a href="lwg-defects.html#2075">2075</a>.</li>
<li>Changed the following issue to NAD Editorial (from Pending NAD Editorial): <a href="lwg-closed.html#2281">2281</a>.</li>
<li>Changed the following 2 issues to NAD (from Tentatively NAD): <a href="lwg-closed.html#2131">2131</a>, <a href="lwg-closed.html#2204">2204</a>.</li>
<li>Changed the following 5 issues to NAD (from New): <a href="lwg-closed.html#2311">2311</a>, <a href="lwg-closed.html#2327">2327</a>, <a href="lwg-closed.html#2345">2345</a>, <a href="lwg-closed.html#2347">2347</a>, <a href="lwg-closed.html#2355">2355</a>.</li>
<li>Changed the following issue to NAD (from Pending NAD): <a href="lwg-closed.html#2046">2046</a>.</li>
</ul>
</li></ul>
</li>
<li>R86: 
2014-01-20 pre-Issaquah mailing
<ul>
<li><b>Summary:</b><ul>
<li>213 open issues, up by 18.</li>
<li>1665 closed issues, up by 0.</li>
<li>1878 issues total, up by 18.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 18 New issues: <a href="lwg-active.html#2338">2338</a>, <a href="lwg-active.html#2339">2339</a>, <a href="lwg-active.html#2340">2340</a>, <a href="lwg-active.html#2341">2341</a>, <a href="lwg-active.html#2342">2342</a>, <a href="lwg-active.html#2343">2343</a>, <a href="lwg-active.html#2344">2344</a>, <a href="lwg-active.html#2345">2345</a>, <a href="lwg-active.html#2346">2346</a>, <a href="lwg-active.html#2347">2347</a>, <a href="lwg-active.html#2348">2348</a>, <a href="lwg-active.html#2349">2349</a>, <a href="lwg-active.html#2350">2350</a>, <a href="lwg-active.html#2351">2351</a>, <a href="lwg-active.html#2352">2352</a>, <a href="lwg-active.html#2353">2353</a>, <a href="lwg-active.html#2354">2354</a>, <a href="lwg-active.html#2355">2355</a>.</li>
<li>Changed the following 4 issues to Ready (from New): <a href="lwg-active.html#2268">2268</a>, <a href="lwg-active.html#2271">2271</a>, <a href="lwg-active.html#2280">2280</a>, <a href="lwg-active.html#2285">2285</a>.</li>
<li>Changed the following 5 issues to Open (from New): <a href="lwg-active.html#2192">2192</a>, <a href="lwg-active.html#2195">2195</a>, <a href="lwg-active.html#2260">2260</a>, <a href="lwg-active.html#2274">2274</a>, <a href="lwg-active.html#2294">2294</a>.</li>
<li>Changed the following 2 issues to Deferred (from New): <a href="lwg-active.html#2202">2202</a>, <a href="lwg-active.html#2230">2230</a>.</li>
</ul></li>
</ul>
</li>
<li>R85: 
2013-10 post-Chicago mailing
<ul>
<li><b>Summary:</b><ul>
<li>195 open issues, up by 22.</li>
<li>1665 closed issues, up by 28.</li>
<li>1860 issues total, up by 50.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following Ready issue: <a href="lwg-active.html#2291">2291</a>.</li>
<li>Added the following Review issue: <a href="lwg-active.html#2299">2299</a>.</li>
<li>Added the following 43 New issues: <a href="lwg-active.html#2288">2288</a>, <a href="lwg-active.html#2289">2289</a>, <a href="lwg-active.html#2290">2290</a>, <a href="lwg-active.html#2292">2292</a>, <a href="lwg-active.html#2293">2293</a>, <a href="lwg-active.html#2294">2294</a>, <a href="lwg-active.html#2295">2295</a>, <a href="lwg-active.html#2296">2296</a>, <a href="lwg-active.html#2301">2301</a>, <a href="lwg-active.html#2302">2302</a>, <a href="lwg-active.html#2303">2303</a>, <a href="lwg-active.html#2304">2304</a>, <a href="lwg-active.html#2306">2306</a>, <a href="lwg-active.html#2307">2307</a>, <a href="lwg-active.html#2308">2308</a>, <a href="lwg-active.html#2309">2309</a>, <a href="lwg-active.html#2310">2310</a>, <a href="lwg-active.html#2311">2311</a>, <a href="lwg-active.html#2312">2312</a>, <a href="lwg-active.html#2313">2313</a>, <a href="lwg-active.html#2314">2314</a>, <a href="lwg-active.html#2315">2315</a>, <a href="lwg-active.html#2316">2316</a>, <a href="lwg-active.html#2317">2317</a>, <a href="lwg-active.html#2318">2318</a>, <a href="lwg-active.html#2319">2319</a>, <a href="lwg-active.html#2320">2320</a>, <a href="lwg-active.html#2321">2321</a>, <a href="lwg-active.html#2322">2322</a>, <a href="lwg-active.html#2323">2323</a>, <a href="lwg-active.html#2324">2324</a>, <a href="lwg-active.html#2325">2325</a>, <a href="lwg-active.html#2326">2326</a>, <a href="lwg-active.html#2327">2327</a>, <a href="lwg-active.html#2328">2328</a>, <a href="lwg-active.html#2329">2329</a>, <a href="lwg-active.html#2330">2330</a>, <a href="lwg-active.html#2331">2331</a>, <a href="lwg-active.html#2332">2332</a>, <a href="lwg-active.html#2334">2334</a>, <a href="lwg-active.html#2335">2335</a>, <a href="lwg-active.html#2336">2336</a>, <a href="lwg-active.html#2337">2337</a>.</li>
<li>Added the following 2 Deferred issues: <a href="lwg-active.html#2305">2305</a>, <a href="lwg-active.html#2333">2333</a>.</li>
<li>Added the following 2 WP issues: <a href="lwg-defects.html#2298">2298</a>, <a href="lwg-defects.html#2300">2300</a>.</li>
<li>Added the following NAD issue: <a href="lwg-closed.html#2297">2297</a>.</li>
<li>Changed the following 5 issues to Ready (from New): <a href="lwg-active.html#2240">2240</a>, <a href="lwg-active.html#2252">2252</a>, <a href="lwg-active.html#2257">2257</a>, <a href="lwg-active.html#2272">2272</a>, <a href="lwg-active.html#2278">2278</a>.</li>
<li>Changed the following 2 issues to Ready (from Open): <a href="lwg-active.html#2135">2135</a>, <a href="lwg-active.html#2142">2142</a>.</li>
<li>Changed the following issue to Review (from Core): <a href="lwg-active.html#2170">2170</a>.</li>
<li>Changed the following 9 issues to Deferred (from New): <a href="lwg-active.html#2095">2095</a>, <a href="lwg-active.html#2253">2253</a>, <a href="lwg-active.html#2254">2254</a>, <a href="lwg-active.html#2255">2255</a>, <a href="lwg-active.html#2264">2264</a>, <a href="lwg-active.html#2277">2277</a>, <a href="lwg-active.html#2282">2282</a>, <a href="lwg-active.html#2283">2283</a>, <a href="lwg-active.html#2287">2287</a>.</li>
<li>Changed the following issue to Pending NAD Editorial (from New): <a href="lwg-closed.html#2281">2281</a>.</li>
<li>Changed the following issue to NAD Future (from Open): <a href="lwg-closed.html#2232">2232</a>.</li>
<li>Changed the following 4 issues to WP (from Ready): <a href="lwg-defects.html#2141">2141</a>, <a href="lwg-defects.html#2235">2235</a>, <a href="lwg-defects.html#2246">2246</a>, <a href="lwg-defects.html#2247">2247</a>.</li>
<li>Changed the following 6 issues to WP (from Tentatively Ready): <a href="lwg-defects.html#2085">2085</a>, <a href="lwg-defects.html#2087">2087</a>, <a href="lwg-defects.html#2143">2143</a>, <a href="lwg-defects.html#2150">2150</a>, <a href="lwg-defects.html#2180">2180</a>, <a href="lwg-defects.html#2194">2194</a>.</li>
<li>Changed the following issue to WP (from Tentatively NAD Editorial): <a href="lwg-defects.html#2078">2078</a>.</li>
<li>Changed the following 3 issues to WP (from Review): <a href="lwg-defects.html#2013">2013</a>, <a href="lwg-defects.html#2100">2100</a>, <a href="lwg-defects.html#2120">2120</a>.</li>
<li>Changed the following 3 issues to WP (from New): <a href="lwg-defects.html#2097">2097</a>, <a href="lwg-defects.html#2275">2275</a>, <a href="lwg-defects.html#2284">2284</a>.</li>
<li>Changed the following 2 issues to WP (from Open): <a href="lwg-defects.html#2018">2018</a>, <a href="lwg-defects.html#2159">2159</a>.</li>
<li>Changed the following issue to Resolved (from New): <a href="lwg-defects.html#2249">2249</a>.</li>
<li>Changed the following issue to NAD (from Tentatively NAD): <a href="lwg-closed.html#2167">2167</a>.</li>
<li>Changed the following 2 issues to NAD (from New): <a href="lwg-closed.html#2270">2270</a>, <a href="lwg-closed.html#2279">2279</a>.</li>
</ul></li>
</ul>
</li>
<li>R84: 
2013-09 pre-Chicago mailing
<ul>
<li><b>Summary:</b><ul>
<li>173 open issues, up by 36.</li>
<li>1637 closed issues, up by 0.</li>
<li>1810 issues total, up by 36.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 36 New issues: <a href="lwg-active.html#2252">2252</a>, <a href="lwg-active.html#2253">2253</a>, <a href="lwg-active.html#2254">2254</a>, <a href="lwg-active.html#2255">2255</a>, <a href="lwg-active.html#2256">2256</a>, <a href="lwg-active.html#2257">2257</a>, <a href="lwg-active.html#2258">2258</a>, <a href="lwg-active.html#2259">2259</a>, <a href="lwg-active.html#2260">2260</a>, <a href="lwg-active.html#2261">2261</a>, <a href="lwg-active.html#2262">2262</a>, <a href="lwg-active.html#2263">2263</a>, <a href="lwg-active.html#2264">2264</a>, <a href="lwg-active.html#2265">2265</a>, <a href="lwg-active.html#2266">2266</a>, <a href="lwg-active.html#2267">2267</a>, <a href="lwg-active.html#2268">2268</a>, <a href="lwg-active.html#2269">2269</a>, <a href="lwg-active.html#2270">2270</a>, <a href="lwg-active.html#2271">2271</a>, <a href="lwg-active.html#2272">2272</a>, <a href="lwg-active.html#2273">2273</a>, <a href="lwg-active.html#2274">2274</a>, <a href="lwg-active.html#2275">2275</a>, <a href="lwg-active.html#2276">2276</a>, <a href="lwg-active.html#2277">2277</a>, <a href="lwg-active.html#2278">2278</a>, <a href="lwg-active.html#2279">2279</a>, <a href="lwg-active.html#2280">2280</a>, <a href="lwg-active.html#2281">2281</a>, <a href="lwg-active.html#2282">2282</a>, <a href="lwg-active.html#2283">2283</a>, <a href="lwg-active.html#2284">2284</a>, <a href="lwg-active.html#2285">2285</a>, <a href="lwg-active.html#2286">2286</a>, <a href="lwg-active.html#2287">2287</a>.</li>
<li>Changed the following 6 issues to Tentatively Ready (from New): <a href="lwg-active.html#2085">2085</a>, <a href="lwg-active.html#2087">2087</a>, <a href="lwg-active.html#2143">2143</a>, <a href="lwg-active.html#2150">2150</a>, <a href="lwg-active.html#2180">2180</a>, <a href="lwg-active.html#2194">2194</a>.</li>
<li>Changed the following 2 issues to Tentatively NAD (from New): <a href="lwg-active.html#2131">2131</a>, <a href="lwg-active.html#2204">2204</a>.</li>
<li>Changed the following 3 issues to Open (from New): <a href="lwg-active.html#2181">2181</a>, <a href="lwg-active.html#2188">2188</a>, <a href="lwg-active.html#2214">2214</a>.</li>
</ul></li>
</ul>
</li>
<li>R83: 
2013-05 post-Bristol mailing
<ul>
<li><b>Summary:</b><ul>
<li>137 open issues, down by 37.</li>
<li>1637 closed issues, up by 40.</li>
<li>1774 issues total, up by 3.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 3 New issues: <a href="lwg-active.html#2249">2249</a>, <a href="lwg-active.html#2250">2250</a>, <a href="lwg-active.html#2251">2251</a>.</li>
<li>Changed the following 2 issues to Ready (from Review): <a href="lwg-active.html#2141">2141</a>, <a href="lwg-active.html#2235">2235</a>.</li>
<li>Changed the following 2 issues to Ready (from New): <a href="lwg-active.html#2246">2246</a>, <a href="lwg-active.html#2247">2247</a>.</li>
<li>Changed the following 3 issues to Open (from Review): <a href="lwg-active.html#2219">2219</a>, <a href="lwg-active.html#2223">2223</a>, <a href="lwg-active.html#2227">2227</a>.</li>
<li>Changed the following 8 issues to WP (from Ready): <a href="lwg-defects.html#2091">2091</a>, <a href="lwg-defects.html#2092">2092</a>, <a href="lwg-defects.html#2093">2093</a>, <a href="lwg-defects.html#2145">2145</a>, <a href="lwg-defects.html#2147">2147</a>, <a href="lwg-defects.html#2163">2163</a>, <a href="lwg-defects.html#2169">2169</a>, <a href="lwg-defects.html#2172">2172</a>.</li>
<li>Changed the following 14 issues to WP (from Tentatively Ready): <a href="lwg-defects.html#2080">2080</a>, <a href="lwg-defects.html#2109">2109</a>, <a href="lwg-defects.html#2144">2144</a>, <a href="lwg-defects.html#2174">2174</a>, <a href="lwg-defects.html#2175">2175</a>, <a href="lwg-defects.html#2177">2177</a>, <a href="lwg-defects.html#2187">2187</a>, <a href="lwg-defects.html#2197">2197</a>, <a href="lwg-defects.html#2200">2200</a>, <a href="lwg-defects.html#2209">2209</a>, <a href="lwg-defects.html#2211">2211</a>, <a href="lwg-defects.html#2222">2222</a>, <a href="lwg-defects.html#2225">2225</a>, <a href="lwg-defects.html#2231">2231</a>.</li>
<li>Changed the following 14 issues to WP (from Review): <a href="lwg-defects.html#2094">2094</a>, <a href="lwg-defects.html#2098">2098</a>, <a href="lwg-defects.html#2130">2130</a>, <a href="lwg-defects.html#2138">2138</a>, <a href="lwg-defects.html#2140">2140</a>, <a href="lwg-defects.html#2162">2162</a>, <a href="lwg-defects.html#2176">2176</a>, <a href="lwg-defects.html#2185">2185</a>, <a href="lwg-defects.html#2190">2190</a>, <a href="lwg-defects.html#2196">2196</a>, <a href="lwg-defects.html#2203">2203</a>, <a href="lwg-defects.html#2207">2207</a>, <a href="lwg-defects.html#2210">2210</a>, <a href="lwg-defects.html#2229">2229</a>.</li>
<li>Changed the following 4 issues to WP (from Open): <a href="lwg-defects.html#2122">2122</a>, <a href="lwg-defects.html#2128">2128</a>, <a href="lwg-defects.html#2148">2148</a>, <a href="lwg-defects.html#2149">2149</a>.</li>
</ul></li>
</ul>
</li>
<li>R82: 
2013-03 pre-Bristol mailing
<ul>
<li><b>Summary:</b><ul>
<li>174 open issues, up by 13.</li>
<li>1597 closed issues, up by 1.</li>
<li>1771 issues total, up by 14.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following Review issue: <a href="lwg-active.html#2235">2235</a>.</li>
<li>Added the following 13 New issues: <a href="lwg-active.html#2236">2236</a>, <a href="lwg-active.html#2237">2237</a>, <a href="lwg-active.html#2238">2238</a>, <a href="lwg-active.html#2239">2239</a>, <a href="lwg-active.html#2240">2240</a>, <a href="lwg-active.html#2241">2241</a>, <a href="lwg-active.html#2242">2242</a>, <a href="lwg-active.html#2243">2243</a>, <a href="lwg-active.html#2244">2244</a>, <a href="lwg-active.html#2245">2245</a>, <a href="lwg-active.html#2246">2246</a>, <a href="lwg-active.html#2247">2247</a>, <a href="lwg-active.html#2248">2248</a>.</li>
<li>Changed the following 10 issues to Tentatively Ready (from New): <a href="lwg-active.html#2144">2144</a>, <a href="lwg-active.html#2174">2174</a>, <a href="lwg-active.html#2175">2175</a>, <a href="lwg-active.html#2197">2197</a>, <a href="lwg-active.html#2200">2200</a>, <a href="lwg-active.html#2209">2209</a>, <a href="lwg-active.html#2211">2211</a>, <a href="lwg-active.html#2222">2222</a>, <a href="lwg-active.html#2225">2225</a>, <a href="lwg-active.html#2231">2231</a>.</li>
<li>Changed the following 11 issues to Review (from New): <a href="lwg-active.html#2141">2141</a>, <a href="lwg-active.html#2176">2176</a>, <a href="lwg-active.html#2182">2182</a>, <a href="lwg-active.html#2203">2203</a>, <a href="lwg-active.html#2207">2207</a>, <a href="lwg-active.html#2210">2210</a>, <a href="lwg-active.html#2219">2219</a>, <a href="lwg-active.html#2223">2223</a>, <a href="lwg-active.html#2227">2227</a>, <a href="lwg-active.html#2228">2228</a>, <a href="lwg-active.html#2229">2229</a>.</li>
<li>Changed the following 19 issues to Open (from New): <a href="lwg-active.html#2133">2133</a>, <a href="lwg-active.html#2146">2146</a>, <a href="lwg-active.html#2151">2151</a>, <a href="lwg-active.html#2153">2153</a>, <a href="lwg-active.html#2155">2155</a>, <a href="lwg-active.html#2156">2156</a>, <a href="lwg-active.html#2160">2160</a>, <a href="lwg-active.html#2179">2179</a>, <a href="lwg-active.html#2189">2189</a>, <a href="lwg-active.html#2198">2198</a>, <a href="lwg-active.html#2199">2199</a>, <a href="lwg-active.html#2206">2206</a>, <a href="lwg-active.html#2212">2212</a>, <a href="lwg-active.html#2215">2215</a>, <a href="lwg-active.html#2218">2218</a>, <a href="lwg-active.html#2224">2224</a>, <a href="lwg-active.html#2232">2232</a>, <a href="lwg-active.html#2233">2233</a>, <a href="lwg-active.html#2234">2234</a>.</li>
<li>Changed the following issue to NAD Future (from New): <a href="lwg-closed.html#2226">2226</a>.</li>
</ul></li>
</ul>
</li>
<li>R81: 
2013-01 mid-term mailing
<ul>
<li><b>Summary:</b><ul>
<li>161 open issues, up by 21.</li>
<li>1596 closed issues, up by 3.</li>
<li>1757 issues total, up by 24.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 24 New issues: <a href="lwg-active.html#2211">2211</a>, <a href="lwg-active.html#2212">2212</a>, <a href="lwg-active.html#2213">2213</a>, <a href="lwg-active.html#2214">2214</a>, <a href="lwg-active.html#2215">2215</a>, <a href="lwg-active.html#2216">2216</a>, <a href="lwg-active.html#2217">2217</a>, <a href="lwg-active.html#2218">2218</a>, <a href="lwg-active.html#2219">2219</a>, <a href="lwg-active.html#2220">2220</a>, <a href="lwg-active.html#2221">2221</a>, <a href="lwg-active.html#2222">2222</a>, <a href="lwg-active.html#2223">2223</a>, <a href="lwg-active.html#2224">2224</a>, <a href="lwg-active.html#2225">2225</a>, <a href="lwg-active.html#2226">2226</a>, <a href="lwg-active.html#2227">2227</a>, <a href="lwg-active.html#2228">2228</a>, <a href="lwg-active.html#2229">2229</a>, <a href="lwg-active.html#2230">2230</a>, <a href="lwg-active.html#2231">2231</a>, <a href="lwg-active.html#2232">2232</a>, <a href="lwg-active.html#2233">2233</a>, <a href="lwg-active.html#2234">2234</a>.</li>
<li>Changed the following issue to Open (from Tentatively Ready): <a href="lwg-active.html#2106">2106</a>.</li>
<li>Changed the following 3 issues to Resolved (from Open): <a href="lwg-defects.html#2012">2012</a>, <a href="lwg-defects.html#2054">2054</a>, <a href="lwg-defects.html#2057">2057</a>.</li>
</ul></li>
</ul>
</li>
<li>R80: 
2012-11-02 post-Portland mailing
<ul>
<li><b>Summary:</b><ul>
<li>140 open issues, up by 4.</li>
<li>1593 closed issues, up by 17.</li>
<li>1733 issues total, up by 21.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 2 Review issues: <a href="lwg-active.html#2190">2190</a>, <a href="lwg-active.html#2196">2196</a>.</li>
<li>Added the following 18 New issues: <a href="lwg-active.html#2191">2191</a>, <a href="lwg-active.html#2192">2192</a>, <a href="lwg-active.html#2194">2194</a>, <a href="lwg-active.html#2195">2195</a>, <a href="lwg-active.html#2197">2197</a>, <a href="lwg-active.html#2198">2198</a>, <a href="lwg-active.html#2199">2199</a>, <a href="lwg-active.html#2200">2200</a>, <a href="lwg-active.html#2201">2201</a>, <a href="lwg-active.html#2202">2202</a>, <a href="lwg-active.html#2203">2203</a>, <a href="lwg-active.html#2204">2204</a>, <a href="lwg-active.html#2205">2205</a>, <a href="lwg-active.html#2206">2206</a>, <a href="lwg-active.html#2207">2207</a>, <a href="lwg-active.html#2208">2208</a>, <a href="lwg-active.html#2209">2209</a>, <a href="lwg-active.html#2210">2210</a>.</li>
<li>Added the following EWG issue: <a href="lwg-active.html#2193">2193</a>.</li>
<li>Changed the following 3 issues to Ready (from Review): <a href="lwg-active.html#2091">2091</a>, <a href="lwg-active.html#2092">2092</a>, <a href="lwg-active.html#2093">2093</a>.</li>
<li>Changed the following 5 issues to Ready (from New): <a href="lwg-active.html#2145">2145</a>, <a href="lwg-active.html#2147">2147</a>, <a href="lwg-active.html#2163">2163</a>, <a href="lwg-active.html#2169">2169</a>, <a href="lwg-active.html#2172">2172</a>.</li>
<li>Changed the following 3 issues to Tentatively Ready (from Review): <a href="lwg-active.html#2080">2080</a>, <a href="lwg-active.html#2106">2106</a>, <a href="lwg-active.html#2109">2109</a>.</li>
<li>Changed the following 2 issues to Tentatively Ready (from New): <a href="lwg-active.html#2177">2177</a>, <a href="lwg-active.html#2187">2187</a>.</li>
<li>Changed the following 4 issues to Tentatively NAD Editorial (from New): <a href="lwg-active.html#2078">2078</a>, <a href="lwg-active.html#2125">2125</a>, <a href="lwg-active.html#2126">2126</a>, <a href="lwg-active.html#2134">2134</a>.</li>
<li>Changed the following issue to Tentatively NAD (from New): <a href="lwg-active.html#2167">2167</a>.</li>
<li>Changed the following 9 issues to Review (from New): <a href="lwg-active.html#2098">2098</a>, <a href="lwg-active.html#2100">2100</a>, <a href="lwg-active.html#2120">2120</a>, <a href="lwg-active.html#2130">2130</a>, <a href="lwg-active.html#2132">2132</a>, <a href="lwg-active.html#2138">2138</a>, <a href="lwg-active.html#2140">2140</a>, <a href="lwg-active.html#2162">2162</a>, <a href="lwg-active.html#2185">2185</a>.</li>
<li>Changed the following issue to Open (from Review): <a href="lwg-active.html#1175">1175</a>.</li>
<li>Changed the following 12 issues to Open (from New): <a href="lwg-active.html#2075">2075</a>, <a href="lwg-active.html#2135">2135</a>, <a href="lwg-active.html#2136">2136</a>, <a href="lwg-active.html#2137">2137</a>, <a href="lwg-active.html#2142">2142</a>, <a href="lwg-active.html#2148">2148</a>, <a href="lwg-active.html#2149">2149</a>, <a href="lwg-active.html#2152">2152</a>, <a href="lwg-active.html#2157">2157</a>, <a href="lwg-active.html#2159">2159</a>, <a href="lwg-active.html#2178">2178</a>, <a href="lwg-active.html#2186">2186</a>.</li>
<li>Changed the following issue to Open (from NAD Future): <a href="lwg-active.html#2051">2051</a>.</li>
<li>Changed the following 2 issues to Core (from New): <a href="lwg-active.html#2165">2165</a>, <a href="lwg-active.html#2170">2170</a>.</li>
<li>Changed the following issue to Deferred (from New): <a href="lwg-active.html#2139">2139</a>.</li>
<li>Changed the following 10 issues to WP (from Ready): <a href="lwg-defects.html#2071">2071</a>, <a href="lwg-defects.html#2074">2074</a>, <a href="lwg-defects.html#2081">2081</a>, <a href="lwg-defects.html#2083">2083</a>, <a href="lwg-defects.html#2086">2086</a>, <a href="lwg-defects.html#2099">2099</a>, <a href="lwg-defects.html#2103">2103</a>, <a href="lwg-defects.html#2105">2105</a>, <a href="lwg-defects.html#2110">2110</a>, <a href="lwg-defects.html#2123">2123</a>.</li>
<li>Changed the following 6 issues to WP (from Tentatively Ready): <a href="lwg-defects.html#2005">2005</a>, <a href="lwg-defects.html#2011">2011</a>, <a href="lwg-defects.html#2048">2048</a>, <a href="lwg-defects.html#2049">2049</a>, <a href="lwg-defects.html#2056">2056</a>, <a href="lwg-defects.html#2058">2058</a>.</li>
<li>Changed the following issue to NAD (from Tentatively NAD): <a href="lwg-closed.html#2124">2124</a>.</li>
<li>Changed the following issue to NAD (from New): <a href="lwg-closed.html#2171">2171</a>.</li>
</ul></li>
</ul>
</li>
<li>R79: 
2012-09-24 pre-Portland mailing
<ul>
<li><b>Summary:</b><ul>
<li>136 open issues, up by 60.</li>
<li>1576 closed issues, up by 0.</li>
<li>1712 issues total, up by 60.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 60 New issues: <a href="lwg-active.html#2130">2130</a>, <a href="lwg-active.html#2131">2131</a>, <a href="lwg-active.html#2132">2132</a>, <a href="lwg-active.html#2133">2133</a>, <a href="lwg-active.html#2134">2134</a>, <a href="lwg-active.html#2135">2135</a>, <a href="lwg-active.html#2136">2136</a>, <a href="lwg-active.html#2137">2137</a>, <a href="lwg-active.html#2138">2138</a>, <a href="lwg-active.html#2139">2139</a>, <a href="lwg-active.html#2140">2140</a>, <a href="lwg-active.html#2141">2141</a>, <a href="lwg-active.html#2142">2142</a>, <a href="lwg-active.html#2143">2143</a>, <a href="lwg-active.html#2144">2144</a>, <a href="lwg-active.html#2145">2145</a>, <a href="lwg-active.html#2146">2146</a>, <a href="lwg-active.html#2147">2147</a>, <a href="lwg-active.html#2148">2148</a>, <a href="lwg-active.html#2149">2149</a>, <a href="lwg-active.html#2150">2150</a>, <a href="lwg-active.html#2151">2151</a>, <a href="lwg-active.html#2152">2152</a>, <a href="lwg-active.html#2153">2153</a>, <a href="lwg-active.html#2154">2154</a>, <a href="lwg-active.html#2155">2155</a>, <a href="lwg-active.html#2156">2156</a>, <a href="lwg-active.html#2157">2157</a>, <a href="lwg-active.html#2158">2158</a>, <a href="lwg-active.html#2159">2159</a>, <a href="lwg-active.html#2160">2160</a>, <a href="lwg-active.html#2161">2161</a>, <a href="lwg-active.html#2162">2162</a>, <a href="lwg-active.html#2163">2163</a>, <a href="lwg-active.html#2164">2164</a>, <a href="lwg-active.html#2165">2165</a>, <a href="lwg-active.html#2166">2166</a>, <a href="lwg-active.html#2167">2167</a>, <a href="lwg-active.html#2168">2168</a>, <a href="lwg-active.html#2169">2169</a>, <a href="lwg-active.html#2170">2170</a>, <a href="lwg-active.html#2171">2171</a>, <a href="lwg-active.html#2172">2172</a>, <a href="lwg-active.html#2173">2173</a>, <a href="lwg-active.html#2174">2174</a>, <a href="lwg-active.html#2175">2175</a>, <a href="lwg-active.html#2176">2176</a>, <a href="lwg-active.html#2177">2177</a>, <a href="lwg-active.html#2178">2178</a>, <a href="lwg-active.html#2179">2179</a>, <a href="lwg-active.html#2180">2180</a>, <a href="lwg-active.html#2181">2181</a>, <a href="lwg-active.html#2182">2182</a>, <a href="lwg-active.html#2183">2183</a>, <a href="lwg-active.html#2184">2184</a>, <a href="lwg-active.html#2185">2185</a>, <a href="lwg-active.html#2186">2186</a>, <a href="lwg-active.html#2187">2187</a>, <a href="lwg-active.html#2188">2188</a>, <a href="lwg-active.html#2189">2189</a>.</li>
<li>No issues changed.</li>
</ul></li>
</ul>
</li>
<li>R78: 
2012-02-27 post-Kona mailing
<ul>
<li><b>Summary:</b><ul>
<li>76 open issues, down by 20.</li>
<li>1576 closed issues, up by 26.</li>
<li>1652 issues total, up by 6.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 2 New issues: <a href="lwg-active.html#2125">2125</a>, <a href="lwg-active.html#2126">2126</a>.</li>
<li>Added the following 3 Open issues: <a href="lwg-active.html#2127">2127</a>, <a href="lwg-active.html#2128">2128</a>, <a href="lwg-active.html#2129">2129</a>.</li>
<li>Added the following Tentatively NAD issue: <a href="lwg-active.html#2124">2124</a>.</li>
<li>Changed the following 5 issues from New to NAD: <a href="lwg-closed.html#2073">2073</a>, <a href="lwg-closed.html#2082">2082</a>, <a href="lwg-closed.html#2090">2090</a>, <a href="lwg-closed.html#2107">2107</a>, <a href="lwg-closed.html#2113">2113</a>.</li>
<li>Changed the following issue from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#2060">2060</a>.</li>
<li>Changed the following issue from Deferred to Open: <a href="lwg-active.html#1526">1526</a>.</li>
<li>Changed the following 15 issues from New to Open: <a href="lwg-active.html#2072">2072</a>, <a href="lwg-active.html#2077">2077</a>, <a href="lwg-active.html#2088">2088</a>, <a href="lwg-active.html#2089">2089</a>, <a href="lwg-active.html#2101">2101</a>, <a href="lwg-active.html#2108">2108</a>, <a href="lwg-active.html#2111">2111</a>, <a href="lwg-active.html#2112">2112</a>, <a href="lwg-active.html#2114">2114</a>, <a href="lwg-active.html#2115">2115</a>, <a href="lwg-active.html#2116">2116</a>, <a href="lwg-active.html#2117">2117</a>, <a href="lwg-active.html#2118">2118</a>, <a href="lwg-active.html#2119">2119</a>, <a href="lwg-active.html#2122">2122</a>.</li>
<li>Changed the following 2 issues from Review to Open: <a href="lwg-active.html#1169">1169</a>, <a href="lwg-active.html#2059">2059</a>.</li>
<li>Changed the following 10 issues from New to Ready: <a href="lwg-active.html#2071">2071</a>, <a href="lwg-active.html#2074">2074</a>, <a href="lwg-active.html#2081">2081</a>, <a href="lwg-active.html#2083">2083</a>, <a href="lwg-active.html#2086">2086</a>, <a href="lwg-active.html#2099">2099</a>, <a href="lwg-active.html#2103">2103</a>, <a href="lwg-active.html#2105">2105</a>, <a href="lwg-active.html#2110">2110</a>, <a href="lwg-active.html#2123">2123</a>.</li>
<li>Changed the following issue from Tentatively Resolved to Resolved: <a href="lwg-defects.html#2066">2066</a>.</li>
<li>Changed the following 7 issues from New to Review: <a href="lwg-active.html#2080">2080</a>, <a href="lwg-active.html#2091">2091</a>, <a href="lwg-active.html#2092">2092</a>, <a href="lwg-active.html#2093">2093</a>, <a href="lwg-active.html#2094">2094</a>, <a href="lwg-active.html#2106">2106</a>, <a href="lwg-active.html#2109">2109</a>.</li>
<li>Changed the following issue from Ready to Review: <a href="lwg-active.html#2013">2013</a>.</li>
<li>Changed the following 6 issues from Review to Tentatively Ready: <a href="lwg-active.html#2005">2005</a>, <a href="lwg-active.html#2011">2011</a>, <a href="lwg-active.html#2048">2048</a>, <a href="lwg-active.html#2049">2049</a>, <a href="lwg-active.html#2056">2056</a>, <a href="lwg-active.html#2058">2058</a>.</li>
<li>Changed the following 18 issues from Ready to WP: <a href="lwg-defects.html#1214">1214</a>, <a href="lwg-defects.html#2009">2009</a>, <a href="lwg-defects.html#2010">2010</a>, <a href="lwg-defects.html#2015">2015</a>, <a href="lwg-defects.html#2021">2021</a>, <a href="lwg-defects.html#2028">2028</a>, <a href="lwg-defects.html#2033">2033</a>, <a href="lwg-defects.html#2039">2039</a>, <a href="lwg-defects.html#2044">2044</a>, <a href="lwg-defects.html#2045">2045</a>, <a href="lwg-defects.html#2047">2047</a>, <a href="lwg-defects.html#2050">2050</a>, <a href="lwg-defects.html#2053">2053</a>, <a href="lwg-defects.html#2061">2061</a>, <a href="lwg-defects.html#2064">2064</a>, <a href="lwg-defects.html#2065">2065</a>, <a href="lwg-defects.html#2067">2067</a>, <a href="lwg-defects.html#2069">2069</a>.</li>
<li>Changed the following 2 issues from Tentatively Ready to WP: <a href="lwg-defects.html#2096">2096</a>, <a href="lwg-defects.html#2102">2102</a>.</li>
</ul></li>
</ul>
</li>
<li>R77: 
2012-01-16 pre-Kona mailing
<ul>
<li><b>Summary:</b><ul>
<li>96 open issues, up by 52.</li>
<li>1550 closed issues, up by 1.</li>
<li>1646 issues total, up by 53.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issue: <a href="lwg-closed.html#2084">2084</a>.</li>
<li>Added the following 50 New issues: <a href="lwg-active.html#2071">2071</a>, <a href="lwg-active.html#2072">2072</a>, <a href="lwg-active.html#2073">2073</a>, <a href="lwg-active.html#2074">2074</a>, <a href="lwg-active.html#2075">2075</a>, <a href="lwg-active.html#2076">2076</a>, <a href="lwg-active.html#2077">2077</a>, <a href="lwg-active.html#2078">2078</a>, <a href="lwg-active.html#2079">2079</a>, <a href="lwg-active.html#2080">2080</a>, <a href="lwg-active.html#2081">2081</a>, <a href="lwg-active.html#2082">2082</a>, <a href="lwg-active.html#2083">2083</a>, <a href="lwg-active.html#2085">2085</a>, <a href="lwg-active.html#2086">2086</a>, <a href="lwg-active.html#2087">2087</a>, <a href="lwg-active.html#2088">2088</a>, <a href="lwg-active.html#2089">2089</a>, <a href="lwg-active.html#2090">2090</a>, <a href="lwg-active.html#2091">2091</a>, <a href="lwg-active.html#2092">2092</a>, <a href="lwg-active.html#2093">2093</a>, <a href="lwg-active.html#2094">2094</a>, <a href="lwg-active.html#2095">2095</a>, <a href="lwg-active.html#2097">2097</a>, <a href="lwg-active.html#2098">2098</a>, <a href="lwg-active.html#2099">2099</a>, <a href="lwg-active.html#2100">2100</a>, <a href="lwg-active.html#2101">2101</a>, <a href="lwg-active.html#2103">2103</a>, <a href="lwg-active.html#2104">2104</a>, <a href="lwg-active.html#2105">2105</a>, <a href="lwg-active.html#2106">2106</a>, <a href="lwg-active.html#2107">2107</a>, <a href="lwg-active.html#2108">2108</a>, <a href="lwg-active.html#2109">2109</a>, <a href="lwg-active.html#2110">2110</a>, <a href="lwg-active.html#2111">2111</a>, <a href="lwg-active.html#2112">2112</a>, <a href="lwg-active.html#2113">2113</a>, <a href="lwg-active.html#2114">2114</a>, <a href="lwg-active.html#2115">2115</a>, <a href="lwg-active.html#2116">2116</a>, <a href="lwg-active.html#2117">2117</a>, <a href="lwg-active.html#2118">2118</a>, <a href="lwg-active.html#2119">2119</a>, <a href="lwg-active.html#2120">2120</a>, <a href="lwg-active.html#2121">2121</a>, <a href="lwg-active.html#2122">2122</a>, <a href="lwg-active.html#2123">2123</a>.</li>
<li>Added the following 2 Tentatively Ready issues: <a href="lwg-active.html#2096">2096</a>, <a href="lwg-active.html#2102">2102</a>.</li>
<li>No issues changed.</li>
</ul></li>
</ul>
</li>
<li>R76: 
2011-09-06 post-Bloomington mailing
<ul>
<li><b>Summary:</b><ul>
<li>44 open issues, up by 19.</li>
<li>1549 closed issues, up by 9.</li>
<li>1593 issues total, up by 28.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 2 NAD issues: <a href="lwg-closed.html#2043">2043</a>, <a href="lwg-closed.html#2068">2068</a>.</li>
<li>Added the following 2 NAD Future issues: <a href="lwg-closed.html#2051">2051</a>, <a href="lwg-closed.html#2055">2055</a>.</li>
<li>Added the following 6 Open issues: <a href="lwg-active.html#2052">2052</a>, <a href="lwg-active.html#2054">2054</a>, <a href="lwg-active.html#2057">2057</a>, <a href="lwg-active.html#2062">2062</a>, <a href="lwg-active.html#2063">2063</a>, <a href="lwg-active.html#2070">2070</a>.</li>
<li>Added the following Pending NAD issue: <a href="lwg-closed.html#2046">2046</a>.</li>
<li>Added the following Pending NAD Editorial issue: <a href="lwg-closed.html#2060">2060</a>.</li>
<li>Added the following 10 Ready issues: <a href="lwg-active.html#2044">2044</a>, <a href="lwg-active.html#2045">2045</a>, <a href="lwg-active.html#2047">2047</a>, <a href="lwg-active.html#2050">2050</a>, <a href="lwg-active.html#2053">2053</a>, <a href="lwg-active.html#2061">2061</a>, <a href="lwg-active.html#2064">2064</a>, <a href="lwg-active.html#2065">2065</a>, <a href="lwg-active.html#2067">2067</a>, <a href="lwg-active.html#2069">2069</a>.</li>
<li>Added the following 5 Review issues: <a href="lwg-active.html#2048">2048</a>, <a href="lwg-active.html#2049">2049</a>, <a href="lwg-active.html#2056">2056</a>, <a href="lwg-active.html#2058">2058</a>, <a href="lwg-active.html#2059">2059</a>.</li>
<li>Added the following Tentatively Resolved issue: <a href="lwg-active.html#2066">2066</a>.</li>
<li>Changed the following 322 issues from WP to C++11: <a href="lwg-defects.html#149">149</a>, <a href="lwg-defects.html#296">296</a>, <a href="lwg-defects.html#419">419</a>, <a href="lwg-defects.html#427">427</a>, <a href="lwg-defects.html#430">430</a>, <a href="lwg-defects.html#471">471</a>, <a href="lwg-defects.html#473">473</a>, <a href="lwg-defects.html#498">498</a>, <a href="lwg-defects.html#539">539</a>, <a href="lwg-defects.html#556">556</a>, <a href="lwg-defects.html#564">564</a>, <a href="lwg-defects.html#565">565</a>, <a href="lwg-defects.html#630">630</a>, <a href="lwg-defects.html#659">659</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#688">688</a>, <a href="lwg-defects.html#696">696</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#711">711</a>, <a href="lwg-defects.html#716">716</a>, <a href="lwg-defects.html#723">723</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#752">752</a>, <a href="lwg-defects.html#753">753</a>, <a href="lwg-defects.html#758">758</a>, <a href="lwg-defects.html#765">765</a>, <a href="lwg-defects.html#774">774</a>, <a href="lwg-defects.html#780">780</a>, <a href="lwg-defects.html#788">788</a>, <a href="lwg-defects.html#810">810</a>, <a href="lwg-defects.html#811">811</a>, <a href="lwg-defects.html#814">814</a>, <a href="lwg-defects.html#817">817</a>, <a href="lwg-defects.html#819">819</a>, <a href="lwg-defects.html#821">821</a>, <a href="lwg-defects.html#835">835</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-defects.html#838">838</a>, <a href="lwg-defects.html#847">847</a>, <a href="lwg-defects.html#853">853</a>, <a href="lwg-defects.html#854">854</a>, <a href="lwg-defects.html#857">857</a>, <a href="lwg-defects.html#859">859</a>, <a href="lwg-defects.html#860">860</a>, <a href="lwg-defects.html#861">861</a>, <a href="lwg-defects.html#865">865</a>, <a href="lwg-defects.html#866">866</a>, <a href="lwg-defects.html#868">868</a>, <a href="lwg-defects.html#869">869</a>, <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#871">871</a>, <a href="lwg-defects.html#872">872</a>, <a href="lwg-defects.html#876">876</a>, <a href="lwg-defects.html#878">878</a>, <a href="lwg-defects.html#881">881</a>, <a href="lwg-defects.html#883">883</a>, <a href="lwg-defects.html#885">885</a>, <a href="lwg-defects.html#886">886</a>, <a href="lwg-defects.html#888">888</a>, <a href="lwg-defects.html#890">890</a>, <a href="lwg-defects.html#891">891</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-defects.html#894">894</a>, <a href="lwg-defects.html#896">896</a>, <a href="lwg-defects.html#898">898</a>, <a href="lwg-defects.html#899">899</a>, <a href="lwg-defects.html#900">900</a>, <a href="lwg-defects.html#904">904</a>, <a href="lwg-defects.html#907">907</a>, <a href="lwg-defects.html#909">909</a>, <a href="lwg-defects.html#911">911</a>, <a href="lwg-defects.html#920">920</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#922">922</a>, <a href="lwg-defects.html#925">925</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-defects.html#931">931</a>, <a href="lwg-defects.html#934">934</a>, <a href="lwg-defects.html#938">938</a>, <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-defects.html#948">948</a>, <a href="lwg-defects.html#949">949</a>, <a href="lwg-defects.html#951">951</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-defects.html#956">956</a>, <a href="lwg-defects.html#957">957</a>, <a href="lwg-defects.html#960">960</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#963">963</a>, <a href="lwg-defects.html#965">965</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>, <a href="lwg-defects.html#970">970</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#975">975</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-defects.html#981">981</a>, <a href="lwg-defects.html#982">982</a>, <a href="lwg-defects.html#984">984</a>, <a href="lwg-defects.html#986">986</a>, <a href="lwg-defects.html#987">987</a>, <a href="lwg-defects.html#990">990</a>, <a href="lwg-defects.html#991">991</a>, <a href="lwg-defects.html#993">993</a>, <a href="lwg-defects.html#994">994</a>, <a href="lwg-defects.html#997">997</a>, <a href="lwg-defects.html#998">998</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-defects.html#1004">1004</a>, <a href="lwg-defects.html#1006">1006</a>, <a href="lwg-defects.html#1011">1011</a>, <a href="lwg-defects.html#1012">1012</a>, <a href="lwg-defects.html#1014">1014</a>, <a href="lwg-defects.html#1019">1019</a>, <a href="lwg-defects.html#1021">1021</a>, <a href="lwg-defects.html#1030">1030</a>, <a href="lwg-defects.html#1033">1033</a>, <a href="lwg-defects.html#1034">1034</a>, <a href="lwg-defects.html#1037">1037</a>, <a href="lwg-defects.html#1038">1038</a>, <a href="lwg-defects.html#1039">1039</a>, <a href="lwg-defects.html#1040">1040</a>, <a href="lwg-defects.html#1044">1044</a>, <a href="lwg-defects.html#1045">1045</a>, <a href="lwg-defects.html#1065">1065</a>, <a href="lwg-defects.html#1066">1066</a>, <a href="lwg-defects.html#1070">1070</a>, <a href="lwg-defects.html#1071">1071</a>, <a href="lwg-defects.html#1073">1073</a>, <a href="lwg-defects.html#1079">1079</a>, <a href="lwg-defects.html#1089">1089</a>, <a href="lwg-defects.html#1094">1094</a>, <a href="lwg-defects.html#1095">1095</a>, <a href="lwg-defects.html#1097">1097</a>, <a href="lwg-defects.html#1098">1098</a>, <a href="lwg-defects.html#1103">1103</a>, <a href="lwg-defects.html#1104">1104</a>, <a href="lwg-defects.html#1108">1108</a>, <a href="lwg-defects.html#1110">1110</a>, <a href="lwg-defects.html#1113">1113</a>, <a href="lwg-defects.html#1114">1114</a>, <a href="lwg-defects.html#1118">1118</a>, <a href="lwg-defects.html#1123">1123</a>, <a href="lwg-defects.html#1126">1126</a>, <a href="lwg-defects.html#1130">1130</a>, <a href="lwg-defects.html#1131">1131</a>, <a href="lwg-defects.html#1133">1133</a>, <a href="lwg-defects.html#1134">1134</a>, <a href="lwg-defects.html#1136">1136</a>, <a href="lwg-defects.html#1137">1137</a>, <a href="lwg-defects.html#1138">1138</a>, <a href="lwg-defects.html#1144">1144</a>, <a href="lwg-defects.html#1152">1152</a>, <a href="lwg-defects.html#1157">1157</a>, <a href="lwg-defects.html#1158">1158</a>, <a href="lwg-defects.html#1159">1159</a>, <a href="lwg-defects.html#1170">1170</a>, <a href="lwg-defects.html#1171">1171</a>, <a href="lwg-defects.html#1177">1177</a>, <a href="lwg-defects.html#1178">1178</a>, <a href="lwg-defects.html#1180">1180</a>, <a href="lwg-defects.html#1181">1181</a>, <a href="lwg-defects.html#1182">1182</a>, <a href="lwg-defects.html#1183">1183</a>, <a href="lwg-defects.html#1187">1187</a>, <a href="lwg-defects.html#1189">1189</a>, <a href="lwg-defects.html#1191">1191</a>, <a href="lwg-defects.html#1192">1192</a>, <a href="lwg-defects.html#1193">1193</a>, <a href="lwg-defects.html#1194">1194</a>, <a href="lwg-defects.html#1195">1195</a>, <a href="lwg-defects.html#1197">1197</a>, <a href="lwg-defects.html#1198">1198</a>, <a href="lwg-defects.html#1199">1199</a>, <a href="lwg-defects.html#1204">1204</a>, <a href="lwg-defects.html#1205">1205</a>, <a href="lwg-defects.html#1206">1206</a>, <a href="lwg-defects.html#1207">1207</a>, <a href="lwg-defects.html#1208">1208</a>, <a href="lwg-defects.html#1209">1209</a>, <a href="lwg-defects.html#1215">1215</a>, <a href="lwg-defects.html#1216">1216</a>, <a href="lwg-defects.html#1218">1218</a>, <a href="lwg-defects.html#1220">1220</a>, <a href="lwg-defects.html#1221">1221</a>, <a href="lwg-defects.html#1222">1222</a>, <a href="lwg-defects.html#1227">1227</a>, <a href="lwg-defects.html#1231">1231</a>, <a href="lwg-defects.html#1234">1234</a>, <a href="lwg-defects.html#1237">1237</a>, <a href="lwg-defects.html#1240">1240</a>, <a href="lwg-defects.html#1241">1241</a>, <a href="lwg-defects.html#1245">1245</a>, <a href="lwg-defects.html#1247">1247</a>, <a href="lwg-defects.html#1249">1249</a>, <a href="lwg-defects.html#1250">1250</a>, <a href="lwg-defects.html#1252">1252</a>, <a href="lwg-defects.html#1253">1253</a>, <a href="lwg-defects.html#1254">1254</a>, <a href="lwg-defects.html#1255">1255</a>, <a href="lwg-defects.html#1256">1256</a>, <a href="lwg-defects.html#1257">1257</a>, <a href="lwg-defects.html#1261">1261</a>, <a href="lwg-defects.html#1262">1262</a>, <a href="lwg-defects.html#1264">1264</a>, <a href="lwg-defects.html#1267">1267</a>, <a href="lwg-defects.html#1270">1270</a>, <a href="lwg-defects.html#1271">1271</a>, <a href="lwg-defects.html#1276">1276</a>, <a href="lwg-defects.html#1277">1277</a>, <a href="lwg-defects.html#1278">1278</a>, <a href="lwg-defects.html#1279">1279</a>, <a href="lwg-defects.html#1280">1280</a>, <a href="lwg-defects.html#1284">1284</a>, <a href="lwg-defects.html#1285">1285</a>, <a href="lwg-defects.html#1286">1286</a>, <a href="lwg-defects.html#1287">1287</a>, <a href="lwg-defects.html#1288">1288</a>, <a href="lwg-defects.html#1292">1292</a>, <a href="lwg-defects.html#1294">1294</a>, <a href="lwg-defects.html#1295">1295</a>, <a href="lwg-defects.html#1298">1298</a>, <a href="lwg-defects.html#1299">1299</a>, <a href="lwg-defects.html#1303">1303</a>, <a href="lwg-defects.html#1306">1306</a>, <a href="lwg-defects.html#1309">1309</a>, <a href="lwg-defects.html#1310">1310</a>, <a href="lwg-defects.html#1312">1312</a>, <a href="lwg-defects.html#1316">1316</a>, <a href="lwg-defects.html#1319">1319</a>, <a href="lwg-defects.html#1323">1323</a>, <a href="lwg-defects.html#1325">1325</a>, <a href="lwg-defects.html#1332">1332</a>, <a href="lwg-defects.html#1333">1333</a>, <a href="lwg-defects.html#1334">1334</a>, <a href="lwg-defects.html#1335">1335</a>, <a href="lwg-defects.html#1337">1337</a>, <a href="lwg-defects.html#1338">1338</a>, <a href="lwg-defects.html#1339">1339</a>, <a href="lwg-defects.html#1340">1340</a>, <a href="lwg-defects.html#1349">1349</a>, <a href="lwg-defects.html#1354">1354</a>, <a href="lwg-defects.html#1360">1360</a>, <a href="lwg-defects.html#1362">1362</a>, <a href="lwg-defects.html#1363">1363</a>, <a href="lwg-defects.html#1367">1367</a>, <a href="lwg-defects.html#1368">1368</a>, <a href="lwg-defects.html#1370">1370</a>, <a href="lwg-defects.html#1372">1372</a>, <a href="lwg-defects.html#1381">1381</a>, <a href="lwg-defects.html#1384">1384</a>, <a href="lwg-defects.html#1385">1385</a>, <a href="lwg-defects.html#1386">1386</a>, <a href="lwg-defects.html#1387">1387</a>, <a href="lwg-defects.html#1388">1388</a>, <a href="lwg-defects.html#1399">1399</a>, <a href="lwg-defects.html#1400">1400</a>, <a href="lwg-defects.html#1401">1401</a>, <a href="lwg-defects.html#1402">1402</a>, <a href="lwg-defects.html#1403">1403</a>, <a href="lwg-defects.html#1404">1404</a>, <a href="lwg-defects.html#1408">1408</a>, <a href="lwg-defects.html#1414">1414</a>, <a href="lwg-defects.html#1416">1416</a>, <a href="lwg-defects.html#1417">1417</a>, <a href="lwg-defects.html#1418">1418</a>, <a href="lwg-defects.html#1420">1420</a>, <a href="lwg-defects.html#1423">1423</a>, <a href="lwg-defects.html#1424">1424</a>, <a href="lwg-defects.html#1425">1425</a>, <a href="lwg-defects.html#1426">1426</a>, <a href="lwg-defects.html#1427">1427</a>, <a href="lwg-defects.html#1428">1428</a>, <a href="lwg-defects.html#1429">1429</a>, <a href="lwg-defects.html#1430">1430</a>, <a href="lwg-defects.html#1431">1431</a>, <a href="lwg-defects.html#1432">1432</a>, <a href="lwg-defects.html#1435">1435</a>, <a href="lwg-defects.html#1436">1436</a>, <a href="lwg-defects.html#1437">1437</a>, <a href="lwg-defects.html#1438">1438</a>, <a href="lwg-defects.html#1439">1439</a>, <a href="lwg-defects.html#1440">1440</a>, <a href="lwg-defects.html#1441">1441</a>, <a href="lwg-defects.html#1448">1448</a>, <a href="lwg-defects.html#1449">1449</a>, <a href="lwg-defects.html#1474">1474</a>, <a href="lwg-defects.html#1478">1478</a>, <a href="lwg-defects.html#1479">1479</a>, <a href="lwg-defects.html#1480">1480</a>, <a href="lwg-defects.html#1487">1487</a>, <a href="lwg-defects.html#1494">1494</a>, <a href="lwg-defects.html#1497">1497</a>, <a href="lwg-defects.html#1514">1514</a>, <a href="lwg-defects.html#1516">1516</a>, <a href="lwg-defects.html#1517">1517</a>, <a href="lwg-defects.html#1518">1518</a>, <a href="lwg-defects.html#1519">1519</a>, <a href="lwg-defects.html#1520">1520</a>, <a href="lwg-defects.html#1522">1522</a>, <a href="lwg-defects.html#1524">1524</a>, <a href="lwg-defects.html#1525">1525</a>, <a href="lwg-defects.html#2000">2000</a>, <a href="lwg-defects.html#2001">2001</a>, <a href="lwg-defects.html#2004">2004</a>, <a href="lwg-defects.html#2007">2007</a>, <a href="lwg-defects.html#2008">2008</a>, <a href="lwg-defects.html#2014">2014</a>, <a href="lwg-defects.html#2017">2017</a>, <a href="lwg-defects.html#2019">2019</a>, <a href="lwg-defects.html#2020">2020</a>, <a href="lwg-defects.html#2022">2022</a>, <a href="lwg-defects.html#2027">2027</a>, <a href="lwg-defects.html#2029">2029</a>, <a href="lwg-defects.html#2030">2030</a>, <a href="lwg-defects.html#2031">2031</a>, <a href="lwg-defects.html#2032">2032</a>, <a href="lwg-defects.html#2041">2041</a>, <a href="lwg-defects.html#2042">2042</a>.</li>
<li>Changed the following issue from Deferred to NAD: <a href="lwg-closed.html#1330">1330</a>.</li>
<li>Changed the following issue from Deferred to NAD Future: <a href="lwg-closed.html#1521">1521</a>.</li>
<li>Changed the following issue from Open to NAD Future: <a href="lwg-closed.html#2040">2040</a>.</li>
<li>Changed the following issue from Deferred to Open: <a href="lwg-active.html#1450">1450</a>.</li>
<li>Changed the following issue from Deferred to Ready: <a href="lwg-active.html#1214">1214</a>.</li>
<li>Changed the following 2 issues from New to Ready: <a href="lwg-active.html#2013">2013</a>, <a href="lwg-active.html#2015">2015</a>.</li>
<li>Changed the following 2 issues from Open to Ready: <a href="lwg-active.html#2010">2010</a>, <a href="lwg-active.html#2033">2033</a>.</li>
<li>Changed the following issue from Review to Ready: <a href="lwg-active.html#2021">2021</a>.</li>
<li>Changed the following 2 issues from Deferred to Review: <a href="lwg-active.html#1169">1169</a>, <a href="lwg-active.html#1175">1175</a>.</li>
<li>Changed the following issue from Open to Review: <a href="lwg-active.html#2011">2011</a>.</li>
</ul></li>
</ul>
</li>
<li>R75: 
2011-03-28 post-Madrid mailing
<ul>
<li><b>Summary:</b><ul>
<li>25 open issues, down by 71.</li>
<li>1540 closed issues, up by 80.</li>
<li>1565 issues total, up by 9.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issue: <a href="lwg-closed.html#2036">2036</a>.</li>
<li>Added the following 2 Open issues: <a href="lwg-active.html#2038">2038</a>, <a href="lwg-closed.html#2040">2040</a>.</li>
<li>Added the following Ready issue: <a href="lwg-defects.html#2039">2039</a>.</li>
<li>Added the following Resolved issue: <a href="lwg-defects.html#2037">2037</a>.</li>
<li>Added the following 2 WP issues: <a href="lwg-defects.html#2041">2041</a>, <a href="lwg-defects.html#2042">2042</a>.</li>
<li>Changed the following issue from New to Deferred: <a href="lwg-closed.html#1521">1521</a>.</li>
<li>Changed the following 2 issues from Open to Deferred: <a href="lwg-active.html#1169">1169</a>, <a href="lwg-active.html#1175">1175</a>.</li>
<li>Changed the following 7 issues from Open to NAD: <a href="lwg-closed.html#1318">1318</a>, <a href="lwg-closed.html#1348">1348</a>, <a href="lwg-closed.html#1358">1358</a>, <a href="lwg-closed.html#1369">1369</a>, <a href="lwg-closed.html#1374">1374</a>, <a href="lwg-closed.html#1452">1452</a>, <a href="lwg-closed.html#1461">1461</a>.</li>
<li>Changed the following 6 issues from Tentatively NAD to NAD: <a href="lwg-closed.html#1371">1371</a>, <a href="lwg-closed.html#1413">1413</a>, <a href="lwg-closed.html#1485">1485</a>, <a href="lwg-closed.html#1486">1486</a>, <a href="lwg-closed.html#2006">2006</a>, <a href="lwg-closed.html#2026">2026</a>.</li>
<li>Changed the following issue from Tentatively Ready to NAD: <a href="lwg-closed.html#1456">1456</a>.</li>
<li>Changed the following 2 issues from Open to NAD Future: <a href="lwg-closed.html#1396">1396</a>, <a href="lwg-closed.html#1459">1459</a>.</li>
<li>Changed the following issue from Tentatively NAD Future to NAD Future: <a href="lwg-closed.html#1320">1320</a>.</li>
<li>Changed the following 4 issues from New to Open: <a href="lwg-defects.html#2012">2012</a>, <a href="lwg-defects.html#2018">2018</a>, <a href="lwg-defects.html#2033">2033</a>, <a href="lwg-active.html#2035">2035</a>.</li>
<li>Changed the following issue from New to Ready: <a href="lwg-defects.html#2028">2028</a>.</li>
<li>Changed the following issue from Review to Ready: <a href="lwg-defects.html#2009">2009</a>.</li>
<li>Changed the following issue from NAD to Resolved: <a href="lwg-defects.html#343">343</a>.</li>
<li>Changed the following issue from NAD Editorial to Resolved: <a href="lwg-defects.html#485">485</a>.</li>
<li>Changed the following 3 issues from New to Resolved: <a href="lwg-defects.html#1523">1523</a>, <a href="lwg-defects.html#2025">2025</a>, <a href="lwg-defects.html#2034">2034</a>.</li>
<li>Changed the following 13 issues from Open to Resolved: <a href="lwg-defects.html#964">964</a>, <a href="lwg-defects.html#966">966</a>, <a href="lwg-defects.html#985">985</a>, <a href="lwg-defects.html#1297">1297</a>, <a href="lwg-defects.html#1345">1345</a>, <a href="lwg-defects.html#1353">1353</a>, <a href="lwg-defects.html#1364">1364</a>, <a href="lwg-defects.html#1421">1421</a>, <a href="lwg-defects.html#1460">1460</a>, <a href="lwg-defects.html#1502">1502</a>, <a href="lwg-defects.html#1504">1504</a>, <a href="lwg-defects.html#1505">1505</a>, <a href="lwg-defects.html#1507">1507</a>.</li>
<li>Changed the following 4 issues from Tentatively Ready to Resolved: <a href="lwg-defects.html#1457">1457</a>, <a href="lwg-defects.html#1515">1515</a>, <a href="lwg-defects.html#2023">2023</a>, <a href="lwg-defects.html#2024">2024</a>.</li>
<li>Changed the following issue from New to Review: <a href="lwg-defects.html#2021">2021</a>.</li>
<li>Changed the following issue from Open to Review: <a href="lwg-defects.html#2005">2005</a>.</li>
<li>Changed the following 3 issues from New to WP: <a href="lwg-defects.html#1524">1524</a>, <a href="lwg-defects.html#2008">2008</a>, <a href="lwg-defects.html#2032">2032</a>.</li>
<li>Changed the following 5 issues from Open to WP: <a href="lwg-defects.html#1252">1252</a>, <a href="lwg-defects.html#1349">1349</a>, <a href="lwg-defects.html#1448">1448</a>, <a href="lwg-defects.html#1478">1478</a>, <a href="lwg-defects.html#1487">1487</a>.</li>
<li>Changed the following 8 issues from Ready to WP: <a href="lwg-defects.html#1279">1279</a>, <a href="lwg-defects.html#1332">1332</a>, <a href="lwg-defects.html#1385">1385</a>, <a href="lwg-defects.html#1401">1401</a>, <a href="lwg-defects.html#1408">1408</a>, <a href="lwg-defects.html#1418">1418</a>, <a href="lwg-defects.html#1420">1420</a>, <a href="lwg-defects.html#1438">1438</a>.</li>
<li>Changed the following 22 issues from Tentatively Ready to WP: <a href="lwg-defects.html#1215">1215</a>, <a href="lwg-defects.html#1253">1253</a>, <a href="lwg-defects.html#1310">1310</a>, <a href="lwg-defects.html#1474">1474</a>, <a href="lwg-defects.html#1479">1479</a>, <a href="lwg-defects.html#1480">1480</a>, <a href="lwg-defects.html#1494">1494</a>, <a href="lwg-defects.html#1497">1497</a>, <a href="lwg-defects.html#1514">1514</a>, <a href="lwg-defects.html#2000">2000</a>, <a href="lwg-defects.html#2001">2001</a>, <a href="lwg-defects.html#2004">2004</a>, <a href="lwg-defects.html#2007">2007</a>, <a href="lwg-defects.html#2014">2014</a>, <a href="lwg-defects.html#2017">2017</a>, <a href="lwg-defects.html#2019">2019</a>, <a href="lwg-defects.html#2020">2020</a>, <a href="lwg-defects.html#2022">2022</a>, <a href="lwg-defects.html#2027">2027</a>, <a href="lwg-defects.html#2029">2029</a>, <a href="lwg-defects.html#2030">2030</a>, <a href="lwg-defects.html#2031">2031</a>.</li>
</ul></li>
</ul>
</li>
<li>R74: 
2011-02-28 pre-Madrid mailing
<ul>
<li><b>Summary:</b><ul>
<li>96 open issues, up by 16.</li>
<li>1460 closed issues, up by 1.</li>
<li>1556 issues total, up by 17.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 7 New issues: <a href="lwg-defects.html#2021">2021</a>, <a href="lwg-defects.html#2025">2025</a>, <a href="lwg-defects.html#2028">2028</a>, <a href="lwg-defects.html#2032">2032</a>, <a href="lwg-defects.html#2033">2033</a>, <a href="lwg-defects.html#2034">2034</a>, <a href="lwg-active.html#2035">2035</a>.</li>
<li>Added the following Tentatively NAD issue: <a href="lwg-closed.html#2026">2026</a>.</li>
<li>Added the following 8 Tentatively Ready issues: <a href="lwg-defects.html#2020">2020</a>, <a href="lwg-defects.html#2022">2022</a>, <a href="lwg-defects.html#2023">2023</a>, <a href="lwg-defects.html#2024">2024</a>, <a href="lwg-defects.html#2027">2027</a>, <a href="lwg-defects.html#2029">2029</a>, <a href="lwg-defects.html#2030">2030</a>, <a href="lwg-defects.html#2031">2031</a>.</li>
<li>Changed the following issue from Open to NAD Editorial: <a href="lwg-closed.html#1503">1503</a>.</li>
<li>Changed the following issue from New to Open: <a href="lwg-active.html#2016">2016</a>.</li>
<li>Changed the following issue from Ready to Open: <a href="lwg-closed.html#1318">1318</a>.</li>
<li>Changed the following issue from NAD to Resolved: <a href="lwg-defects.html#1229">1229</a>.</li>
<li>Changed the following 65 issues from NAD Editorial to Resolved: <a href="lwg-defects.html#732">732</a>, <a href="lwg-defects.html#756">756</a>, <a href="lwg-defects.html#767">767</a>, <a href="lwg-defects.html#793">793</a>, <a href="lwg-defects.html#794">794</a>, <a href="lwg-defects.html#800">800</a>, <a href="lwg-defects.html#803">803</a>, <a href="lwg-defects.html#825">825</a>, <a href="lwg-defects.html#828">828</a>, <a href="lwg-defects.html#874">874</a>, <a href="lwg-defects.html#875">875</a>, <a href="lwg-defects.html#880">880</a>, <a href="lwg-defects.html#889">889</a>, <a href="lwg-defects.html#897">897</a>, <a href="lwg-defects.html#908">908</a>, <a href="lwg-defects.html#923">923</a>, <a href="lwg-defects.html#924">924</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#944">944</a>, <a href="lwg-defects.html#958">958</a>, <a href="lwg-defects.html#976">976</a>, <a href="lwg-defects.html#1043">1043</a>, <a href="lwg-defects.html#1046">1046</a>, <a href="lwg-defects.html#1047">1047</a>, <a href="lwg-defects.html#1048">1048</a>, <a href="lwg-defects.html#1049">1049</a>, <a href="lwg-defects.html#1050">1050</a>, <a href="lwg-defects.html#1088">1088</a>, <a href="lwg-defects.html#1090">1090</a>, <a href="lwg-defects.html#1093">1093</a>, <a href="lwg-defects.html#1106">1106</a>, <a href="lwg-defects.html#1129">1129</a>, <a href="lwg-defects.html#1143">1143</a>, <a href="lwg-defects.html#1145">1145</a>, <a href="lwg-defects.html#1146">1146</a>, <a href="lwg-defects.html#1147">1147</a>, <a href="lwg-defects.html#1160">1160</a>, <a href="lwg-defects.html#1161">1161</a>, <a href="lwg-defects.html#1162">1162</a>, <a href="lwg-defects.html#1163">1163</a>, <a href="lwg-defects.html#1165">1165</a>, <a href="lwg-defects.html#1166">1166</a>, <a href="lwg-defects.html#1172">1172</a>, <a href="lwg-defects.html#1185">1185</a>, <a href="lwg-defects.html#1196">1196</a>, <a href="lwg-defects.html#1210">1210</a>, <a href="lwg-defects.html#1211">1211</a>, <a href="lwg-defects.html#1212">1212</a>, <a href="lwg-defects.html#1225">1225</a>, <a href="lwg-defects.html#1226">1226</a>, <a href="lwg-defects.html#1244">1244</a>, <a href="lwg-defects.html#1248">1248</a>, <a href="lwg-defects.html#1266">1266</a>, <a href="lwg-defects.html#1269">1269</a>, <a href="lwg-defects.html#1272">1272</a>, <a href="lwg-defects.html#1273">1273</a>, <a href="lwg-defects.html#1274">1274</a>, <a href="lwg-defects.html#1275">1275</a>, <a href="lwg-defects.html#1281">1281</a>, <a href="lwg-defects.html#1291">1291</a>, <a href="lwg-defects.html#1300">1300</a>, <a href="lwg-defects.html#1304">1304</a>, <a href="lwg-defects.html#1305">1305</a>, <a href="lwg-defects.html#1311">1311</a>, <a href="lwg-defects.html#1329">1329</a>.</li>
<li>Changed the following 2 issues from Open to Tentatively NAD: <a href="lwg-closed.html#1485">1485</a>, <a href="lwg-closed.html#1486">1486</a>.</li>
<li>Changed the following 3 issues from New to Tentatively Ready: <a href="lwg-defects.html#2014">2014</a>, <a href="lwg-defects.html#2017">2017</a>, <a href="lwg-defects.html#2019">2019</a>.</li>
<li>Changed the following 8 issues from Open to Tentatively Ready: <a href="lwg-closed.html#1456">1456</a>, <a href="lwg-defects.html#1457">1457</a>, <a href="lwg-defects.html#1474">1474</a>, <a href="lwg-defects.html#1479">1479</a>, <a href="lwg-defects.html#1494">1494</a>, <a href="lwg-defects.html#1514">1514</a>, <a href="lwg-defects.html#1515">1515</a>, <a href="lwg-defects.html#2001">2001</a>.</li>
<li>Changed the following issue from Review to Tentatively Ready: <a href="lwg-defects.html#1480">1480</a>.</li>
</ul></li>
</ul>
</li>
<li>R73: 
2010-11-29 Post-Batavia mailing.
<ul>
<li><b>Summary:</b><ul>
<li>80 open issues, down by 126.</li>
<li>1459 closed issues, up by 145.</li>
<li>1539 issues total, up by 19.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 11 New issues: <a href="lwg-closed.html#1521">1521</a>, <a href="lwg-defects.html#1523">1523</a>, <a href="lwg-defects.html#2008">2008</a>, <a href="lwg-defects.html#2012">2012</a>, <a href="lwg-defects.html#2013">2013</a>, <a href="lwg-defects.html#2014">2014</a>, <a href="lwg-defects.html#2015">2015</a>, <a href="lwg-active.html#2016">2016</a>, <a href="lwg-defects.html#2017">2017</a>, <a href="lwg-defects.html#2018">2018</a>, <a href="lwg-defects.html#2019">2019</a>.</li>
<li>Added the following 5 Open issues: <a href="lwg-defects.html#2001">2001</a>, <a href="lwg-defects.html#2003">2003</a>, <a href="lwg-defects.html#2005">2005</a>, <a href="lwg-defects.html#2010">2010</a>, <a href="lwg-defects.html#2011">2011</a>.</li>
<li>Added the following Resolved issue: <a href="lwg-defects.html#2002">2002</a>.</li>
<li>Added the following Review issue: <a href="lwg-defects.html#2009">2009</a>.</li>
<li>Added the following Tentatively NAD issue: <a href="lwg-closed.html#2006">2006</a>.</li>
<li>Added the following 3 Tentatively Ready issues: <a href="lwg-defects.html#2000">2000</a>, <a href="lwg-defects.html#2004">2004</a>, <a href="lwg-defects.html#2007">2007</a>.</li>
<li>Added the following WP issue: <a href="lwg-defects.html#1522">1522</a>.</li>
<li>Changed the following 3 issues from New to Deferred: <a href="lwg-active.html#1213">1213</a>, <a href="lwg-defects.html#1214">1214</a>, <a href="lwg-closed.html#1330">1330</a>.</li>
<li>Changed the following issue from Open to Deferred: <a href="lwg-defects.html#1450">1450</a>.</li>
<li>Changed the following 14 issues from Open to Dup: <a href="lwg-closed.html#1350">1350</a>, <a href="lwg-closed.html#1351">1351</a>, <a href="lwg-closed.html#1352">1352</a>, <a href="lwg-closed.html#1375">1375</a>, <a href="lwg-closed.html#1411">1411</a>, <a href="lwg-closed.html#1443">1443</a>, <a href="lwg-closed.html#1451">1451</a>, <a href="lwg-closed.html#1454">1454</a>, <a href="lwg-closed.html#1458">1458</a>, <a href="lwg-closed.html#1463">1463</a>, <a href="lwg-closed.html#1470">1470</a>, <a href="lwg-closed.html#1475">1475</a>, <a href="lwg-closed.html#1476">1476</a>, <a href="lwg-closed.html#1477">1477</a>.</li>
<li>Changed the following issue from New to NAD: <a href="lwg-closed.html#1331">1331</a>.</li>
<li>Changed the following 8 issues from Open to NAD: <a href="lwg-closed.html#579">579</a>, <a href="lwg-closed.html#1359">1359</a>, <a href="lwg-closed.html#1361">1361</a>, <a href="lwg-closed.html#1373">1373</a>, <a href="lwg-closed.html#1376">1376</a>, <a href="lwg-closed.html#1398">1398</a>, <a href="lwg-closed.html#1446">1446</a>, <a href="lwg-closed.html#1473">1473</a>.</li>
<li>Changed the following 2 issues from Tentatively NAD to NAD: <a href="lwg-closed.html#1190">1190</a>, <a href="lwg-closed.html#1200">1200</a>.</li>
<li>Changed the following issue from WP to NAD: <a href="lwg-closed.html#822">822</a>.</li>
<li>Changed the following 11 issues from Open to NAD Editorial: <a href="lwg-closed.html#1395">1395</a>, <a href="lwg-closed.html#1442">1442</a>, <a href="lwg-closed.html#1471">1471</a>, <a href="lwg-closed.html#1472">1472</a>, <a href="lwg-closed.html#1489">1489</a>, <a href="lwg-closed.html#1495">1495</a>, <a href="lwg-closed.html#1496">1496</a>, <a href="lwg-closed.html#1509">1509</a>, <a href="lwg-closed.html#1510">1510</a>, <a href="lwg-closed.html#1511">1511</a>, <a href="lwg-closed.html#1512">1512</a>.</li>
<li>Changed the following issue from Review to NAD Editorial: <a href="lwg-defects.html#1281">1281</a>.</li>
<li>Changed the following issue from New to NAD Future: <a href="lwg-closed.html#1289">1289</a>.</li>
<li>Changed the following 6 issues from Open to NAD Future: <a href="lwg-closed.html#1406">1406</a>, <a href="lwg-closed.html#1422">1422</a>, <a href="lwg-closed.html#1484">1484</a>, <a href="lwg-closed.html#1488">1488</a>, <a href="lwg-closed.html#1493">1493</a>, <a href="lwg-closed.html#1499">1499</a>.</li>
<li>Changed the following 2 issues from Tentatively NAD Future to NAD Future: <a href="lwg-closed.html#1173">1173</a>, <a href="lwg-closed.html#1188">1188</a>.</li>
<li>Changed the following 2 issues from New to Open: <a href="lwg-defects.html#1252">1252</a>, <a href="lwg-defects.html#1297">1297</a>.</li>
<li>Changed the following 3 issues from New to Ready: <a href="lwg-defects.html#1279">1279</a>, <a href="lwg-closed.html#1318">1318</a>, <a href="lwg-defects.html#1332">1332</a>.</li>
<li>Changed the following 6 issues from Open to Ready: <a href="lwg-defects.html#1385">1385</a>, <a href="lwg-defects.html#1401">1401</a>, <a href="lwg-defects.html#1408">1408</a>, <a href="lwg-defects.html#1418">1418</a>, <a href="lwg-defects.html#1420">1420</a>, <a href="lwg-defects.html#1438">1438</a>.</li>
<li>Changed the following 42 issues from NAD Editorial to Resolved: <a href="lwg-defects.html#353">353</a>, <a href="lwg-defects.html#431">431</a>, <a href="lwg-defects.html#482">482</a>, <a href="lwg-defects.html#525">525</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-defects.html#625">625</a>, <a href="lwg-defects.html#635">635</a>, <a href="lwg-defects.html#658">658</a>, <a href="lwg-defects.html#697">697</a>, <a href="lwg-defects.html#719">719</a>, <a href="lwg-defects.html#742">742</a>, <a href="lwg-defects.html#786">786</a>, <a href="lwg-defects.html#815">815</a>, <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#823">823</a>, <a href="lwg-defects.html#827">827</a>, <a href="lwg-defects.html#834">834</a>, <a href="lwg-defects.html#884">884</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-defects.html#947">947</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#953">953</a>, <a href="lwg-defects.html#983">983</a>, <a href="lwg-defects.html#1054">1054</a>, <a href="lwg-defects.html#1055">1055</a>, <a href="lwg-defects.html#1075">1075</a>, <a href="lwg-defects.html#1100">1100</a>, <a href="lwg-defects.html#1116">1116</a>, <a href="lwg-defects.html#1117">1117</a>, <a href="lwg-defects.html#1122">1122</a>, <a href="lwg-defects.html#1135">1135</a>, <a href="lwg-defects.html#1151">1151</a>, <a href="lwg-defects.html#1174">1174</a>, <a href="lwg-defects.html#1258">1258</a>, <a href="lwg-defects.html#1260">1260</a>, <a href="lwg-defects.html#1283">1283</a>, <a href="lwg-defects.html#1293">1293</a>, <a href="lwg-defects.html#1307">1307</a>, <a href="lwg-defects.html#1321">1321</a>, <a href="lwg-defects.html#1394">1394</a>, <a href="lwg-defects.html#1405">1405</a>, <a href="lwg-defects.html#1407">1407</a>.</li>
<li>Changed the following 5 issues from New to Resolved: <a href="lwg-defects.html#1290">1290</a>, <a href="lwg-defects.html#1322">1322</a>, <a href="lwg-defects.html#1324">1324</a>, <a href="lwg-defects.html#1326">1326</a>, <a href="lwg-defects.html#1328">1328</a>.</li>
<li>Changed the following 46 issues from Open to Resolved: <a href="lwg-defects.html#801">801</a>, <a href="lwg-defects.html#1268">1268</a>, <a href="lwg-defects.html#1327">1327</a>, <a href="lwg-defects.html#1344">1344</a>, <a href="lwg-defects.html#1346">1346</a>, <a href="lwg-defects.html#1347">1347</a>, <a href="lwg-defects.html#1355">1355</a>, <a href="lwg-defects.html#1356">1356</a>, <a href="lwg-defects.html#1357">1357</a>, <a href="lwg-defects.html#1365">1365</a>, <a href="lwg-defects.html#1366">1366</a>, <a href="lwg-defects.html#1377">1377</a>, <a href="lwg-defects.html#1378">1378</a>, <a href="lwg-defects.html#1379">1379</a>, <a href="lwg-defects.html#1380">1380</a>, <a href="lwg-defects.html#1382">1382</a>, <a href="lwg-defects.html#1383">1383</a>, <a href="lwg-defects.html#1389">1389</a>, <a href="lwg-defects.html#1390">1390</a>, <a href="lwg-defects.html#1391">1391</a>, <a href="lwg-defects.html#1392">1392</a>, <a href="lwg-defects.html#1393">1393</a>, <a href="lwg-defects.html#1397">1397</a>, <a href="lwg-defects.html#1409">1409</a>, <a href="lwg-defects.html#1410">1410</a>, <a href="lwg-defects.html#1412">1412</a>, <a href="lwg-defects.html#1445">1445</a>, <a href="lwg-defects.html#1447">1447</a>, <a href="lwg-defects.html#1453">1453</a>, <a href="lwg-defects.html#1455">1455</a>, <a href="lwg-defects.html#1462">1462</a>, <a href="lwg-defects.html#1464">1464</a>, <a href="lwg-defects.html#1465">1465</a>, <a href="lwg-defects.html#1466">1466</a>, <a href="lwg-defects.html#1467">1467</a>, <a href="lwg-defects.html#1468">1468</a>, <a href="lwg-defects.html#1469">1469</a>, <a href="lwg-defects.html#1481">1481</a>, <a href="lwg-defects.html#1482">1482</a>, <a href="lwg-defects.html#1490">1490</a>, <a href="lwg-defects.html#1491">1491</a>, <a href="lwg-defects.html#1492">1492</a>, <a href="lwg-defects.html#1498">1498</a>, <a href="lwg-defects.html#1501">1501</a>, <a href="lwg-defects.html#1508">1508</a>, <a href="lwg-defects.html#1513">1513</a>.</li>
<li>Changed the following issue from Open to Review: <a href="lwg-defects.html#1480">1480</a>.</li>
<li>Changed the following 2 issues from Open to Tentatively NAD: <a href="lwg-closed.html#1371">1371</a>, <a href="lwg-closed.html#1413">1413</a>.</li>
<li>Changed the following issue from New to Tentatively NAD Future: <a href="lwg-closed.html#1320">1320</a>.</li>
<li>Changed the following 3 issues from New to Tentatively Ready: <a href="lwg-defects.html#1215">1215</a>, <a href="lwg-defects.html#1253">1253</a>, <a href="lwg-defects.html#1310">1310</a>.</li>
<li>Changed the following issue from Open to Tentatively Ready: <a href="lwg-defects.html#1497">1497</a>.</li>
<li>Changed the following 24 issues from NAD Editorial to WP: <a href="lwg-defects.html#1360">1360</a>, <a href="lwg-defects.html#1363">1363</a>, <a href="lwg-defects.html#1367">1367</a>, <a href="lwg-defects.html#1372">1372</a>, <a href="lwg-defects.html#1381">1381</a>, <a href="lwg-defects.html#1384">1384</a>, <a href="lwg-defects.html#1386">1386</a>, <a href="lwg-defects.html#1387">1387</a>, <a href="lwg-defects.html#1388">1388</a>, <a href="lwg-defects.html#1399">1399</a>, <a href="lwg-defects.html#1400">1400</a>, <a href="lwg-defects.html#1402">1402</a>, <a href="lwg-defects.html#1403">1403</a>, <a href="lwg-defects.html#1416">1416</a>, <a href="lwg-defects.html#1417">1417</a>, <a href="lwg-defects.html#1423">1423</a>, <a href="lwg-defects.html#1424">1424</a>, <a href="lwg-defects.html#1425">1425</a>, <a href="lwg-defects.html#1426">1426</a>, <a href="lwg-defects.html#1427">1427</a>, <a href="lwg-defects.html#1429">1429</a>, <a href="lwg-defects.html#1430">1430</a>, <a href="lwg-defects.html#1431">1431</a>, <a href="lwg-defects.html#1441">1441</a>.</li>
<li>Changed the following issue from New to WP: <a href="lwg-defects.html#1294">1294</a>.</li>
<li>Changed the following 10 issues from Open to WP: <a href="lwg-defects.html#1354">1354</a>, <a href="lwg-defects.html#1362">1362</a>, <a href="lwg-defects.html#1368">1368</a>, <a href="lwg-defects.html#1370">1370</a>, <a href="lwg-defects.html#1428">1428</a>, <a href="lwg-defects.html#1435">1435</a>, <a href="lwg-defects.html#1436">1436</a>, <a href="lwg-defects.html#1437">1437</a>, <a href="lwg-defects.html#1439">1439</a>, <a href="lwg-defects.html#1440">1440</a>.</li>
<li>Changed the following 2 issues from Ready to WP: <a href="lwg-defects.html#868">868</a>, <a href="lwg-defects.html#951">951</a>.</li>
<li>Changed the following 33 issues from Tentatively Ready to WP: <a href="lwg-defects.html#956">956</a>, <a href="lwg-defects.html#1118">1118</a>, <a href="lwg-defects.html#1171">1171</a>, <a href="lwg-defects.html#1181">1181</a>, <a href="lwg-defects.html#1183">1183</a>, <a href="lwg-defects.html#1191">1191</a>, <a href="lwg-defects.html#1198">1198</a>, <a href="lwg-defects.html#1207">1207</a>, <a href="lwg-defects.html#1234">1234</a>, <a href="lwg-defects.html#1240">1240</a>, <a href="lwg-defects.html#1249">1249</a>, <a href="lwg-defects.html#1292">1292</a>, <a href="lwg-defects.html#1295">1295</a>, <a href="lwg-defects.html#1316">1316</a>, <a href="lwg-defects.html#1319">1319</a>, <a href="lwg-defects.html#1323">1323</a>, <a href="lwg-defects.html#1325">1325</a>, <a href="lwg-defects.html#1333">1333</a>, <a href="lwg-defects.html#1334">1334</a>, <a href="lwg-defects.html#1335">1335</a>, <a href="lwg-defects.html#1337">1337</a>, <a href="lwg-defects.html#1338">1338</a>, <a href="lwg-defects.html#1339">1339</a>, <a href="lwg-defects.html#1340">1340</a>, <a href="lwg-defects.html#1404">1404</a>, <a href="lwg-defects.html#1414">1414</a>, <a href="lwg-defects.html#1432">1432</a>, <a href="lwg-defects.html#1449">1449</a>, <a href="lwg-defects.html#1516">1516</a>, <a href="lwg-defects.html#1517">1517</a>, <a href="lwg-defects.html#1518">1518</a>, <a href="lwg-defects.html#1519">1519</a>, <a href="lwg-defects.html#1520">1520</a>.</li>
</ul></li>
</ul>
</li>
<li>R72: 
2010-10-18 pre-Batavia mailing.
<ul>
<li><b>Summary:</b><ul>
<li>206 open issues, up by 141.</li>
<li>1314 closed issues, up by 36.</li>
<li>1520 issues total, up by 177.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following Dup issues: <a href="lwg-closed.html#1433">1433</a>, <a href="lwg-closed.html#1444">1444</a>.</li>
<li>Added the following NAD Editorial issues: <a href="lwg-defects.html#1360">1360</a>, <a href="lwg-defects.html#1363">1363</a>, <a href="lwg-defects.html#1367">1367</a>, <a href="lwg-defects.html#1372">1372</a>, <a href="lwg-defects.html#1381">1381</a>, <a href="lwg-defects.html#1384">1384</a>, <a href="lwg-defects.html#1386">1386</a>, <a href="lwg-defects.html#1387">1387</a>, <a href="lwg-defects.html#1388">1388</a>, <a href="lwg-defects.html#1394">1394</a>, <a href="lwg-defects.html#1399">1399</a>, <a href="lwg-defects.html#1400">1400</a>, <a href="lwg-defects.html#1402">1402</a>, <a href="lwg-defects.html#1403">1403</a>, <a href="lwg-defects.html#1405">1405</a>, <a href="lwg-defects.html#1407">1407</a>, <a href="lwg-closed.html#1415">1415</a>, <a href="lwg-defects.html#1416">1416</a>, <a href="lwg-defects.html#1417">1417</a>, <a href="lwg-closed.html#1419">1419</a>, <a href="lwg-defects.html#1423">1423</a>, <a href="lwg-defects.html#1424">1424</a>, <a href="lwg-defects.html#1425">1425</a>, <a href="lwg-defects.html#1426">1426</a>, <a href="lwg-defects.html#1427">1427</a>, <a href="lwg-defects.html#1429">1429</a>, <a href="lwg-defects.html#1430">1430</a>, <a href="lwg-defects.html#1431">1431</a>, <a href="lwg-closed.html#1434">1434</a>, <a href="lwg-defects.html#1441">1441</a>, <a href="lwg-closed.html#1483">1483</a>, <a href="lwg-closed.html#1500">1500</a>, <a href="lwg-closed.html#1506">1506</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#1344">1344</a>, <a href="lwg-defects.html#1345">1345</a>, <a href="lwg-defects.html#1346">1346</a>, <a href="lwg-defects.html#1347">1347</a>, <a href="lwg-closed.html#1348">1348</a>, <a href="lwg-defects.html#1349">1349</a>, <a href="lwg-closed.html#1350">1350</a>, <a href="lwg-closed.html#1351">1351</a>, <a href="lwg-closed.html#1352">1352</a>, <a href="lwg-defects.html#1353">1353</a>, <a href="lwg-defects.html#1354">1354</a>, <a href="lwg-defects.html#1355">1355</a>, <a href="lwg-defects.html#1356">1356</a>, <a href="lwg-defects.html#1357">1357</a>, <a href="lwg-closed.html#1358">1358</a>, <a href="lwg-closed.html#1359">1359</a>, <a href="lwg-closed.html#1361">1361</a>, <a href="lwg-defects.html#1362">1362</a>, <a href="lwg-defects.html#1364">1364</a>, <a href="lwg-defects.html#1365">1365</a>, <a href="lwg-defects.html#1366">1366</a>, <a href="lwg-defects.html#1368">1368</a>, <a href="lwg-closed.html#1369">1369</a>, <a href="lwg-defects.html#1370">1370</a>, <a href="lwg-closed.html#1371">1371</a>, <a href="lwg-closed.html#1373">1373</a>, <a href="lwg-closed.html#1374">1374</a>, <a href="lwg-closed.html#1375">1375</a>, <a href="lwg-closed.html#1376">1376</a>, <a href="lwg-defects.html#1377">1377</a>, <a href="lwg-defects.html#1378">1378</a>, <a href="lwg-defects.html#1379">1379</a>, <a href="lwg-defects.html#1380">1380</a>, <a href="lwg-defects.html#1382">1382</a>, <a href="lwg-defects.html#1383">1383</a>, <a href="lwg-defects.html#1385">1385</a>, <a href="lwg-defects.html#1389">1389</a>, <a href="lwg-defects.html#1390">1390</a>, <a href="lwg-defects.html#1391">1391</a>, <a href="lwg-defects.html#1392">1392</a>, <a href="lwg-defects.html#1393">1393</a>, <a href="lwg-closed.html#1395">1395</a>, <a href="lwg-closed.html#1396">1396</a>, <a href="lwg-defects.html#1397">1397</a>, <a href="lwg-closed.html#1398">1398</a>, <a href="lwg-defects.html#1401">1401</a>, <a href="lwg-closed.html#1406">1406</a>, <a href="lwg-defects.html#1408">1408</a>, <a href="lwg-defects.html#1409">1409</a>, <a href="lwg-defects.html#1410">1410</a>, <a href="lwg-closed.html#1411">1411</a>, <a href="lwg-defects.html#1412">1412</a>, <a href="lwg-closed.html#1413">1413</a>, <a href="lwg-defects.html#1418">1418</a>, <a href="lwg-defects.html#1420">1420</a>, <a href="lwg-defects.html#1421">1421</a>, <a href="lwg-closed.html#1422">1422</a>, <a href="lwg-defects.html#1428">1428</a>, <a href="lwg-defects.html#1435">1435</a>, <a href="lwg-defects.html#1436">1436</a>, <a href="lwg-defects.html#1437">1437</a>, <a href="lwg-defects.html#1438">1438</a>, <a href="lwg-defects.html#1439">1439</a>, <a href="lwg-defects.html#1440">1440</a>, <a href="lwg-closed.html#1442">1442</a>, <a href="lwg-closed.html#1443">1443</a>, <a href="lwg-defects.html#1445">1445</a>, <a href="lwg-closed.html#1446">1446</a>, <a href="lwg-defects.html#1447">1447</a>, <a href="lwg-defects.html#1448">1448</a>, <a href="lwg-defects.html#1450">1450</a>, <a href="lwg-closed.html#1451">1451</a>, <a href="lwg-closed.html#1452">1452</a>, <a href="lwg-defects.html#1453">1453</a>, <a href="lwg-closed.html#1454">1454</a>, <a href="lwg-defects.html#1455">1455</a>, <a href="lwg-closed.html#1456">1456</a>, <a href="lwg-defects.html#1457">1457</a>, <a href="lwg-closed.html#1458">1458</a>, <a href="lwg-closed.html#1459">1459</a>, <a href="lwg-defects.html#1460">1460</a>, <a href="lwg-closed.html#1461">1461</a>, <a href="lwg-defects.html#1462">1462</a>, <a href="lwg-closed.html#1463">1463</a>, <a href="lwg-defects.html#1464">1464</a>, <a href="lwg-defects.html#1465">1465</a>, <a href="lwg-defects.html#1466">1466</a>, <a href="lwg-defects.html#1467">1467</a>, <a href="lwg-defects.html#1468">1468</a>, <a href="lwg-defects.html#1469">1469</a>, <a href="lwg-closed.html#1470">1470</a>, <a href="lwg-closed.html#1471">1471</a>, <a href="lwg-closed.html#1472">1472</a>, <a href="lwg-closed.html#1473">1473</a>, <a href="lwg-defects.html#1474">1474</a>, <a href="lwg-closed.html#1475">1475</a>, <a href="lwg-closed.html#1476">1476</a>, <a href="lwg-closed.html#1477">1477</a>, <a href="lwg-defects.html#1478">1478</a>, <a href="lwg-defects.html#1479">1479</a>, <a href="lwg-defects.html#1480">1480</a>, <a href="lwg-defects.html#1481">1481</a>, <a href="lwg-defects.html#1482">1482</a>, <a href="lwg-closed.html#1484">1484</a>, <a href="lwg-closed.html#1485">1485</a>, <a href="lwg-closed.html#1486">1486</a>, <a href="lwg-defects.html#1487">1487</a>, <a href="lwg-closed.html#1488">1488</a>, <a href="lwg-closed.html#1489">1489</a>, <a href="lwg-defects.html#1490">1490</a>, <a href="lwg-defects.html#1491">1491</a>, <a href="lwg-defects.html#1492">1492</a>, <a href="lwg-closed.html#1493">1493</a>, <a href="lwg-defects.html#1494">1494</a>, <a href="lwg-closed.html#1495">1495</a>, <a href="lwg-closed.html#1496">1496</a>, <a href="lwg-defects.html#1497">1497</a>, <a href="lwg-defects.html#1498">1498</a>, <a href="lwg-closed.html#1499">1499</a>, <a href="lwg-defects.html#1501">1501</a>, <a href="lwg-defects.html#1502">1502</a>, <a href="lwg-closed.html#1503">1503</a>, <a href="lwg-defects.html#1504">1504</a>, <a href="lwg-defects.html#1505">1505</a>, <a href="lwg-defects.html#1507">1507</a>, <a href="lwg-defects.html#1508">1508</a>, <a href="lwg-closed.html#1509">1509</a>, <a href="lwg-closed.html#1510">1510</a>, <a href="lwg-closed.html#1511">1511</a>, <a href="lwg-closed.html#1512">1512</a>, <a href="lwg-defects.html#1513">1513</a>, <a href="lwg-defects.html#1514">1514</a>, <a href="lwg-defects.html#1515">1515</a>.</li>
<li>Added the following Tentatively Ready issues: <a href="lwg-defects.html#1404">1404</a>, <a href="lwg-defects.html#1414">1414</a>, <a href="lwg-defects.html#1432">1432</a>, <a href="lwg-defects.html#1449">1449</a>, <a href="lwg-defects.html#1516">1516</a>, <a href="lwg-defects.html#1517">1517</a>, <a href="lwg-defects.html#1518">1518</a>, <a href="lwg-defects.html#1519">1519</a>, <a href="lwg-defects.html#1520">1520</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#1260">1260</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#1181">1181</a>, <a href="lwg-defects.html#1240">1240</a>, <a href="lwg-defects.html#1249">1249</a>, <a href="lwg-defects.html#1292">1292</a>, <a href="lwg-defects.html#1295">1295</a>, <a href="lwg-defects.html#1316">1316</a>, <a href="lwg-defects.html#1319">1319</a>, <a href="lwg-defects.html#1323">1323</a>, <a href="lwg-defects.html#1325">1325</a>, <a href="lwg-defects.html#1333">1333</a>, <a href="lwg-defects.html#1334">1334</a>, <a href="lwg-defects.html#1335">1335</a>, <a href="lwg-defects.html#1337">1337</a>, <a href="lwg-defects.html#1338">1338</a>, <a href="lwg-defects.html#1339">1339</a>, <a href="lwg-defects.html#1340">1340</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#956">956</a>, <a href="lwg-defects.html#1118">1118</a>, <a href="lwg-defects.html#1183">1183</a>, <a href="lwg-defects.html#1234">1234</a>.</li>
</ul></li>
</ul>
</li>
<li>R71: 
2010-08-25 post-Rapperswil mailing.
<ul>
<li><b>Summary:</b><ul>
<li>65 open issues, up by 2.</li>
<li>1278 closed issues, up by 7.</li>
<li>1343 issues total, up by 9.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#1335">1335</a>, <a href="lwg-defects.html#2008">2008</a>, <a href="lwg-defects.html#1337">1337</a>, <a href="lwg-defects.html#1338">1338</a>, <a href="lwg-defects.html#1339">1339</a>, <a href="lwg-defects.html#1340">1340</a>, <a href="lwg-defects.html#2009">2009</a>, <a href="lwg-defects.html#2010">2010</a>, <a href="lwg-defects.html#2011">2011</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#996">996</a>, <a href="lwg-closed.html#1119">1119</a>.</li>
<li>Changed the following issues from Open to NAD Concepts: <a href="lwg-closed.html#1076">1076</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-defects.html#953">953</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-active.html#1169">1169</a>, <a href="lwg-active.html#1175">1175</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#951">951</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#868">868</a>.</li>
<li>Changed the following issues from New to Tentatively NAD: <a href="lwg-closed.html#1190">1190</a>, <a href="lwg-closed.html#1200">1200</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Future: <a href="lwg-closed.html#1188">1188</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Future: <a href="lwg-closed.html#1173">1173</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#1198">1198</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#1171">1171</a>, <a href="lwg-defects.html#1191">1191</a>, <a href="lwg-defects.html#1207">1207</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#1187">1187</a>, <a href="lwg-defects.html#1206">1206</a>, <a href="lwg-defects.html#1278">1278</a>.</li>
</ul></li>
</ul>
</li>
<li>R70: 
2010-03-26 post-Pittsburgh mailing.
<ul>
<li><b>Summary:</b><ul>
<li>63 open issues, down by 203.</li>
<li>1271 closed issues, up by 219.</li>
<li>1334 issues total, up by 16.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD Editorial issues: <a href="lwg-defects.html#1321">1321</a>, <a href="lwg-defects.html#1329">1329</a>.</li>
<li>Added the following New issues: <a href="lwg-defects.html#1319">1319</a>, <a href="lwg-closed.html#1320">1320</a>, <a href="lwg-defects.html#1322">1322</a>, <a href="lwg-defects.html#1323">1323</a>, <a href="lwg-defects.html#1324">1324</a>, <a href="lwg-defects.html#1325">1325</a>, <a href="lwg-defects.html#1326">1326</a>, <a href="lwg-defects.html#1328">1328</a>, <a href="lwg-closed.html#1330">1330</a>, <a href="lwg-closed.html#1331">1331</a>, <a href="lwg-defects.html#1332">1332</a>, <a href="lwg-defects.html#1333">1333</a>, <a href="lwg-defects.html#1334">1334</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#1327">1327</a>.</li>
<li>Changed the following issues from Tentatively Dup to Dup: <a href="lwg-closed.html#1219">1219</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#1302">1302</a>, <a href="lwg-closed.html#1308">1308</a>, <a href="lwg-closed.html#1313">1313</a>, <a href="lwg-closed.html#1314">1314</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#887">887</a>, <a href="lwg-closed.html#1008">1008</a>, <a href="lwg-closed.html#1068">1068</a>, <a href="lwg-closed.html#1069">1069</a>, <a href="lwg-closed.html#1153">1153</a>, <a href="lwg-closed.html#1156">1156</a>, <a href="lwg-closed.html#1228">1228</a>.</li>
<li>Changed the following issues from Tentatively NAD to NAD: <a href="lwg-closed.html#631">631</a>, <a href="lwg-closed.html#726">726</a>, <a href="lwg-closed.html#959">959</a>, <a href="lwg-closed.html#1056">1056</a>, <a href="lwg-closed.html#1099">1099</a>, <a href="lwg-closed.html#1125">1125</a>, <a href="lwg-closed.html#1176">1176</a>, <a href="lwg-closed.html#1202">1202</a>, <a href="lwg-closed.html#1223">1223</a>, <a href="lwg-closed.html#1224">1224</a>, <a href="lwg-closed.html#1246">1246</a>, <a href="lwg-closed.html#1251">1251</a>, <a href="lwg-closed.html#1259">1259</a>, <a href="lwg-closed.html#1263">1263</a>, <a href="lwg-closed.html#1265">1265</a>, <a href="lwg-closed.html#1296">1296</a>.</li>
<li>Changed the following issues from Tentatively NAD Concepts to NAD Concepts: <a href="lwg-closed.html#910">910</a>, <a href="lwg-closed.html#1186">1186</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#1185">1185</a>, <a href="lwg-defects.html#1210">1210</a>, <a href="lwg-defects.html#1212">1212</a>, <a href="lwg-defects.html#1225">1225</a>, <a href="lwg-defects.html#1244">1244</a>, <a href="lwg-defects.html#1266">1266</a>, <a href="lwg-defects.html#1269">1269</a>, <a href="lwg-defects.html#1272">1272</a>, <a href="lwg-defects.html#1275">1275</a>, <a href="lwg-defects.html#1291">1291</a>, <a href="lwg-defects.html#1305">1305</a>, <a href="lwg-defects.html#1307">1307</a>, <a href="lwg-defects.html#1311">1311</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#299">299</a>, <a href="lwg-closed.html#397">397</a>, <a href="lwg-closed.html#408">408</a>, <a href="lwg-closed.html#446">446</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-defects.html#625">625</a>, <a href="lwg-defects.html#742">742</a>, <a href="lwg-defects.html#834">834</a>, <a href="lwg-closed.html#915">915</a>, <a href="lwg-defects.html#1093">1093</a>, <a href="lwg-defects.html#1151">1151</a>, <a href="lwg-defects.html#1211">1211</a>, <a href="lwg-defects.html#1248">1248</a>.</li>
<li>Changed the following issues from Ready to NAD Editorial: <a href="lwg-defects.html#485">485</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#983">983</a>, <a href="lwg-defects.html#1100">1100</a>, <a href="lwg-defects.html#1135">1135</a>.</li>
<li>Changed the following issues from Tentatively NAD Editorial to NAD Editorial: <a href="lwg-defects.html#815">815</a>, <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#889">889</a>, <a href="lwg-defects.html#1106">1106</a>, <a href="lwg-closed.html#1115">1115</a>, <a href="lwg-closed.html#1233">1233</a>, <a href="lwg-closed.html#1239">1239</a>, <a href="lwg-defects.html#1258">1258</a>, <a href="lwg-defects.html#1283">1283</a>, <a href="lwg-closed.html#1301">1301</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="lwg-defects.html#1090">1090</a>, <a href="lwg-defects.html#1226">1226</a>, <a href="lwg-defects.html#1273">1273</a>, <a href="lwg-defects.html#1274">1274</a>, <a href="lwg-defects.html#1293">1293</a>, <a href="lwg-defects.html#1300">1300</a>, <a href="lwg-defects.html#1304">1304</a>, <a href="lwg-closed.html#1315">1315</a>.</li>
<li>Changed the following issues from New to NAD Future: <a href="lwg-closed.html#1154">1154</a>, <a href="lwg-closed.html#1317">1317</a>.</li>
<li>Changed the following issues from Ready to NAD Future: <a href="lwg-closed.html#1052">1052</a>.</li>
<li>Changed the following issues from Tentatively NAD Future to NAD Future: <a href="lwg-closed.html#1112">1112</a>, <a href="lwg-closed.html#1121">1121</a>, <a href="lwg-closed.html#1201">1201</a>, <a href="lwg-closed.html#1238">1238</a>, <a href="lwg-closed.html#1282">1282</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#1234">1234</a>, <a href="lwg-defects.html#1268">1268</a>.</li>
<li>Changed the following issues from Tentatively Ready to Open: <a href="lwg-closed.html#579">579</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#1187">1187</a>, <a href="lwg-defects.html#1206">1206</a>, <a href="lwg-defects.html#1278">1278</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#1281">1281</a>.</li>
<li>Changed the following issues from Ready to Review: <a href="lwg-defects.html#868">868</a>.</li>
<li>Changed the following issues from New to WP: <a href="lwg-defects.html#1159">1159</a>.</li>
<li>Changed the following issues from Open to WP: <a href="lwg-defects.html#427">427</a>, <a href="lwg-defects.html#430">430</a>, <a href="lwg-defects.html#774">774</a>, <a href="lwg-defects.html#819">819</a>, <a href="lwg-defects.html#835">835</a>, <a href="lwg-defects.html#861">861</a>, <a href="lwg-defects.html#885">885</a>, <a href="lwg-defects.html#896">896</a>, <a href="lwg-defects.html#900">900</a>, <a href="lwg-defects.html#911">911</a>, <a href="lwg-defects.html#1079">1079</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#296">296</a>, <a href="lwg-defects.html#471">471</a>, <a href="lwg-defects.html#473">473</a>, <a href="lwg-defects.html#539">539</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-defects.html#854">854</a>, <a href="lwg-defects.html#860">860</a>, <a href="lwg-defects.html#865">865</a>, <a href="lwg-defects.html#871">871</a>, <a href="lwg-defects.html#872">872</a>, <a href="lwg-defects.html#920">920</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-defects.html#957">957</a>, <a href="lwg-defects.html#960">960</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#963">963</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#1011">1011</a>, <a href="lwg-defects.html#1030">1030</a>, <a href="lwg-defects.html#1094">1094</a>, <a href="lwg-defects.html#1095">1095</a>, <a href="lwg-defects.html#1097">1097</a>, <a href="lwg-defects.html#1098">1098</a>, <a href="lwg-defects.html#1104">1104</a>, <a href="lwg-defects.html#1123">1123</a>, <a href="lwg-defects.html#1134">1134</a>, <a href="lwg-defects.html#1136">1136</a>, <a href="lwg-defects.html#1144">1144</a>, <a href="lwg-defects.html#1157">1157</a>, <a href="lwg-defects.html#1194">1194</a>, <a href="lwg-defects.html#1204">1204</a>, <a href="lwg-defects.html#1216">1216</a>, <a href="lwg-defects.html#1227">1227</a>, <a href="lwg-defects.html#1237">1237</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="lwg-defects.html#556">556</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#780">780</a>, <a href="lwg-defects.html#811">811</a>, <a href="lwg-defects.html#817">817</a>, <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#891">891</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-defects.html#987">987</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-defects.html#1033">1033</a>, <a href="lwg-defects.html#1034">1034</a>, <a href="lwg-defects.html#1071">1071</a>, <a href="lwg-defects.html#1089">1089</a>, <a href="lwg-defects.html#1108">1108</a>, <a href="lwg-defects.html#1110">1110</a>, <a href="lwg-defects.html#1113">1113</a>, <a href="lwg-defects.html#1114">1114</a>, <a href="lwg-defects.html#1126">1126</a>, <a href="lwg-defects.html#1130">1130</a>, <a href="lwg-defects.html#1131">1131</a>, <a href="lwg-defects.html#1133">1133</a>, <a href="lwg-defects.html#1137">1137</a>, <a href="lwg-defects.html#1138">1138</a>, <a href="lwg-defects.html#1152">1152</a>, <a href="lwg-defects.html#1158">1158</a>, <a href="lwg-defects.html#1170">1170</a>, <a href="lwg-defects.html#1177">1177</a>, <a href="lwg-defects.html#1180">1180</a>, <a href="lwg-defects.html#1182">1182</a>, <a href="lwg-defects.html#1189">1189</a>, <a href="lwg-defects.html#1192">1192</a>, <a href="lwg-defects.html#1193">1193</a>, <a href="lwg-defects.html#1195">1195</a>, <a href="lwg-defects.html#1197">1197</a>, <a href="lwg-defects.html#1199">1199</a>, <a href="lwg-defects.html#1205">1205</a>, <a href="lwg-defects.html#1208">1208</a>, <a href="lwg-defects.html#1209">1209</a>, <a href="lwg-defects.html#1218">1218</a>, <a href="lwg-defects.html#1220">1220</a>, <a href="lwg-defects.html#1221">1221</a>, <a href="lwg-defects.html#1222">1222</a>, <a href="lwg-defects.html#1231">1231</a>, <a href="lwg-defects.html#1241">1241</a>, <a href="lwg-defects.html#1245">1245</a>, <a href="lwg-defects.html#1247">1247</a>, <a href="lwg-defects.html#1250">1250</a>, <a href="lwg-defects.html#1254">1254</a>, <a href="lwg-defects.html#1255">1255</a>, <a href="lwg-defects.html#1256">1256</a>, <a href="lwg-defects.html#1257">1257</a>, <a href="lwg-defects.html#1261">1261</a>, <a href="lwg-defects.html#1262">1262</a>, <a href="lwg-defects.html#1264">1264</a>, <a href="lwg-defects.html#1267">1267</a>, <a href="lwg-defects.html#1270">1270</a>, <a href="lwg-defects.html#1271">1271</a>, <a href="lwg-defects.html#1276">1276</a>, <a href="lwg-defects.html#1277">1277</a>, <a href="lwg-defects.html#1280">1280</a>, <a href="lwg-defects.html#1284">1284</a>, <a href="lwg-defects.html#1285">1285</a>, <a href="lwg-defects.html#1286">1286</a>, <a href="lwg-defects.html#1287">1287</a>, <a href="lwg-defects.html#1288">1288</a>, <a href="lwg-defects.html#1298">1298</a>, <a href="lwg-defects.html#1299">1299</a>, <a href="lwg-defects.html#1303">1303</a>, <a href="lwg-defects.html#1306">1306</a>, <a href="lwg-defects.html#1309">1309</a>, <a href="lwg-defects.html#1312">1312</a>.</li>
</ul></li>
</ul>
</li>
<li>R69: 
2010-02-12 pre-Pittsburgh mailing.
<ul>
<li><b>Summary:</b><ul>
<li>266 open issues, up by 61.</li>
<li>1052 closed issues, down by 3.</li>
<li>1318 issues total, up by 58.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#1266">1266</a>, <a href="lwg-defects.html#1268">1268</a>, <a href="lwg-defects.html#1269">1269</a>, <a href="lwg-defects.html#1272">1272</a>, <a href="lwg-defects.html#1275">1275</a>, <a href="lwg-defects.html#1278">1278</a>, <a href="lwg-defects.html#1279">1279</a>, <a href="lwg-defects.html#1281">1281</a>, <a href="lwg-closed.html#1289">1289</a>, <a href="lwg-defects.html#1290">1290</a>, <a href="lwg-defects.html#1291">1291</a>, <a href="lwg-defects.html#1292">1292</a>, <a href="lwg-defects.html#1294">1294</a>, <a href="lwg-defects.html#1295">1295</a>, <a href="lwg-defects.html#1297">1297</a>, <a href="lwg-closed.html#1302">1302</a>, <a href="lwg-defects.html#1305">1305</a>, <a href="lwg-defects.html#1307">1307</a>, <a href="lwg-closed.html#1308">1308</a>, <a href="lwg-defects.html#1310">1310</a>, <a href="lwg-defects.html#1311">1311</a>, <a href="lwg-closed.html#1313">1313</a>, <a href="lwg-closed.html#1314">1314</a>, <a href="lwg-defects.html#1316">1316</a>, <a href="lwg-closed.html#1317">1317</a>, <a href="lwg-closed.html#1318">1318</a>.</li>
<li>Added the following Tentatively NAD issues: <a href="lwg-closed.html#1263">1263</a>, <a href="lwg-closed.html#1265">1265</a>, <a href="lwg-closed.html#1296">1296</a>.</li>
<li>Added the following Tentatively NAD Editorial issues: <a href="lwg-defects.html#1283">1283</a>, <a href="lwg-closed.html#1301">1301</a>.</li>
<li>Added the following Tentatively NAD Future issues: <a href="lwg-closed.html#1282">1282</a>.</li>
<li>Added the following Tentatively Ready issues: <a href="lwg-defects.html#1261">1261</a>, <a href="lwg-defects.html#1262">1262</a>, <a href="lwg-defects.html#1264">1264</a>, <a href="lwg-defects.html#1267">1267</a>, <a href="lwg-defects.html#1270">1270</a>, <a href="lwg-defects.html#1271">1271</a>, <a href="lwg-defects.html#1273">1273</a>, <a href="lwg-defects.html#1274">1274</a>, <a href="lwg-defects.html#1276">1276</a>, <a href="lwg-defects.html#1277">1277</a>, <a href="lwg-defects.html#1280">1280</a>, <a href="lwg-defects.html#1284">1284</a>, <a href="lwg-defects.html#1285">1285</a>, <a href="lwg-defects.html#1286">1286</a>, <a href="lwg-defects.html#1287">1287</a>, <a href="lwg-defects.html#1288">1288</a>, <a href="lwg-defects.html#1293">1293</a>, <a href="lwg-defects.html#1298">1298</a>, <a href="lwg-defects.html#1299">1299</a>, <a href="lwg-defects.html#1300">1300</a>, <a href="lwg-defects.html#1303">1303</a>, <a href="lwg-defects.html#1304">1304</a>, <a href="lwg-defects.html#1306">1306</a>, <a href="lwg-defects.html#1309">1309</a>, <a href="lwg-defects.html#1312">1312</a>, <a href="lwg-closed.html#1315">1315</a>.</li>
<li>Changed the following issues from NAD to NAD Editorial: <a href="lwg-closed.html#101">101</a>.</li>
<li>Changed the following issues from NAD Future to Open: <a href="lwg-defects.html#1248">1248</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#1207">1207</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="lwg-defects.html#1079">1079</a>.</li>
<li>Changed the following issues from New to Tentatively Dup: <a href="lwg-closed.html#1219">1219</a>.</li>
<li>Changed the following issues from New to Tentatively NAD: <a href="lwg-closed.html#1125">1125</a>, <a href="lwg-closed.html#1176">1176</a>, <a href="lwg-closed.html#1202">1202</a>, <a href="lwg-closed.html#1223">1223</a>, <a href="lwg-closed.html#1224">1224</a>, <a href="lwg-closed.html#1246">1246</a>, <a href="lwg-closed.html#1251">1251</a>, <a href="lwg-closed.html#1259">1259</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD: <a href="lwg-closed.html#726">726</a>, <a href="lwg-closed.html#959">959</a>.</li>
<li>Changed the following issues from Review to Tentatively NAD: <a href="lwg-closed.html#631">631</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Concepts: <a href="lwg-closed.html#910">910</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="lwg-defects.html#1258">1258</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="lwg-defects.html#815">815</a>, <a href="lwg-defects.html#1106">1106</a>.</li>
<li>Changed the following issues from Ready to Tentatively NAD Editorial: <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#889">889</a>.</li>
<li>Changed the following issues from NAD to Tentatively Ready: <a href="lwg-closed.html#579">579</a>.</li>
<li>Changed the following issues from NAD Editorial to Tentatively Ready: <a href="lwg-defects.html#1195">1195</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#1131">1131</a>, <a href="lwg-defects.html#1133">1133</a>, <a href="lwg-defects.html#1137">1137</a>, <a href="lwg-defects.html#1170">1170</a>, <a href="lwg-defects.html#1180">1180</a>, <a href="lwg-defects.html#1182">1182</a>, <a href="lwg-defects.html#1193">1193</a>, <a href="lwg-defects.html#1197">1197</a>, <a href="lwg-defects.html#1199">1199</a>, <a href="lwg-defects.html#1205">1205</a>, <a href="lwg-defects.html#1209">1209</a>, <a href="lwg-defects.html#1218">1218</a>, <a href="lwg-defects.html#1221">1221</a>, <a href="lwg-defects.html#1222">1222</a>, <a href="lwg-defects.html#1245">1245</a>, <a href="lwg-defects.html#1250">1250</a>, <a href="lwg-defects.html#1254">1254</a>, <a href="lwg-defects.html#1255">1255</a>, <a href="lwg-defects.html#1256">1256</a>, <a href="lwg-defects.html#1257">1257</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#811">811</a>, <a href="lwg-defects.html#817">817</a>, <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#891">891</a>, <a href="lwg-defects.html#1033">1033</a>, <a href="lwg-defects.html#1034">1034</a>, <a href="lwg-defects.html#1089">1089</a>, <a href="lwg-defects.html#1110">1110</a>.</li>
<li>Changed the following issues from Ready to Tentatively Ready: <a href="lwg-defects.html#893">893</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-defects.html#1177">1177</a>.</li>
<li>Changed the following issues from Review to Tentatively Ready: <a href="lwg-defects.html#556">556</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#780">780</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-defects.html#1130">1130</a>, <a href="lwg-defects.html#1247">1247</a>.</li>
<li>Changed the following issues from Pending WP to WP: <a href="lwg-defects.html#970">970</a>.</li>
</ul></li>
</ul>
</li>
<li>R68: 
2009-11-06 post-Santa Cruz mailing.
<ul>
<li><b>Summary:</b><ul>
<li>205 open issues, down by 77.</li>
<li>1055 closed issues, up by 120.</li>
<li>1260 issues total, up by 43.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following Dup issues: <a href="lwg-closed.html#1230">1230</a>.</li>
<li>Added the following NAD issues: <a href="lwg-defects.html#1229">1229</a>, <a href="lwg-closed.html#1236">1236</a>, <a href="lwg-closed.html#1243">1243</a>.</li>
<li>Added the following NAD Editorial issues: <a href="lwg-closed.html#1232">1232</a>.</li>
<li>Added the following NAD Future issues: <a href="lwg-closed.html#1235">1235</a>, <a href="lwg-closed.html#1242">1242</a>, <a href="lwg-defects.html#1248">1248</a>.</li>
<li>Added the following New issues: <a href="lwg-defects.html#1218">1218</a>, <a href="lwg-closed.html#1219">1219</a>, <a href="lwg-defects.html#1221">1221</a>, <a href="lwg-defects.html#1222">1222</a>, <a href="lwg-closed.html#1223">1223</a>, <a href="lwg-closed.html#1224">1224</a>, <a href="lwg-defects.html#1225">1225</a>, <a href="lwg-defects.html#1234">1234</a>, <a href="lwg-defects.html#1240">1240</a>, <a href="lwg-defects.html#1244">1244</a>, <a href="lwg-defects.html#1245">1245</a>, <a href="lwg-closed.html#1246">1246</a>, <a href="lwg-defects.html#1249">1249</a>, <a href="lwg-defects.html#1250">1250</a>, <a href="lwg-closed.html#1251">1251</a>, <a href="lwg-defects.html#1252">1252</a>, <a href="lwg-defects.html#1253">1253</a>, <a href="lwg-defects.html#1254">1254</a>, <a href="lwg-defects.html#1255">1255</a>, <a href="lwg-defects.html#1256">1256</a>, <a href="lwg-defects.html#1257">1257</a>, <a href="lwg-defects.html#1258">1258</a>, <a href="lwg-closed.html#1259">1259</a>, <a href="lwg-defects.html#1260">1260</a>.</li>
<li>Added the following Open issues: <a href="lwg-closed.html#1228">1228</a>.</li>
<li>Added the following Ready issues: <a href="lwg-defects.html#1227">1227</a>, <a href="lwg-defects.html#1237">1237</a>.</li>
<li>Added the following Review issues: <a href="lwg-defects.html#1247">1247</a>.</li>
<li>Added the following Tentatively NAD Editorial issues: <a href="lwg-closed.html#1233">1233</a>, <a href="lwg-closed.html#1239">1239</a>.</li>
<li>Added the following Tentatively NAD Future issues: <a href="lwg-closed.html#1238">1238</a>.</li>
<li>Added the following Tentatively Ready issues: <a href="lwg-defects.html#1220">1220</a>, <a href="lwg-defects.html#1226">1226</a>, <a href="lwg-defects.html#1231">1231</a>, <a href="lwg-defects.html#1241">1241</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#1132">1132</a>, <a href="lwg-closed.html#1148">1148</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#96">96</a>, <a href="lwg-closed.html#458">458</a>, <a href="lwg-closed.html#463">463</a>, <a href="lwg-closed.html#916">916</a>, <a href="lwg-closed.html#917">917</a>, <a href="lwg-closed.html#919">919</a>, <a href="lwg-closed.html#955">955</a>, <a href="lwg-closed.html#977">977</a>, <a href="lwg-closed.html#1009">1009</a>, <a href="lwg-closed.html#1020">1020</a>, <a href="lwg-closed.html#1035">1035</a>, <a href="lwg-closed.html#1042">1042</a>, <a href="lwg-closed.html#1051">1051</a>, <a href="lwg-closed.html#1064">1064</a>.</li>
<li>Changed the following issues from Review to NAD: <a href="lwg-closed.html#668">668</a>, <a href="lwg-closed.html#930">930</a>, <a href="lwg-closed.html#1091">1091</a>, <a href="lwg-closed.html#1102">1102</a>.</li>
<li>Changed the following issues from Tentatively NAD to NAD: <a href="lwg-closed.html#588">588</a>, <a href="lwg-closed.html#617">617</a>, <a href="lwg-closed.html#971">971</a>.</li>
<li>Changed the following issues from Tentatively NAD Future to NAD: <a href="lwg-closed.html#1062">1062</a>.</li>
<li>Changed the following issues from NAD Concepts to NAD Editorial: <a href="lwg-defects.html#1143">1143</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#1116">1116</a>, <a href="lwg-defects.html#1117">1117</a>, <a href="lwg-defects.html#1122">1122</a>, <a href="lwg-defects.html#1129">1129</a>, <a href="lwg-defects.html#1145">1145</a>, <a href="lwg-defects.html#1146">1146</a>, <a href="lwg-defects.html#1147">1147</a>, <a href="lwg-closed.html#1155">1155</a>, <a href="lwg-defects.html#1166">1166</a>, <a href="lwg-defects.html#1172">1172</a>, <a href="lwg-defects.html#1174">1174</a>, <a href="lwg-closed.html#1179">1179</a>, <a href="lwg-defects.html#1195">1195</a>, <a href="lwg-defects.html#1196">1196</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-defects.html#431">431</a>, <a href="lwg-closed.html#580">580</a>, <a href="lwg-defects.html#635">635</a>, <a href="lwg-defects.html#719">719</a>, <a href="lwg-defects.html#823">823</a>, <a href="lwg-defects.html#827">827</a>, <a href="lwg-closed.html#879">879</a>, <a href="lwg-defects.html#880">880</a>, <a href="lwg-defects.html#908">908</a>, <a href="lwg-defects.html#923">923</a>, <a href="lwg-defects.html#924">924</a>, <a href="lwg-closed.html#926">926</a>, <a href="lwg-defects.html#944">944</a>, <a href="lwg-defects.html#947">947</a>, <a href="lwg-defects.html#958">958</a>, <a href="lwg-defects.html#1046">1046</a>, <a href="lwg-defects.html#1048">1048</a>, <a href="lwg-defects.html#1054">1054</a>, <a href="lwg-defects.html#1055">1055</a>, <a href="lwg-defects.html#1075">1075</a>, <a href="lwg-defects.html#1088">1088</a>, <a href="lwg-defects.html#1160">1160</a>, <a href="lwg-defects.html#1161">1161</a>, <a href="lwg-defects.html#1162">1162</a>, <a href="lwg-defects.html#1163">1163</a>, <a href="lwg-defects.html#1165">1165</a>.</li>
<li>Changed the following issues from Review to NAD Editorial: <a href="lwg-defects.html#828">828</a>, <a href="lwg-defects.html#897">897</a>, <a href="lwg-defects.html#976">976</a>, <a href="lwg-defects.html#1043">1043</a>, <a href="lwg-defects.html#1047">1047</a>, <a href="lwg-defects.html#1049">1049</a>, <a href="lwg-defects.html#1050">1050</a>.</li>
<li>Changed the following issues from New to NAD Future: <a href="lwg-closed.html#1120">1120</a>, <a href="lwg-closed.html#1150">1150</a>, <a href="lwg-closed.html#1184">1184</a>, <a href="lwg-closed.html#1203">1203</a>, <a href="lwg-closed.html#1217">1217</a>.</li>
<li>Changed the following issues from Open to NAD Future: <a href="lwg-closed.html#484">484</a>, <a href="lwg-closed.html#532">532</a>, <a href="lwg-closed.html#851">851</a>, <a href="lwg-closed.html#933">933</a>, <a href="lwg-closed.html#935">935</a>, <a href="lwg-closed.html#936">936</a>, <a href="lwg-closed.html#961">961</a>, <a href="lwg-closed.html#1041">1041</a>, <a href="lwg-closed.html#1053">1053</a>.</li>
<li>Changed the following issues from Tentatively NAD Future to NAD Future: <a href="lwg-closed.html#1031">1031</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#1118">1118</a>, <a href="lwg-closed.html#1119">1119</a>, <a href="lwg-defects.html#1151">1151</a>, <a href="lwg-closed.html#1153">1153</a>, <a href="lwg-closed.html#1156">1156</a>, <a href="lwg-defects.html#1171">1171</a>, <a href="lwg-closed.html#1173">1173</a>, <a href="lwg-defects.html#1183">1183</a>, <a href="lwg-defects.html#1191">1191</a>, <a href="lwg-defects.html#1211">1211</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="lwg-defects.html#430">430</a>, <a href="lwg-defects.html#834">834</a>.</li>
<li>Changed the following issues from Review to Open: <a href="lwg-closed.html#397">397</a>, <a href="lwg-closed.html#408">408</a>, <a href="lwg-defects.html#835">835</a>.</li>
<li>Changed the following issues from Tentatively NAD to Open: <a href="lwg-defects.html#625">625</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#1123">1123</a>, <a href="lwg-defects.html#1134">1134</a>, <a href="lwg-defects.html#1135">1135</a>, <a href="lwg-defects.html#1136">1136</a>, <a href="lwg-defects.html#1144">1144</a>, <a href="lwg-defects.html#1177">1177</a>, <a href="lwg-defects.html#1194">1194</a>, <a href="lwg-defects.html#1204">1204</a>, <a href="lwg-defects.html#1216">1216</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#296">296</a>, <a href="lwg-defects.html#471">471</a>, <a href="lwg-defects.html#485">485</a>, <a href="lwg-defects.html#539">539</a>, <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#860">860</a>, <a href="lwg-defects.html#865">865</a>, <a href="lwg-defects.html#872">872</a>, <a href="lwg-defects.html#920">920</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#960">960</a>, <a href="lwg-defects.html#963">963</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-defects.html#1011">1011</a>, <a href="lwg-defects.html#1030">1030</a>, <a href="lwg-defects.html#1079">1079</a>, <a href="lwg-defects.html#1098">1098</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#473">473</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-defects.html#854">854</a>, <a href="lwg-defects.html#868">868</a>, <a href="lwg-defects.html#871">871</a>, <a href="lwg-defects.html#889">889</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-defects.html#957">957</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>, <a href="lwg-defects.html#983">983</a>, <a href="lwg-closed.html#1052">1052</a>, <a href="lwg-defects.html#1094">1094</a>, <a href="lwg-defects.html#1095">1095</a>, <a href="lwg-defects.html#1097">1097</a>, <a href="lwg-defects.html#1100">1100</a>, <a href="lwg-defects.html#1104">1104</a>, <a href="lwg-defects.html#1157">1157</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#1130">1130</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#556">556</a>, <a href="lwg-closed.html#631">631</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#929">929</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD: <a href="lwg-closed.html#1056">1056</a>, <a href="lwg-closed.html#1099">1099</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Concepts: <a href="lwg-closed.html#1186">1186</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="lwg-closed.html#1115">1115</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Future: <a href="lwg-closed.html#1121">1121</a>, <a href="lwg-closed.html#1201">1201</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Future: <a href="lwg-closed.html#1112">1112</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#1126">1126</a>, <a href="lwg-defects.html#1138">1138</a>, <a href="lwg-defects.html#1152">1152</a>, <a href="lwg-defects.html#1158">1158</a>, <a href="lwg-defects.html#1189">1189</a>, <a href="lwg-defects.html#1192">1192</a>, <a href="lwg-defects.html#1208">1208</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#987">987</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-defects.html#1071">1071</a>, <a href="lwg-defects.html#1090">1090</a>, <a href="lwg-defects.html#1108">1108</a>, <a href="lwg-defects.html#1113">1113</a>, <a href="lwg-defects.html#1114">1114</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#149">149</a>, <a href="lwg-defects.html#419">419</a>, <a href="lwg-defects.html#498">498</a>, <a href="lwg-defects.html#564">564</a>, <a href="lwg-defects.html#565">565</a>, <a href="lwg-defects.html#630">630</a>, <a href="lwg-defects.html#659">659</a>, <a href="lwg-defects.html#696">696</a>, <a href="lwg-defects.html#711">711</a>, <a href="lwg-defects.html#716">716</a>, <a href="lwg-defects.html#723">723</a>, <a href="lwg-defects.html#788">788</a>, <a href="lwg-closed.html#822">822</a>, <a href="lwg-defects.html#838">838</a>, <a href="lwg-defects.html#847">847</a>, <a href="lwg-defects.html#857">857</a>, <a href="lwg-defects.html#859">859</a>, <a href="lwg-defects.html#876">876</a>, <a href="lwg-defects.html#881">881</a>, <a href="lwg-defects.html#883">883</a>, <a href="lwg-defects.html#886">886</a>, <a href="lwg-defects.html#934">934</a>, <a href="lwg-defects.html#1004">1004</a>, <a href="lwg-defects.html#1178">1178</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="lwg-defects.html#1012">1012</a>, <a href="lwg-defects.html#1019">1019</a>.</li>
</ul></li>
</ul>
</li>
<li>R67: 
2009-09-25 pre-Santa Cruz mailing.
<ul>
<li><b>Summary:</b><ul>
<li>282 open issues, up by 32.</li>
<li>935 closed issues, down by 1.</li>
<li>1217 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#1187">1187</a>, <a href="lwg-closed.html#1188">1188</a>, <a href="lwg-defects.html#1189">1189</a>, <a href="lwg-closed.html#1190">1190</a>, <a href="lwg-defects.html#1191">1191</a>, <a href="lwg-defects.html#1192">1192</a>, <a href="lwg-defects.html#1193">1193</a>, <a href="lwg-defects.html#1194">1194</a>, <a href="lwg-defects.html#1195">1195</a>, <a href="lwg-defects.html#1196">1196</a>, <a href="lwg-defects.html#1197">1197</a>, <a href="lwg-defects.html#1198">1198</a>, <a href="lwg-defects.html#1199">1199</a>, <a href="lwg-closed.html#1200">1200</a>, <a href="lwg-closed.html#1201">1201</a>, <a href="lwg-closed.html#1202">1202</a>, <a href="lwg-closed.html#1203">1203</a>, <a href="lwg-defects.html#1204">1204</a>, <a href="lwg-defects.html#1205">1205</a>, <a href="lwg-defects.html#1206">1206</a>, <a href="lwg-defects.html#1207">1207</a>, <a href="lwg-defects.html#1208">1208</a>, <a href="lwg-defects.html#1209">1209</a>, <a href="lwg-defects.html#1210">1210</a>, <a href="lwg-defects.html#1211">1211</a>, <a href="lwg-defects.html#1212">1212</a>, <a href="lwg-active.html#1213">1213</a>, <a href="lwg-defects.html#1214">1214</a>, <a href="lwg-defects.html#1215">1215</a>, <a href="lwg-defects.html#1216">1216</a>, <a href="lwg-closed.html#1217">1217</a>.</li>
<li>Changed the following issues from NAD to Open: <a href="lwg-defects.html#296">296</a>.</li>
<li>Changed the following issues from WP to Pending WP: <a href="lwg-defects.html#970">970</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#976">976</a>, <a href="lwg-closed.html#1052">1052</a>.</li>
<li>Changed the following issues from Ready to Review: <a href="lwg-defects.html#780">780</a>.</li>
</ul></li>
</ul>
</li>
<li>R66: 
2009-07-31 post-Frankfurt mailing.
<ul>
<li><b>Summary:</b><ul>
<li>250 open issues, down by 128.</li>
<li>936 closed issues, up by 171.</li>
<li>1186 issues total, up by 43.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issues: <a href="lwg-closed.html#1164">1164</a>.</li>
<li>Added the following NAD Concepts issues: <a href="lwg-closed.html#1149">1149</a>, <a href="lwg-closed.html#1167">1167</a>.</li>
<li>Added the following NAD Editorial issues: <a href="lwg-closed.html#1168">1168</a>.</li>
<li>Added the following New issues: <a href="lwg-defects.html#1144">1144</a>, <a href="lwg-defects.html#1145">1145</a>, <a href="lwg-defects.html#1146">1146</a>, <a href="lwg-defects.html#1147">1147</a>, <a href="lwg-closed.html#1148">1148</a>, <a href="lwg-closed.html#1150">1150</a>, <a href="lwg-defects.html#1151">1151</a>, <a href="lwg-defects.html#1152">1152</a>, <a href="lwg-closed.html#1153">1153</a>, <a href="lwg-closed.html#1154">1154</a>, <a href="lwg-closed.html#1155">1155</a>, <a href="lwg-closed.html#1156">1156</a>, <a href="lwg-defects.html#1158">1158</a>, <a href="lwg-defects.html#1159">1159</a>, <a href="lwg-defects.html#1166">1166</a>, <a href="lwg-active.html#1169">1169</a>, <a href="lwg-defects.html#1170">1170</a>, <a href="lwg-defects.html#1171">1171</a>, <a href="lwg-defects.html#1172">1172</a>, <a href="lwg-closed.html#1173">1173</a>, <a href="lwg-defects.html#1174">1174</a>, <a href="lwg-active.html#1175">1175</a>, <a href="lwg-closed.html#1176">1176</a>, <a href="lwg-defects.html#1177">1177</a>, <a href="lwg-closed.html#1179">1179</a>, <a href="lwg-defects.html#1180">1180</a>, <a href="lwg-defects.html#1181">1181</a>, <a href="lwg-defects.html#1182">1182</a>, <a href="lwg-defects.html#1183">1183</a>, <a href="lwg-closed.html#1184">1184</a>, <a href="lwg-defects.html#1185">1185</a>, <a href="lwg-closed.html#1186">1186</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#1160">1160</a>, <a href="lwg-defects.html#1161">1161</a>, <a href="lwg-defects.html#1162">1162</a>, <a href="lwg-defects.html#1163">1163</a>, <a href="lwg-defects.html#1165">1165</a>.</li>
<li>Added the following Ready issues: <a href="lwg-defects.html#1178">1178</a>.</li>
<li>Added the following Review issues: <a href="lwg-defects.html#1157">1157</a>.</li>
<li>Changed the following issues from Open to Dup: <a href="lwg-closed.html#750">750</a>, <a href="lwg-closed.html#895">895</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#111">111</a>, <a href="lwg-closed.html#128">128</a>, <a href="lwg-closed.html#138">138</a>, <a href="lwg-closed.html#190">190</a>, <a href="lwg-closed.html#219">219</a>, <a href="lwg-closed.html#290">290</a>, <a href="lwg-closed.html#309">309</a>, <a href="lwg-closed.html#342">342</a>, <a href="lwg-defects.html#343">343</a>, <a href="lwg-closed.html#382">382</a>, <a href="lwg-closed.html#394">394</a>, <a href="lwg-closed.html#398">398</a>, <a href="lwg-closed.html#417">417</a>, <a href="lwg-closed.html#418">418</a>, <a href="lwg-closed.html#421">421</a>, <a href="lwg-closed.html#459">459</a>, <a href="lwg-closed.html#466">466</a>, <a href="lwg-closed.html#492">492</a>, <a href="lwg-closed.html#502">502</a>, <a href="lwg-closed.html#503">503</a>, <a href="lwg-closed.html#546">546</a>, <a href="lwg-closed.html#573">573</a>, <a href="lwg-closed.html#582">582</a>, <a href="lwg-closed.html#585">585</a>, <a href="lwg-closed.html#597">597</a>, <a href="lwg-closed.html#606">606</a>, <a href="lwg-closed.html#614">614</a>, <a href="lwg-closed.html#632">632</a>, <a href="lwg-closed.html#721">721</a>, <a href="lwg-closed.html#747">747</a>, <a href="lwg-closed.html#751">751</a>, <a href="lwg-closed.html#833">833</a>, <a href="lwg-closed.html#941">941</a>, <a href="lwg-closed.html#992">992</a>.</li>
<li>Changed the following issues from Review to NAD: <a href="lwg-closed.html#1003">1003</a>.</li>
<li>Changed the following issues from Tentatively NAD to NAD: <a href="lwg-closed.html#568">568</a>, <a href="lwg-closed.html#644">644</a>, <a href="lwg-closed.html#667">667</a>, <a href="lwg-closed.html#669">669</a>, <a href="lwg-closed.html#701">701</a>, <a href="lwg-closed.html#702">702</a>, <a href="lwg-closed.html#785">785</a>, <a href="lwg-closed.html#863">863</a>, <a href="lwg-closed.html#901">901</a>, <a href="lwg-closed.html#903">903</a>, <a href="lwg-closed.html#946">946</a>, <a href="lwg-closed.html#988">988</a>, <a href="lwg-closed.html#995">995</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD: <a href="lwg-closed.html#1002">1002</a>.</li>
<li>Changed the following issues from New to NAD Concepts: <a href="lwg-closed.html#1124">1124</a>, <a href="lwg-closed.html#1127">1127</a>, <a href="lwg-closed.html#1128">1128</a>, <a href="lwg-closed.html#1139">1139</a>, <a href="lwg-closed.html#1140">1140</a>, <a href="lwg-closed.html#1141">1141</a>, <a href="lwg-closed.html#1142">1142</a>, <a href="lwg-defects.html#1143">1143</a>.</li>
<li>Changed the following issues from Open to NAD Concepts: <a href="lwg-closed.html#902">902</a>, <a href="lwg-closed.html#989">989</a>, <a href="lwg-closed.html#1000">1000</a>, <a href="lwg-closed.html#1007">1007</a>, <a href="lwg-closed.html#1010">1010</a>, <a href="lwg-closed.html#1015">1015</a>, <a href="lwg-closed.html#1016">1016</a>, <a href="lwg-closed.html#1017">1017</a>, <a href="lwg-closed.html#1018">1018</a>, <a href="lwg-closed.html#1026">1026</a>, <a href="lwg-closed.html#1027">1027</a>, <a href="lwg-closed.html#1028">1028</a>, <a href="lwg-closed.html#1029">1029</a>, <a href="lwg-closed.html#1032">1032</a>, <a href="lwg-closed.html#1036">1036</a>, <a href="lwg-closed.html#1057">1057</a>, <a href="lwg-closed.html#1059">1059</a>, <a href="lwg-closed.html#1072">1072</a>, <a href="lwg-closed.html#1078">1078</a>, <a href="lwg-closed.html#1081">1081</a>, <a href="lwg-closed.html#1082">1082</a>, <a href="lwg-closed.html#1083">1083</a>, <a href="lwg-closed.html#1084">1084</a>, <a href="lwg-closed.html#1085">1085</a>, <a href="lwg-closed.html#1086">1086</a>, <a href="lwg-closed.html#1092">1092</a>, <a href="lwg-closed.html#1096">1096</a>, <a href="lwg-closed.html#1105">1105</a>.</li>
<li>Changed the following issues from Review to NAD Concepts: <a href="lwg-closed.html#1001">1001</a>, <a href="lwg-closed.html#1005">1005</a>, <a href="lwg-closed.html#1080">1080</a>, <a href="lwg-closed.html#1087">1087</a>, <a href="lwg-closed.html#1111">1111</a>.</li>
<li>Changed the following issues from Tentatively NAD to NAD Concepts: <a href="lwg-closed.html#912">912</a>, <a href="lwg-closed.html#918">918</a>, <a href="lwg-closed.html#1074">1074</a>.</li>
<li>Changed the following issues from Tentatively NAD Editorial to NAD Concepts: <a href="lwg-closed.html#927">927</a>, <a href="lwg-closed.html#1109">1109</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD Concepts: <a href="lwg-closed.html#906">906</a>, <a href="lwg-closed.html#913">913</a>, <a href="lwg-closed.html#914">914</a>, <a href="lwg-closed.html#928">928</a>, <a href="lwg-closed.html#1024">1024</a>, <a href="lwg-closed.html#1063">1063</a>, <a href="lwg-closed.html#1067">1067</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#718">718</a>, <a href="lwg-closed.html#873">873</a>.</li>
<li>Changed the following issues from Tentatively NAD Editorial to NAD Editorial: <a href="lwg-closed.html#424">424</a>, <a href="lwg-defects.html#825">825</a>, <a href="lwg-closed.html#830">830</a>, <a href="lwg-closed.html#837">837</a>, <a href="lwg-closed.html#862">862</a>, <a href="lwg-closed.html#867">867</a>, <a href="lwg-defects.html#884">884</a>, <a href="lwg-closed.html#945">945</a>, <a href="lwg-closed.html#952">952</a>, <a href="lwg-closed.html#969">969</a>, <a href="lwg-closed.html#972">972</a>, <a href="lwg-closed.html#973">973</a>, <a href="lwg-closed.html#979">979</a>, <a href="lwg-closed.html#1023">1023</a>, <a href="lwg-closed.html#1058">1058</a>, <a href="lwg-closed.html#1060">1060</a>, <a href="lwg-closed.html#1061">1061</a>, <a href="lwg-closed.html#1077">1077</a>, <a href="lwg-closed.html#1101">1101</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="lwg-closed.html#1013">1013</a>, <a href="lwg-closed.html#1107">1107</a>.</li>
<li>Changed the following issues from Open to NAD Future: <a href="lwg-closed.html#255">255</a>, <a href="lwg-closed.html#423">423</a>, <a href="lwg-closed.html#523">523</a>, <a href="lwg-closed.html#708">708</a>, <a href="lwg-closed.html#760">760</a>, <a href="lwg-closed.html#839">839</a>, <a href="lwg-closed.html#877">877</a>.</li>
<li>Changed the following issues from CD1 to Open: <a href="lwg-defects.html#823">823</a>.</li>
<li>Changed the following issues from NAD Editorial to Open: <a href="lwg-closed.html#299">299</a>, <a href="lwg-closed.html#484">484</a>, <a href="lwg-closed.html#532">532</a>, <a href="lwg-defects.html#556">556</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-closed.html#631">631</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#742">742</a>, <a href="lwg-defects.html#811">811</a>, <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#872">872</a>.</li>
<li>Changed the following issues from Review to Open: <a href="lwg-closed.html#879">879</a>, <a href="lwg-closed.html#919">919</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#987">987</a>, <a href="lwg-closed.html#1009">1009</a>, <a href="lwg-defects.html#1093">1093</a>.</li>
<li>Changed the following issues from Tentatively NAD to Open: <a href="lwg-closed.html#458">458</a>.</li>
<li>Changed the following issues from Tentatively NAD Future to Open: <a href="lwg-closed.html#96">96</a>.</li>
<li>Changed the following issues from Tentatively Ready to Open: <a href="lwg-closed.html#910">910</a>, <a href="lwg-closed.html#915">915</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#976">976</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-defects.html#1011">1011</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#149">149</a>, <a href="lwg-defects.html#419">419</a>, <a href="lwg-defects.html#430">430</a>, <a href="lwg-defects.html#498">498</a>, <a href="lwg-defects.html#564">564</a>, <a href="lwg-defects.html#565">565</a>, <a href="lwg-defects.html#630">630</a>, <a href="lwg-defects.html#659">659</a>, <a href="lwg-defects.html#696">696</a>, <a href="lwg-defects.html#711">711</a>, <a href="lwg-defects.html#716">716</a>, <a href="lwg-defects.html#723">723</a>, <a href="lwg-defects.html#788">788</a>, <a href="lwg-defects.html#834">834</a>, <a href="lwg-defects.html#838">838</a>, <a href="lwg-defects.html#847">847</a>, <a href="lwg-defects.html#857">857</a>, <a href="lwg-defects.html#859">859</a>, <a href="lwg-defects.html#876">876</a>, <a href="lwg-defects.html#881">881</a>, <a href="lwg-defects.html#883">883</a>, <a href="lwg-defects.html#886">886</a>, <a href="lwg-defects.html#1004">1004</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#780">780</a>.</li>
<li>Changed the following issues from Tentatively NAD to Ready: <a href="lwg-closed.html#822">822</a>.</li>
<li>Changed the following issues from Tentatively Ready to Ready: <a href="lwg-defects.html#934">934</a>.</li>
<li>Changed the following issues from NAD to Review: <a href="lwg-defects.html#871">871</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-closed.html#397">397</a>, <a href="lwg-closed.html#408">408</a>, <a href="lwg-defects.html#473">473</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-defects.html#868">868</a>, <a href="lwg-defects.html#889">889</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-closed.html#930">930</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>.</li>
<li>Changed the following issues from Tentatively NAD to Review: <a href="lwg-closed.html#668">668</a>.</li>
<li>Changed the following issues from Tentatively Ready to Review: <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#1100">1100</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD: <a href="lwg-closed.html#588">588</a>, <a href="lwg-closed.html#617">617</a>, <a href="lwg-defects.html#625">625</a>, <a href="lwg-closed.html#971">971</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Future: <a href="lwg-closed.html#1031">1031</a>, <a href="lwg-closed.html#1062">1062</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#1012">1012</a>, <a href="lwg-defects.html#1019">1019</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="lwg-defects.html#688">688</a>, <a href="lwg-defects.html#765">765</a>, <a href="lwg-defects.html#810">810</a>, <a href="lwg-defects.html#814">814</a>, <a href="lwg-defects.html#853">853</a>, <a href="lwg-defects.html#869">869</a>, <a href="lwg-defects.html#878">878</a>, <a href="lwg-defects.html#888">888</a>, <a href="lwg-defects.html#890">890</a>, <a href="lwg-defects.html#898">898</a>, <a href="lwg-defects.html#899">899</a>, <a href="lwg-defects.html#904">904</a>, <a href="lwg-defects.html#907">907</a>, <a href="lwg-defects.html#909">909</a>, <a href="lwg-defects.html#922">922</a>, <a href="lwg-defects.html#925">925</a>, <a href="lwg-defects.html#931">931</a>, <a href="lwg-defects.html#938">938</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-defects.html#948">948</a>, <a href="lwg-defects.html#949">949</a>, <a href="lwg-defects.html#965">965</a>, <a href="lwg-defects.html#970">970</a>, <a href="lwg-defects.html#975">975</a>, <a href="lwg-defects.html#981">981</a>, <a href="lwg-defects.html#982">982</a>, <a href="lwg-defects.html#984">984</a>, <a href="lwg-defects.html#986">986</a>, <a href="lwg-defects.html#990">990</a>, <a href="lwg-defects.html#991">991</a>, <a href="lwg-defects.html#993">993</a>, <a href="lwg-defects.html#994">994</a>, <a href="lwg-defects.html#997">997</a>, <a href="lwg-defects.html#998">998</a>, <a href="lwg-defects.html#1006">1006</a>, <a href="lwg-defects.html#1014">1014</a>, <a href="lwg-defects.html#1021">1021</a>, <a href="lwg-defects.html#1037">1037</a>, <a href="lwg-defects.html#1038">1038</a>, <a href="lwg-defects.html#1039">1039</a>, <a href="lwg-defects.html#1040">1040</a>, <a href="lwg-defects.html#1044">1044</a>, <a href="lwg-defects.html#1045">1045</a>, <a href="lwg-defects.html#1065">1065</a>, <a href="lwg-defects.html#1066">1066</a>, <a href="lwg-defects.html#1070">1070</a>, <a href="lwg-defects.html#1073">1073</a>, <a href="lwg-defects.html#1103">1103</a>.</li>
</ul></li>
</ul>
</li>
<li>R65: 
2009-06-19 pre-Frankfurt mailing.
<ul>
<li><b>Summary:</b><ul>
<li>378 open issues, up by 32.</li>
<li>765 closed issues, up by 0.</li>
<li>1143 issues total, up by 32.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-closed.html#1115">1115</a>, <a href="lwg-defects.html#1116">1116</a>, <a href="lwg-defects.html#1117">1117</a>, <a href="lwg-defects.html#1118">1118</a>, <a href="lwg-closed.html#1119">1119</a>, <a href="lwg-closed.html#1120">1120</a>, <a href="lwg-closed.html#1121">1121</a>, <a href="lwg-defects.html#1122">1122</a>, <a href="lwg-defects.html#1123">1123</a>, <a href="lwg-closed.html#1124">1124</a>, <a href="lwg-closed.html#1125">1125</a>, <a href="lwg-defects.html#1126">1126</a>, <a href="lwg-closed.html#1127">1127</a>, <a href="lwg-closed.html#1128">1128</a>, <a href="lwg-defects.html#1129">1129</a>, <a href="lwg-defects.html#1130">1130</a>, <a href="lwg-defects.html#1131">1131</a>, <a href="lwg-closed.html#1132">1132</a>, <a href="lwg-defects.html#1133">1133</a>, <a href="lwg-defects.html#1134">1134</a>, <a href="lwg-defects.html#1135">1135</a>, <a href="lwg-defects.html#1136">1136</a>, <a href="lwg-defects.html#1137">1137</a>, <a href="lwg-defects.html#1138">1138</a>, <a href="lwg-closed.html#1139">1139</a>, <a href="lwg-closed.html#1140">1140</a>, <a href="lwg-closed.html#1141">1141</a>, <a href="lwg-closed.html#1142">1142</a>, <a href="lwg-defects.html#1143">1143</a>.</li>
<li>Added the following Open issues: <a href="lwg-closed.html#1112">1112</a>, <a href="lwg-defects.html#1113">1113</a>, <a href="lwg-defects.html#1114">1114</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#937">937</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#696">696</a>, <a href="lwg-defects.html#716">716</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#865">865</a>, <a href="lwg-defects.html#900">900</a>, <a href="lwg-defects.html#911">911</a>, <a href="lwg-closed.html#916">916</a>, <a href="lwg-closed.html#917">917</a>, <a href="lwg-defects.html#920">920</a>, <a href="lwg-closed.html#933">933</a>, <a href="lwg-closed.html#935">935</a>, <a href="lwg-closed.html#941">941</a>, <a href="lwg-defects.html#947">947</a>, <a href="lwg-defects.html#951">951</a>, <a href="lwg-defects.html#953">953</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-closed.html#955">955</a>, <a href="lwg-defects.html#956">956</a>, <a href="lwg-closed.html#977">977</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-defects.html#985">985</a>, <a href="lwg-closed.html#989">989</a>, <a href="lwg-closed.html#996">996</a>, <a href="lwg-defects.html#1033">1033</a>, <a href="lwg-defects.html#1054">1054</a>, <a href="lwg-closed.html#1056">1056</a>, <a href="lwg-closed.html#1057">1057</a>, <a href="lwg-closed.html#1059">1059</a>, <a href="lwg-closed.html#1062">1062</a>, <a href="lwg-closed.html#1068">1068</a>, <a href="lwg-closed.html#1069">1069</a>, <a href="lwg-defects.html#1071">1071</a>, <a href="lwg-closed.html#1072">1072</a>, <a href="lwg-closed.html#1076">1076</a>, <a href="lwg-defects.html#1090">1090</a>, <a href="lwg-closed.html#1092">1092</a>, <a href="lwg-closed.html#1096">1096</a>, <a href="lwg-defects.html#1098">1098</a>, <a href="lwg-closed.html#1099">1099</a>, <a href="lwg-closed.html#1105">1105</a>, <a href="lwg-defects.html#1106">1106</a>, <a href="lwg-defects.html#1108">1108</a>, <a href="lwg-defects.html#1110">1110</a>.</li>
<li>Changed the following issues from Review to Open: <a href="lwg-defects.html#817">817</a>, <a href="lwg-closed.html#971">971</a>, <a href="lwg-closed.html#992">992</a>, <a href="lwg-defects.html#1004">1004</a>, <a href="lwg-closed.html#1010">1010</a>, <a href="lwg-defects.html#1012">1012</a>, <a href="lwg-closed.html#1015">1015</a>, <a href="lwg-defects.html#1019">1019</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#780">780</a>, <a href="lwg-defects.html#835">835</a>, <a href="lwg-defects.html#897">897</a>, <a href="lwg-closed.html#919">919</a>, <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#957">957</a>, <a href="lwg-defects.html#983">983</a>, <a href="lwg-closed.html#1001">1001</a>, <a href="lwg-closed.html#1080">1080</a>, <a href="lwg-closed.html#1091">1091</a>, <a href="lwg-defects.html#1093">1093</a>, <a href="lwg-defects.html#1094">1094</a>, <a href="lwg-defects.html#1095">1095</a>, <a href="lwg-defects.html#1097">1097</a>, <a href="lwg-closed.html#1102">1102</a>, <a href="lwg-defects.html#1104">1104</a>, <a href="lwg-closed.html#1111">1111</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#987">987</a>, <a href="lwg-closed.html#1087">1087</a>.</li>
<li>Changed the following issues from New to Tentatively NAD: <a href="lwg-closed.html#568">568</a>, <a href="lwg-closed.html#701">701</a>, <a href="lwg-closed.html#702">702</a>, <a href="lwg-closed.html#785">785</a>, <a href="lwg-closed.html#863">863</a>, <a href="lwg-closed.html#903">903</a>, <a href="lwg-closed.html#912">912</a>, <a href="lwg-closed.html#918">918</a>, <a href="lwg-closed.html#946">946</a>, <a href="lwg-closed.html#995">995</a>, <a href="lwg-closed.html#1074">1074</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD: <a href="lwg-closed.html#458">458</a>, <a href="lwg-closed.html#644">644</a>, <a href="lwg-closed.html#667">667</a>, <a href="lwg-closed.html#668">668</a>, <a href="lwg-closed.html#669">669</a>.</li>
<li>Changed the following issues from Review to Tentatively NAD: <a href="lwg-closed.html#901">901</a>.</li>
<li>Changed the following issues from Tentatively Ready to Tentatively NAD: <a href="lwg-closed.html#822">822</a>, <a href="lwg-closed.html#988">988</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="lwg-closed.html#837">837</a>, <a href="lwg-closed.html#862">862</a>, <a href="lwg-closed.html#867">867</a>, <a href="lwg-closed.html#927">927</a>, <a href="lwg-closed.html#945">945</a>, <a href="lwg-closed.html#952">952</a>, <a href="lwg-closed.html#969">969</a>, <a href="lwg-closed.html#972">972</a>, <a href="lwg-closed.html#973">973</a>, <a href="lwg-closed.html#979">979</a>, <a href="lwg-closed.html#1058">1058</a>, <a href="lwg-closed.html#1060">1060</a>, <a href="lwg-closed.html#1061">1061</a>, <a href="lwg-closed.html#1077">1077</a>, <a href="lwg-closed.html#1101">1101</a>, <a href="lwg-closed.html#1109">1109</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="lwg-closed.html#424">424</a>, <a href="lwg-defects.html#825">825</a>, <a href="lwg-closed.html#830">830</a>, <a href="lwg-defects.html#884">884</a>.</li>
<li>Changed the following issues from Review to Tentatively NAD Editorial: <a href="lwg-closed.html#1023">1023</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Future: <a href="lwg-closed.html#96">96</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#810">810</a>, <a href="lwg-defects.html#898">898</a>, <a href="lwg-closed.html#906">906</a>, <a href="lwg-closed.html#910">910</a>, <a href="lwg-closed.html#913">913</a>, <a href="lwg-closed.html#914">914</a>, <a href="lwg-closed.html#915">915</a>, <a href="lwg-defects.html#925">925</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#976">976</a>, <a href="lwg-defects.html#981">981</a>, <a href="lwg-defects.html#982">982</a>, <a href="lwg-defects.html#984">984</a>, <a href="lwg-defects.html#990">990</a>, <a href="lwg-defects.html#998">998</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-closed.html#1063">1063</a>, <a href="lwg-closed.html#1067">1067</a>, <a href="lwg-defects.html#1070">1070</a>, <a href="lwg-defects.html#1073">1073</a>, <a href="lwg-defects.html#1100">1100</a>, <a href="lwg-defects.html#1103">1103</a>, <a href="lwg-closed.html#1107">1107</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#688">688</a>, <a href="lwg-defects.html#814">814</a>.</li>
<li>Changed the following issues from Review to Tentatively Ready: <a href="lwg-defects.html#899">899</a>, <a href="lwg-defects.html#907">907</a>, <a href="lwg-defects.html#909">909</a>, <a href="lwg-defects.html#934">934</a>, <a href="lwg-defects.html#938">938</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#965">965</a>, <a href="lwg-defects.html#970">970</a>, <a href="lwg-defects.html#975">975</a>, <a href="lwg-defects.html#986">986</a>, <a href="lwg-defects.html#991">991</a>, <a href="lwg-defects.html#993">993</a>, <a href="lwg-defects.html#994">994</a>, <a href="lwg-defects.html#997">997</a>, <a href="lwg-closed.html#1002">1002</a>, <a href="lwg-defects.html#1006">1006</a>, <a href="lwg-defects.html#1011">1011</a>, <a href="lwg-closed.html#1013">1013</a>, <a href="lwg-defects.html#1014">1014</a>, <a href="lwg-defects.html#1021">1021</a>, <a href="lwg-closed.html#1024">1024</a>, <a href="lwg-defects.html#1037">1037</a>, <a href="lwg-defects.html#1038">1038</a>, <a href="lwg-defects.html#1039">1039</a>, <a href="lwg-defects.html#1040">1040</a>, <a href="lwg-defects.html#1044">1044</a>, <a href="lwg-defects.html#1045">1045</a>, <a href="lwg-defects.html#1065">1065</a>, <a href="lwg-defects.html#1066">1066</a>.</li>
</ul></li>
</ul>
</li>
<li>R64: 
2009-05-01 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>346 open issues, up by 19.</li>
<li>765 closed issues, up by 0.</li>
<li>1111 issues total, up by 19.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#1093">1093</a>, <a href="lwg-defects.html#1094">1094</a>, <a href="lwg-defects.html#1095">1095</a>, <a href="lwg-closed.html#1096">1096</a>, <a href="lwg-defects.html#1097">1097</a>, <a href="lwg-defects.html#1098">1098</a>, <a href="lwg-closed.html#1099">1099</a>, <a href="lwg-defects.html#1100">1100</a>, <a href="lwg-closed.html#1101">1101</a>, <a href="lwg-closed.html#1102">1102</a>, <a href="lwg-defects.html#1103">1103</a>, <a href="lwg-defects.html#1104">1104</a>, <a href="lwg-closed.html#1105">1105</a>, <a href="lwg-defects.html#1106">1106</a>, <a href="lwg-closed.html#1107">1107</a>, <a href="lwg-defects.html#1108">1108</a>, <a href="lwg-closed.html#1109">1109</a>, <a href="lwg-defects.html#1110">1110</a>, <a href="lwg-closed.html#1111">1111</a>.</li>
<li>Changed the following issues from DR to CD1: <a href="lwg-defects.html#130">130</a>, <a href="lwg-defects.html#386">386</a>, <a href="lwg-defects.html#406">406</a>, <a href="lwg-defects.html#409">409</a>, <a href="lwg-defects.html#413">413</a>, <a href="lwg-defects.html#434">434</a>, <a href="lwg-defects.html#438">438</a>, <a href="lwg-defects.html#444">444</a>, <a href="lwg-defects.html#445">445</a>, <a href="lwg-defects.html#455">455</a>, <a href="lwg-defects.html#457">457</a>, <a href="lwg-defects.html#460">460</a>, <a href="lwg-defects.html#469">469</a>, <a href="lwg-defects.html#533">533</a>.</li>
<li>Changed the following issues from Review to New: <a href="lwg-defects.html#1070">1070</a>.</li>
</ul></li>
</ul>
</li>
<li>R63: 
2009-03-20 post-Summit mailing.
<ul>
<li><b>Summary:</b><ul>
<li>327 open issues, up by 96.</li>
<li>765 closed issues, up by 14.</li>
<li>1092 issues total, up by 110.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD Editorial issues: <a href="lwg-closed.html#1022">1022</a>.</li>
<li>Added the following NAD Future issues: <a href="lwg-closed.html#1025">1025</a>.</li>
<li>Added the following New issues: <a href="lwg-defects.html#983">983</a>, <a href="lwg-defects.html#984">984</a>, <a href="lwg-defects.html#985">985</a>, <a href="lwg-closed.html#989">989</a>, <a href="lwg-defects.html#990">990</a>, <a href="lwg-closed.html#995">995</a>, <a href="lwg-closed.html#996">996</a>, <a href="lwg-defects.html#998">998</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-closed.html#1001">1001</a>, <a href="lwg-defects.html#1033">1033</a>, <a href="lwg-defects.html#1054">1054</a>, <a href="lwg-closed.html#1056">1056</a>, <a href="lwg-closed.html#1057">1057</a>, <a href="lwg-closed.html#1058">1058</a>, <a href="lwg-closed.html#1059">1059</a>, <a href="lwg-closed.html#1060">1060</a>, <a href="lwg-closed.html#1061">1061</a>, <a href="lwg-closed.html#1062">1062</a>, <a href="lwg-closed.html#1063">1063</a>, <a href="lwg-closed.html#1067">1067</a>, <a href="lwg-closed.html#1068">1068</a>, <a href="lwg-closed.html#1069">1069</a>, <a href="lwg-defects.html#1071">1071</a>, <a href="lwg-closed.html#1072">1072</a>, <a href="lwg-defects.html#1073">1073</a>, <a href="lwg-closed.html#1074">1074</a>, <a href="lwg-closed.html#1076">1076</a>, <a href="lwg-closed.html#1077">1077</a>, <a href="lwg-closed.html#1080">1080</a>, <a href="lwg-defects.html#1090">1090</a>, <a href="lwg-closed.html#1091">1091</a>, <a href="lwg-closed.html#1092">1092</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#987">987</a>, <a href="lwg-closed.html#1000">1000</a>, <a href="lwg-closed.html#1007">1007</a>, <a href="lwg-closed.html#1008">1008</a>, <a href="lwg-closed.html#1016">1016</a>, <a href="lwg-closed.html#1017">1017</a>, <a href="lwg-closed.html#1018">1018</a>, <a href="lwg-closed.html#1020">1020</a>, <a href="lwg-closed.html#1026">1026</a>, <a href="lwg-closed.html#1027">1027</a>, <a href="lwg-closed.html#1028">1028</a>, <a href="lwg-closed.html#1029">1029</a>, <a href="lwg-defects.html#1030">1030</a>, <a href="lwg-closed.html#1031">1031</a>, <a href="lwg-closed.html#1032">1032</a>, <a href="lwg-defects.html#1034">1034</a>, <a href="lwg-closed.html#1035">1035</a>, <a href="lwg-closed.html#1036">1036</a>, <a href="lwg-closed.html#1041">1041</a>, <a href="lwg-closed.html#1042">1042</a>, <a href="lwg-defects.html#1046">1046</a>, <a href="lwg-defects.html#1048">1048</a>, <a href="lwg-closed.html#1051">1051</a>, <a href="lwg-closed.html#1052">1052</a>, <a href="lwg-closed.html#1053">1053</a>, <a href="lwg-defects.html#1055">1055</a>, <a href="lwg-closed.html#1064">1064</a>, <a href="lwg-defects.html#1075">1075</a>, <a href="lwg-closed.html#1078">1078</a>, <a href="lwg-defects.html#1079">1079</a>, <a href="lwg-closed.html#1081">1081</a>, <a href="lwg-closed.html#1082">1082</a>, <a href="lwg-closed.html#1083">1083</a>, <a href="lwg-closed.html#1084">1084</a>, <a href="lwg-closed.html#1085">1085</a>, <a href="lwg-closed.html#1086">1086</a>, <a href="lwg-closed.html#1087">1087</a>, <a href="lwg-defects.html#1088">1088</a>, <a href="lwg-defects.html#1089">1089</a>.</li>
<li>Added the following Review issues: <a href="lwg-defects.html#986">986</a>, <a href="lwg-defects.html#991">991</a>, <a href="lwg-closed.html#992">992</a>, <a href="lwg-defects.html#993">993</a>, <a href="lwg-defects.html#994">994</a>, <a href="lwg-defects.html#997">997</a>, <a href="lwg-closed.html#1002">1002</a>, <a href="lwg-closed.html#1003">1003</a>, <a href="lwg-defects.html#1004">1004</a>, <a href="lwg-closed.html#1005">1005</a>, <a href="lwg-defects.html#1006">1006</a>, <a href="lwg-closed.html#1009">1009</a>, <a href="lwg-closed.html#1010">1010</a>, <a href="lwg-defects.html#1011">1011</a>, <a href="lwg-defects.html#1012">1012</a>, <a href="lwg-closed.html#1013">1013</a>, <a href="lwg-defects.html#1014">1014</a>, <a href="lwg-closed.html#1015">1015</a>, <a href="lwg-defects.html#1019">1019</a>, <a href="lwg-defects.html#1021">1021</a>, <a href="lwg-closed.html#1023">1023</a>, <a href="lwg-closed.html#1024">1024</a>, <a href="lwg-defects.html#1037">1037</a>, <a href="lwg-defects.html#1038">1038</a>, <a href="lwg-defects.html#1039">1039</a>, <a href="lwg-defects.html#1040">1040</a>, <a href="lwg-defects.html#1043">1043</a>, <a href="lwg-defects.html#1044">1044</a>, <a href="lwg-defects.html#1045">1045</a>, <a href="lwg-defects.html#1047">1047</a>, <a href="lwg-defects.html#1049">1049</a>, <a href="lwg-defects.html#1050">1050</a>, <a href="lwg-defects.html#1065">1065</a>, <a href="lwg-defects.html#1066">1066</a>, <a href="lwg-defects.html#1070">1070</a>.</li>
<li>Added the following Tentatively Ready issues: <a href="lwg-closed.html#988">988</a>.</li>
<li>Changed the following issues from New to Dup: <a href="lwg-closed.html#905">905</a>, <a href="lwg-closed.html#942">942</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#980">980</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#874">874</a>, <a href="lwg-defects.html#875">875</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-defects.html#732">732</a>, <a href="lwg-defects.html#793">793</a>, <a href="lwg-defects.html#794">794</a>, <a href="lwg-defects.html#800">800</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#683">683</a>, <a href="lwg-closed.html#892">892</a>.</li>
<li>Changed the following issues from Ready to NAD Editorial: <a href="lwg-defects.html#803">803</a>.</li>
<li>Changed the following issues from NAD to Open: <a href="lwg-closed.html#466">466</a>.</li>
<li>Changed the following issues from NAD Future to Open: <a href="lwg-closed.html#111">111</a>, <a href="lwg-closed.html#138">138</a>, <a href="lwg-defects.html#149">149</a>, <a href="lwg-closed.html#219">219</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#880">880</a>, <a href="lwg-defects.html#891">891</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-closed.html#902">902</a>, <a href="lwg-defects.html#908">908</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#923">923</a>, <a href="lwg-defects.html#924">924</a>, <a href="lwg-closed.html#926">926</a>, <a href="lwg-closed.html#930">930</a>, <a href="lwg-closed.html#936">936</a>, <a href="lwg-defects.html#944">944</a>, <a href="lwg-defects.html#958">958</a>, <a href="lwg-closed.html#959">959</a>, <a href="lwg-defects.html#960">960</a>, <a href="lwg-closed.html#961">961</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#963">963</a>, <a href="lwg-defects.html#964">964</a>, <a href="lwg-defects.html#966">966</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="lwg-defects.html#788">788</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="lwg-closed.html#937">937</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-closed.html#879">879</a>, <a href="lwg-defects.html#899">899</a>, <a href="lwg-closed.html#901">901</a>, <a href="lwg-defects.html#907">907</a>, <a href="lwg-defects.html#909">909</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-defects.html#934">934</a>, <a href="lwg-defects.html#938">938</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#965">965</a>, <a href="lwg-defects.html#970">970</a>, <a href="lwg-closed.html#971">971</a>, <a href="lwg-defects.html#975">975</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#817">817</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#904">904</a>, <a href="lwg-defects.html#922">922</a>, <a href="lwg-closed.html#928">928</a>, <a href="lwg-defects.html#931">931</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-defects.html#948">948</a>, <a href="lwg-defects.html#949">949</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#890">890</a>.</li>
<li>Changed the following issues from Review to Tentatively Ready: <a href="lwg-defects.html#765">765</a>, <a href="lwg-closed.html#822">822</a>, <a href="lwg-defects.html#853">853</a>, <a href="lwg-defects.html#869">869</a>, <a href="lwg-defects.html#878">878</a>, <a href="lwg-defects.html#888">888</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#752">752</a>, <a href="lwg-defects.html#753">753</a>, <a href="lwg-defects.html#758">758</a>, <a href="lwg-defects.html#821">821</a>, <a href="lwg-defects.html#866">866</a>, <a href="lwg-defects.html#894">894</a>.</li>
</ul></li>
</ul>
</li>
<li>R62: 
2009-02-06 pre-Summit mailing.
<ul>
<li><b>Summary:</b><ul>
<li>231 open issues, up by 44.</li>
<li>751 closed issues, up by 0.</li>
<li>982 issues total, up by 44.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-closed.html#941">941</a>, <a href="lwg-closed.html#942">942</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-defects.html#944">944</a>, <a href="lwg-closed.html#945">945</a>, <a href="lwg-closed.html#946">946</a>, <a href="lwg-defects.html#947">947</a>, <a href="lwg-defects.html#948">948</a>, <a href="lwg-defects.html#949">949</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#951">951</a>, <a href="lwg-closed.html#952">952</a>, <a href="lwg-defects.html#953">953</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-closed.html#955">955</a>, <a href="lwg-defects.html#956">956</a>, <a href="lwg-defects.html#957">957</a>, <a href="lwg-defects.html#958">958</a>, <a href="lwg-closed.html#959">959</a>, <a href="lwg-defects.html#960">960</a>, <a href="lwg-closed.html#961">961</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#963">963</a>, <a href="lwg-defects.html#964">964</a>, <a href="lwg-defects.html#965">965</a>, <a href="lwg-defects.html#966">966</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>, <a href="lwg-closed.html#969">969</a>, <a href="lwg-defects.html#970">970</a>, <a href="lwg-closed.html#971">971</a>, <a href="lwg-closed.html#972">972</a>, <a href="lwg-closed.html#973">973</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#975">975</a>, <a href="lwg-defects.html#976">976</a>, <a href="lwg-closed.html#977">977</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-closed.html#979">979</a>, <a href="lwg-closed.html#980">980</a>, <a href="lwg-defects.html#981">981</a>, <a href="lwg-defects.html#982">982</a>.</li>
</ul></li>
</ul>
</li>
<li>R61: 
2008-12-05 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>187 open issues, up by 20.</li>
<li>751 closed issues, up by 0.</li>
<li>938 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-closed.html#919">919</a>, <a href="lwg-defects.html#920">920</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#922">922</a>, <a href="lwg-defects.html#923">923</a>, <a href="lwg-defects.html#924">924</a>, <a href="lwg-defects.html#925">925</a>, <a href="lwg-closed.html#926">926</a>, <a href="lwg-closed.html#927">927</a>, <a href="lwg-closed.html#928">928</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-closed.html#930">930</a>, <a href="lwg-defects.html#931">931</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-closed.html#933">933</a>, <a href="lwg-defects.html#934">934</a>, <a href="lwg-closed.html#935">935</a>, <a href="lwg-closed.html#936">936</a>, <a href="lwg-closed.html#937">937</a>, <a href="lwg-defects.html#938">938</a>.</li>
</ul></li>
</ul>
</li>
<li>R60: 
2008-10-03 post-San Francisco mailing.
<ul>
<li><b>Summary:</b><ul>
<li>167 open issues, down by 25.</li>
<li>751 closed issues, up by 65.</li>
<li>918 issues total, up by 40.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following CD1 issues: <a href="lwg-defects.html#882">882</a>.</li>
<li>Added the following New issues: <a href="lwg-closed.html#879">879</a>, <a href="lwg-defects.html#880">880</a>, <a href="lwg-defects.html#891">891</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-defects.html#897">897</a>, <a href="lwg-defects.html#898">898</a>, <a href="lwg-defects.html#899">899</a>, <a href="lwg-defects.html#900">900</a>, <a href="lwg-closed.html#901">901</a>, <a href="lwg-closed.html#902">902</a>, <a href="lwg-closed.html#903">903</a>, <a href="lwg-defects.html#904">904</a>, <a href="lwg-closed.html#905">905</a>, <a href="lwg-closed.html#906">906</a>, <a href="lwg-defects.html#907">907</a>, <a href="lwg-defects.html#908">908</a>, <a href="lwg-defects.html#909">909</a>, <a href="lwg-closed.html#910">910</a>, <a href="lwg-defects.html#911">911</a>, <a href="lwg-closed.html#912">912</a>, <a href="lwg-closed.html#913">913</a>, <a href="lwg-closed.html#914">914</a>, <a href="lwg-closed.html#915">915</a>, <a href="lwg-closed.html#916">916</a>, <a href="lwg-closed.html#917">917</a>, <a href="lwg-closed.html#918">918</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#881">881</a>, <a href="lwg-defects.html#883">883</a>, <a href="lwg-defects.html#884">884</a>, <a href="lwg-defects.html#885">885</a>, <a href="lwg-defects.html#886">886</a>, <a href="lwg-closed.html#887">887</a>, <a href="lwg-defects.html#889">889</a>, <a href="lwg-defects.html#890">890</a>, <a href="lwg-closed.html#895">895</a>, <a href="lwg-defects.html#896">896</a>.</li>
<li>Added the following Pending NAD Editorial issues: <a href="lwg-closed.html#892">892</a>.</li>
<li>Added the following Ready issues: <a href="lwg-defects.html#894">894</a>.</li>
<li>Added the following Review issues: <a href="lwg-defects.html#888">888</a>.</li>
<li>Changed the following issues from New to CD1: <a href="lwg-defects.html#818">818</a>, <a href="lwg-defects.html#820">820</a>, <a href="lwg-defects.html#843">843</a>, <a href="lwg-defects.html#845">845</a>, <a href="lwg-defects.html#846">846</a>, <a href="lwg-defects.html#856">856</a>, <a href="lwg-defects.html#858">858</a>.</li>
<li>Changed the following issues from Ready to CD1: <a href="lwg-defects.html#180">180</a>, <a href="lwg-defects.html#387">387</a>, <a href="lwg-defects.html#396">396</a>, <a href="lwg-defects.html#522">522</a>, <a href="lwg-defects.html#629">629</a>, <a href="lwg-defects.html#691">691</a>, <a href="lwg-defects.html#713">713</a>, <a href="lwg-defects.html#714">714</a>, <a href="lwg-defects.html#720">720</a>, <a href="lwg-defects.html#728">728</a>, <a href="lwg-defects.html#762">762</a>, <a href="lwg-defects.html#769">769</a>, <a href="lwg-defects.html#771">771</a>, <a href="lwg-defects.html#772">772</a>, <a href="lwg-defects.html#776">776</a>, <a href="lwg-defects.html#779">779</a>, <a href="lwg-defects.html#787">787</a>, <a href="lwg-defects.html#805">805</a>, <a href="lwg-defects.html#806">806</a>, <a href="lwg-defects.html#807">807</a>, <a href="lwg-defects.html#808">808</a>, <a href="lwg-defects.html#809">809</a>, <a href="lwg-defects.html#813">813</a>, <a href="lwg-defects.html#824">824</a>, <a href="lwg-defects.html#829">829</a>, <a href="lwg-defects.html#842">842</a>, <a href="lwg-defects.html#844">844</a>, <a href="lwg-defects.html#848">848</a>, <a href="lwg-defects.html#850">850</a>, <a href="lwg-defects.html#852">852</a>.</li>
<li>Changed the following issues from Review to CD1: <a href="lwg-defects.html#23">23</a>, <a href="lwg-defects.html#675">675</a>, <a href="lwg-defects.html#692">692</a>, <a href="lwg-defects.html#698">698</a>, <a href="lwg-defects.html#709">709</a>, <a href="lwg-defects.html#734">734</a>, <a href="lwg-defects.html#804">804</a>, <a href="lwg-defects.html#823">823</a>.</li>
<li>Changed the following issues from WP to CD1: <a href="lwg-defects.html#44">44</a>, <a href="lwg-defects.html#49">49</a>, <a href="lwg-defects.html#76">76</a>, <a href="lwg-defects.html#91">91</a>, <a href="lwg-defects.html#92">92</a>, <a href="lwg-defects.html#98">98</a>, <a href="lwg-defects.html#103">103</a>, <a href="lwg-defects.html#109">109</a>, <a href="lwg-defects.html#117">117</a>, <a href="lwg-defects.html#118">118</a>, <a href="lwg-defects.html#120">120</a>, <a href="lwg-defects.html#123">123</a>, <a href="lwg-defects.html#136">136</a>, <a href="lwg-defects.html#153">153</a>, <a href="lwg-defects.html#165">165</a>, <a href="lwg-defects.html#167">167</a>, <a href="lwg-defects.html#171">171</a>, <a href="lwg-defects.html#179">179</a>, <a href="lwg-defects.html#182">182</a>, <a href="lwg-defects.html#183">183</a>, <a href="lwg-defects.html#184">184</a>, <a href="lwg-defects.html#185">185</a>, <a href="lwg-defects.html#186">186</a>, <a href="lwg-defects.html#187">187</a>, <a href="lwg-defects.html#198">198</a>, <a href="lwg-defects.html#200">200</a>, <a href="lwg-defects.html#201">201</a>, <a href="lwg-defects.html#202">202</a>, <a href="lwg-defects.html#206">206</a>, <a href="lwg-defects.html#214">214</a>, <a href="lwg-defects.html#221">221</a>, <a href="lwg-defects.html#225">225</a>, <a href="lwg-defects.html#226">226</a>, <a href="lwg-defects.html#228">228</a>, <a href="lwg-defects.html#229">229</a>, <a href="lwg-defects.html#230">230</a>, <a href="lwg-defects.html#231">231</a>, <a href="lwg-defects.html#232">232</a>, <a href="lwg-defects.html#233">233</a>, <a href="lwg-defects.html#234">234</a>, <a href="lwg-defects.html#235">235</a>, <a href="lwg-defects.html#237">237</a>, <a href="lwg-defects.html#238">238</a>, <a href="lwg-defects.html#239">239</a>, <a href="lwg-defects.html#240">240</a>, <a href="lwg-defects.html#241">241</a>, <a href="lwg-defects.html#242">242</a>, <a href="lwg-defects.html#243">243</a>, <a href="lwg-defects.html#247">247</a>, <a href="lwg-defects.html#248">248</a>, <a href="lwg-defects.html#250">250</a>, <a href="lwg-defects.html#251">251</a>, <a href="lwg-defects.html#252">252</a>, <a href="lwg-defects.html#253">253</a>, <a href="lwg-defects.html#254">254</a>, <a href="lwg-defects.html#256">256</a>, <a href="lwg-defects.html#258">258</a>, <a href="lwg-defects.html#259">259</a>, <a href="lwg-defects.html#260">260</a>, <a href="lwg-defects.html#261">261</a>, <a href="lwg-defects.html#262">262</a>, <a href="lwg-defects.html#263">263</a>, <a href="lwg-defects.html#264">264</a>, <a href="lwg-defects.html#265">265</a>, <a href="lwg-defects.html#266">266</a>, <a href="lwg-defects.html#268">268</a>, <a href="lwg-defects.html#270">270</a>, <a href="lwg-defects.html#271">271</a>, <a href="lwg-defects.html#272">272</a>, <a href="lwg-defects.html#273">273</a>, <a href="lwg-defects.html#274">274</a>, <a href="lwg-defects.html#275">275</a>, <a href="lwg-defects.html#276">276</a>, <a href="lwg-defects.html#278">278</a>, <a href="lwg-defects.html#280">280</a>, <a href="lwg-defects.html#281">281</a>, <a href="lwg-defects.html#282">282</a>, <a href="lwg-defects.html#283">283</a>, <a href="lwg-defects.html#284">284</a>, <a href="lwg-defects.html#285">285</a>, <a href="lwg-defects.html#286">286</a>, <a href="lwg-defects.html#288">288</a>, <a href="lwg-defects.html#291">291</a>, <a href="lwg-defects.html#292">292</a>, <a href="lwg-defects.html#294">294</a>, <a href="lwg-defects.html#295">295</a>, <a href="lwg-defects.html#297">297</a>, <a href="lwg-defects.html#298">298</a>, <a href="lwg-defects.html#300">300</a>, <a href="lwg-defects.html#301">301</a>, <a href="lwg-defects.html#303">303</a>, <a href="lwg-defects.html#305">305</a>, <a href="lwg-defects.html#306">306</a>, <a href="lwg-defects.html#307">307</a>, <a href="lwg-defects.html#308">308</a>, <a href="lwg-defects.html#310">310</a>, <a href="lwg-defects.html#311">311</a>, <a href="lwg-defects.html#312">312</a>, <a href="lwg-defects.html#315">315</a>, <a href="lwg-defects.html#316">316</a>, <a href="lwg-defects.html#317">317</a>, <a href="lwg-defects.html#318">318</a>, <a href="lwg-defects.html#319">319</a>, <a href="lwg-defects.html#320">320</a>, <a href="lwg-defects.html#321">321</a>, <a href="lwg-defects.html#322">322</a>, <a href="lwg-defects.html#324">324</a>, <a href="lwg-defects.html#325">325</a>, <a href="lwg-defects.html#327">327</a>, <a href="lwg-defects.html#328">328</a>, <a href="lwg-defects.html#329">329</a>, <a href="lwg-defects.html#331">331</a>, <a href="lwg-defects.html#333">333</a>, <a href="lwg-defects.html#334">334</a>, <a href="lwg-defects.html#335">335</a>, <a href="lwg-defects.html#336">336</a>, <a href="lwg-defects.html#337">337</a>, <a href="lwg-defects.html#338">338</a>, <a href="lwg-defects.html#339">339</a>, <a href="lwg-defects.html#340">340</a>, <a href="lwg-defects.html#341">341</a>, <a href="lwg-defects.html#345">345</a>, <a href="lwg-defects.html#346">346</a>, <a href="lwg-defects.html#347">347</a>, <a href="lwg-defects.html#349">349</a>, <a href="lwg-defects.html#352">352</a>, <a href="lwg-defects.html#354">354</a>, <a href="lwg-defects.html#355">355</a>, <a href="lwg-defects.html#358">358</a>, <a href="lwg-defects.html#359">359</a>, <a href="lwg-defects.html#360">360</a>, <a href="lwg-defects.html#362">362</a>, <a href="lwg-defects.html#363">363</a>, <a href="lwg-defects.html#364">364</a>, <a href="lwg-defects.html#365">365</a>, <a href="lwg-defects.html#369">369</a>, <a href="lwg-defects.html#370">370</a>, <a href="lwg-defects.html#371">371</a>, <a href="lwg-defects.html#373">373</a>, <a href="lwg-defects.html#375">375</a>, <a href="lwg-defects.html#376">376</a>, <a href="lwg-defects.html#379">379</a>, <a href="lwg-defects.html#380">380</a>, <a href="lwg-defects.html#381">381</a>, <a href="lwg-defects.html#383">383</a>, <a href="lwg-defects.html#384">384</a>, <a href="lwg-defects.html#389">389</a>, <a href="lwg-defects.html#391">391</a>, <a href="lwg-defects.html#395">395</a>, <a href="lwg-defects.html#400">400</a>, <a href="lwg-defects.html#401">401</a>, <a href="lwg-defects.html#402">402</a>, <a href="lwg-defects.html#403">403</a>, <a href="lwg-defects.html#404">404</a>, <a href="lwg-defects.html#405">405</a>, <a href="lwg-defects.html#407">407</a>, <a href="lwg-defects.html#410">410</a>, <a href="lwg-defects.html#411">411</a>, <a href="lwg-defects.html#412">412</a>, <a href="lwg-defects.html#414">414</a>, <a href="lwg-defects.html#415">415</a>, <a href="lwg-defects.html#416">416</a>, <a href="lwg-defects.html#420">420</a>, <a href="lwg-defects.html#422">422</a>, <a href="lwg-defects.html#425">425</a>, <a href="lwg-defects.html#426">426</a>, <a href="lwg-defects.html#428">428</a>, <a href="lwg-defects.html#432">432</a>, <a href="lwg-defects.html#435">435</a>, <a href="lwg-defects.html#436">436</a>, <a href="lwg-defects.html#441">441</a>, <a href="lwg-defects.html#442">442</a>, <a href="lwg-defects.html#443">443</a>, <a href="lwg-defects.html#448">448</a>, <a href="lwg-defects.html#449">449</a>, <a href="lwg-defects.html#453">453</a>, <a href="lwg-defects.html#456">456</a>, <a href="lwg-defects.html#461">461</a>, <a href="lwg-defects.html#464">464</a>, <a href="lwg-defects.html#465">465</a>, <a href="lwg-defects.html#467">467</a>, <a href="lwg-defects.html#468">468</a>, <a href="lwg-defects.html#474">474</a>, <a href="lwg-defects.html#475">475</a>, <a href="lwg-defects.html#478">478</a>, <a href="lwg-defects.html#488">488</a>, <a href="lwg-defects.html#495">495</a>, <a href="lwg-defects.html#496">496</a>, <a href="lwg-defects.html#497">497</a>, <a href="lwg-defects.html#505">505</a>, <a href="lwg-defects.html#507">507</a>, <a href="lwg-defects.html#508">508</a>, <a href="lwg-defects.html#518">518</a>, <a href="lwg-defects.html#519">519</a>, <a href="lwg-defects.html#520">520</a>, <a href="lwg-defects.html#521">521</a>, <a href="lwg-defects.html#524">524</a>, <a href="lwg-defects.html#527">527</a>, <a href="lwg-defects.html#530">530</a>, <a href="lwg-defects.html#531">531</a>, <a href="lwg-defects.html#534">534</a>, <a href="lwg-defects.html#535">535</a>, <a href="lwg-defects.html#537">537</a>, <a href="lwg-defects.html#538">538</a>, <a href="lwg-defects.html#540">540</a>, <a href="lwg-defects.html#541">541</a>, <a href="lwg-defects.html#542">542</a>, <a href="lwg-defects.html#543">543</a>, <a href="lwg-defects.html#545">545</a>, <a href="lwg-defects.html#550">550</a>, <a href="lwg-defects.html#551">551</a>, <a href="lwg-defects.html#552">552</a>, <a href="lwg-defects.html#559">559</a>, <a href="lwg-defects.html#561">561</a>, <a href="lwg-defects.html#562">562</a>, <a href="lwg-defects.html#563">563</a>, <a href="lwg-defects.html#566">566</a>, <a href="lwg-defects.html#567">567</a>, <a href="lwg-defects.html#574">574</a>, <a href="lwg-defects.html#575">575</a>, <a href="lwg-defects.html#576">576</a>, <a href="lwg-defects.html#577">577</a>, <a href="lwg-defects.html#578">578</a>, <a href="lwg-defects.html#581">581</a>, <a href="lwg-defects.html#586">586</a>, <a href="lwg-defects.html#589">589</a>, <a href="lwg-defects.html#593">593</a>, <a href="lwg-defects.html#595">595</a>, <a href="lwg-defects.html#596">596</a>, <a href="lwg-defects.html#607">607</a>, <a href="lwg-defects.html#608">608</a>, <a href="lwg-defects.html#609">609</a>, <a href="lwg-defects.html#610">610</a>, <a href="lwg-defects.html#611">611</a>, <a href="lwg-defects.html#612">612</a>, <a href="lwg-defects.html#613">613</a>, <a href="lwg-defects.html#616">616</a>, <a href="lwg-defects.html#618">618</a>, <a href="lwg-defects.html#619">619</a>, <a href="lwg-defects.html#620">620</a>, <a href="lwg-defects.html#621">621</a>, <a href="lwg-defects.html#622">622</a>, <a href="lwg-defects.html#623">623</a>, <a href="lwg-defects.html#624">624</a>, <a href="lwg-defects.html#628">628</a>, <a href="lwg-defects.html#634">634</a>, <a href="lwg-defects.html#638">638</a>, <a href="lwg-defects.html#640">640</a>, <a href="lwg-defects.html#643">643</a>, <a href="lwg-defects.html#646">646</a>, <a href="lwg-defects.html#650">650</a>, <a href="lwg-defects.html#651">651</a>, <a href="lwg-defects.html#652">652</a>, <a href="lwg-defects.html#654">654</a>, <a href="lwg-defects.html#655">655</a>, <a href="lwg-defects.html#660">660</a>, <a href="lwg-defects.html#661">661</a>, <a href="lwg-defects.html#664">664</a>, <a href="lwg-defects.html#665">665</a>, <a href="lwg-defects.html#666">666</a>, <a href="lwg-defects.html#672">672</a>, <a href="lwg-defects.html#673">673</a>, <a href="lwg-defects.html#674">674</a>, <a href="lwg-defects.html#677">677</a>, <a href="lwg-defects.html#678">678</a>, <a href="lwg-defects.html#679">679</a>, <a href="lwg-defects.html#680">680</a>, <a href="lwg-defects.html#681">681</a>, <a href="lwg-defects.html#682">682</a>, <a href="lwg-defects.html#685">685</a>, <a href="lwg-defects.html#687">687</a>, <a href="lwg-defects.html#689">689</a>, <a href="lwg-defects.html#693">693</a>, <a href="lwg-defects.html#694">694</a>, <a href="lwg-defects.html#695">695</a>, <a href="lwg-defects.html#699">699</a>, <a href="lwg-defects.html#700">700</a>, <a href="lwg-defects.html#703">703</a>, <a href="lwg-defects.html#705">705</a>, <a href="lwg-defects.html#706">706</a>, <a href="lwg-defects.html#710">710</a>, <a href="lwg-defects.html#712">712</a>, <a href="lwg-defects.html#715">715</a>, <a href="lwg-defects.html#722">722</a>, <a href="lwg-defects.html#740">740</a>, <a href="lwg-defects.html#743">743</a>, <a href="lwg-defects.html#744">744</a>, <a href="lwg-defects.html#746">746</a>, <a href="lwg-defects.html#749">749</a>, <a href="lwg-defects.html#755">755</a>, <a href="lwg-defects.html#759">759</a>, <a href="lwg-defects.html#761">761</a>, <a href="lwg-defects.html#766">766</a>, <a href="lwg-defects.html#768">768</a>, <a href="lwg-defects.html#770">770</a>, <a href="lwg-defects.html#775">775</a>, <a href="lwg-defects.html#777">777</a>, <a href="lwg-defects.html#778">778</a>, <a href="lwg-defects.html#781">781</a>, <a href="lwg-defects.html#782">782</a>, <a href="lwg-defects.html#783">783</a>, <a href="lwg-defects.html#789">789</a>, <a href="lwg-defects.html#792">792</a>, <a href="lwg-defects.html#798">798</a>.</li>
<li>Changed the following issues from Open to Dup: <a href="lwg-closed.html#670">670</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#849">849</a>, <a href="lwg-closed.html#855">855</a>, <a href="lwg-defects.html#871">871</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#454">454</a>, <a href="lwg-closed.html#832">832</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#811">811</a>, <a href="lwg-closed.html#812">812</a>, <a href="lwg-closed.html#841">841</a>, <a href="lwg-closed.html#864">864</a>, <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#872">872</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#299">299</a>, <a href="lwg-closed.html#484">484</a>, <a href="lwg-defects.html#556">556</a>, <a href="lwg-closed.html#631">631</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#742">742</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#532">532</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-closed.html#717">717</a>, <a href="lwg-closed.html#725">725</a>, <a href="lwg-closed.html#738">738</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-closed.html#721">721</a>, <a href="lwg-closed.html#751">751</a>, <a href="lwg-defects.html#814">814</a>, <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#817">817</a>, <a href="lwg-defects.html#819">819</a>, <a href="lwg-defects.html#827">827</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-defects.html#838">838</a>, <a href="lwg-defects.html#847">847</a>, <a href="lwg-defects.html#857">857</a>, <a href="lwg-defects.html#859">859</a>, <a href="lwg-defects.html#860">860</a>, <a href="lwg-defects.html#861">861</a>, <a href="lwg-defects.html#868">868</a>, <a href="lwg-closed.html#873">873</a>, <a href="lwg-defects.html#876">876</a>, <a href="lwg-closed.html#877">877</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to Open: <a href="lwg-closed.html#424">424</a>, <a href="lwg-defects.html#625">625</a>.</li>
<li>Changed the following issues from Review to Open: <a href="lwg-closed.html#851">851</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#788">788</a>, <a href="lwg-defects.html#821">821</a>, <a href="lwg-defects.html#866">866</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#753">753</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#752">752</a>, <a href="lwg-defects.html#758">758</a>, <a href="lwg-defects.html#803">803</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#765">765</a>, <a href="lwg-closed.html#822">822</a>, <a href="lwg-defects.html#853">853</a>, <a href="lwg-defects.html#854">854</a>, <a href="lwg-defects.html#869">869</a>, <a href="lwg-defects.html#878">878</a>.</li>
<li>Changed the following issues from TC to TC1: <a href="lwg-defects.html#1">1</a>, <a href="lwg-defects.html#3">3</a>, <a href="lwg-defects.html#5">5</a>, <a href="lwg-defects.html#7">7</a>, <a href="lwg-defects.html#8">8</a>, <a href="lwg-defects.html#9">9</a>, <a href="lwg-defects.html#11">11</a>, <a href="lwg-defects.html#13">13</a>, <a href="lwg-defects.html#14">14</a>, <a href="lwg-defects.html#15">15</a>, <a href="lwg-defects.html#16">16</a>, <a href="lwg-defects.html#17">17</a>, <a href="lwg-defects.html#18">18</a>, <a href="lwg-defects.html#19">19</a>, <a href="lwg-defects.html#20">20</a>, <a href="lwg-defects.html#21">21</a>, <a href="lwg-defects.html#22">22</a>, <a href="lwg-defects.html#24">24</a>, <a href="lwg-defects.html#25">25</a>, <a href="lwg-defects.html#26">26</a>, <a href="lwg-defects.html#27">27</a>, <a href="lwg-defects.html#28">28</a>, <a href="lwg-defects.html#29">29</a>, <a href="lwg-defects.html#30">30</a>, <a href="lwg-defects.html#31">31</a>, <a href="lwg-defects.html#32">32</a>, <a href="lwg-defects.html#33">33</a>, <a href="lwg-defects.html#34">34</a>, <a href="lwg-defects.html#35">35</a>, <a href="lwg-defects.html#36">36</a>, <a href="lwg-defects.html#37">37</a>, <a href="lwg-defects.html#38">38</a>, <a href="lwg-defects.html#39">39</a>, <a href="lwg-defects.html#40">40</a>, <a href="lwg-defects.html#41">41</a>, <a href="lwg-defects.html#42">42</a>, <a href="lwg-defects.html#46">46</a>, <a href="lwg-defects.html#47">47</a>, <a href="lwg-defects.html#48">48</a>, <a href="lwg-defects.html#50">50</a>, <a href="lwg-defects.html#51">51</a>, <a href="lwg-defects.html#52">52</a>, <a href="lwg-defects.html#53">53</a>, <a href="lwg-defects.html#54">54</a>, <a href="lwg-defects.html#55">55</a>, <a href="lwg-defects.html#56">56</a>, <a href="lwg-defects.html#57">57</a>, <a href="lwg-defects.html#59">59</a>, <a href="lwg-defects.html#60">60</a>, <a href="lwg-defects.html#61">61</a>, <a href="lwg-defects.html#62">62</a>, <a href="lwg-defects.html#63">63</a>, <a href="lwg-defects.html#64">64</a>, <a href="lwg-defects.html#66">66</a>, <a href="lwg-defects.html#68">68</a>, <a href="lwg-defects.html#69">69</a>, <a href="lwg-defects.html#70">70</a>, <a href="lwg-defects.html#71">71</a>, <a href="lwg-defects.html#74">74</a>, <a href="lwg-defects.html#75">75</a>, <a href="lwg-defects.html#78">78</a>, <a href="lwg-defects.html#79">79</a>, <a href="lwg-defects.html#80">80</a>, <a href="lwg-defects.html#83">83</a>, <a href="lwg-defects.html#86">86</a>, <a href="lwg-defects.html#90">90</a>, <a href="lwg-defects.html#106">106</a>, <a href="lwg-defects.html#108">108</a>, <a href="lwg-defects.html#110">110</a>, <a href="lwg-defects.html#112">112</a>, <a href="lwg-defects.html#114">114</a>, <a href="lwg-defects.html#115">115</a>, <a href="lwg-defects.html#119">119</a>, <a href="lwg-defects.html#122">122</a>, <a href="lwg-defects.html#124">124</a>, <a href="lwg-defects.html#125">125</a>, <a href="lwg-defects.html#126">126</a>, <a href="lwg-defects.html#127">127</a>, <a href="lwg-defects.html#129">129</a>, <a href="lwg-defects.html#132">132</a>, <a href="lwg-defects.html#133">133</a>, <a href="lwg-defects.html#134">134</a>, <a href="lwg-defects.html#137">137</a>, <a href="lwg-defects.html#139">139</a>, <a href="lwg-defects.html#141">141</a>, <a href="lwg-defects.html#142">142</a>, <a href="lwg-defects.html#144">144</a>, <a href="lwg-defects.html#146">146</a>, <a href="lwg-defects.html#147">147</a>, <a href="lwg-defects.html#148">148</a>, <a href="lwg-defects.html#150">150</a>, <a href="lwg-defects.html#151">151</a>, <a href="lwg-defects.html#152">152</a>, <a href="lwg-defects.html#154">154</a>, <a href="lwg-defects.html#155">155</a>, <a href="lwg-defects.html#156">156</a>, <a href="lwg-defects.html#158">158</a>, <a href="lwg-defects.html#159">159</a>, <a href="lwg-defects.html#160">160</a>, <a href="lwg-defects.html#161">161</a>, <a href="lwg-defects.html#164">164</a>, <a href="lwg-defects.html#168">168</a>, <a href="lwg-defects.html#169">169</a>, <a href="lwg-defects.html#170">170</a>, <a href="lwg-defects.html#172">172</a>, <a href="lwg-defects.html#173">173</a>, <a href="lwg-defects.html#174">174</a>, <a href="lwg-defects.html#175">175</a>, <a href="lwg-defects.html#176">176</a>, <a href="lwg-defects.html#181">181</a>, <a href="lwg-defects.html#189">189</a>, <a href="lwg-defects.html#193">193</a>, <a href="lwg-defects.html#195">195</a>, <a href="lwg-defects.html#199">199</a>, <a href="lwg-defects.html#208">208</a>, <a href="lwg-defects.html#209">209</a>, <a href="lwg-defects.html#210">210</a>, <a href="lwg-defects.html#211">211</a>, <a href="lwg-defects.html#212">212</a>, <a href="lwg-defects.html#217">217</a>, <a href="lwg-defects.html#220">220</a>, <a href="lwg-defects.html#222">222</a>, <a href="lwg-defects.html#223">223</a>, <a href="lwg-defects.html#224">224</a>, <a href="lwg-defects.html#227">227</a>.</li>
</ul></li>
</ul>
</li>
<li>R59: 
2008-08-22 pre-San Francisco mailing.
<ul>
<li><b>Summary:</b><ul>
<li>192 open issues, up by 9.</li>
<li>686 closed issues, up by 0.</li>
<li>878 issues total, up by 9.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#871">871</a>, <a href="lwg-defects.html#872">872</a>, <a href="lwg-closed.html#873">873</a>, <a href="lwg-defects.html#874">874</a>, <a href="lwg-defects.html#875">875</a>, <a href="lwg-defects.html#876">876</a>, <a href="lwg-closed.html#877">877</a>, <a href="lwg-defects.html#878">878</a>.</li>
</ul></li>
</ul>
</li>
<li>R58: 
2008-07-28 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>183 open issues, up by 12.</li>
<li>686 closed issues, down by 4.</li>
<li>869 issues total, up by 8.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-closed.html#862">862</a>, <a href="lwg-closed.html#863">863</a>, <a href="lwg-closed.html#864">864</a>, <a href="lwg-defects.html#865">865</a>, <a href="lwg-defects.html#866">866</a>, <a href="lwg-closed.html#867">867</a>, <a href="lwg-defects.html#868">868</a>, <a href="lwg-defects.html#869">869</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#393">393</a>, <a href="lwg-closed.html#557">557</a>, <a href="lwg-closed.html#592">592</a>, <a href="lwg-closed.html#754">754</a>, <a href="lwg-closed.html#757">757</a>.</li>
<li>Changed the following issues from Pending WP to Open: <a href="lwg-closed.html#644">644</a>.</li>
<li>Changed the following issues from WP to Ready: <a href="lwg-defects.html#387">387</a>, <a href="lwg-defects.html#629">629</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to Review: <a href="lwg-defects.html#709">709</a>.</li>
</ul></li>
</ul>
</li>
<li>R57: 
2008-06-27 post-Sophia Antipolis mailing.
<ul>
<li><b>Summary:</b><ul>
<li>171 open issues, down by 20.</li>
<li>690 closed issues, up by 43.</li>
<li>861 issues total, up by 23.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issues: <a href="lwg-closed.html#840">840</a>.</li>
<li>Added the following New issues: <a href="lwg-closed.html#841">841</a>, <a href="lwg-defects.html#843">843</a>, <a href="lwg-defects.html#845">845</a>, <a href="lwg-defects.html#846">846</a>, <a href="lwg-defects.html#847">847</a>, <a href="lwg-closed.html#849">849</a>, <a href="lwg-defects.html#853">853</a>, <a href="lwg-defects.html#854">854</a>, <a href="lwg-closed.html#855">855</a>, <a href="lwg-defects.html#856">856</a>, <a href="lwg-defects.html#857">857</a>, <a href="lwg-defects.html#858">858</a>, <a href="lwg-defects.html#859">859</a>, <a href="lwg-defects.html#860">860</a>, <a href="lwg-defects.html#861">861</a>.</li>
<li>Added the following Open issues: <a href="lwg-closed.html#839">839</a>.</li>
<li>Added the following Ready issues: <a href="lwg-defects.html#842">842</a>, <a href="lwg-defects.html#844">844</a>, <a href="lwg-defects.html#848">848</a>, <a href="lwg-defects.html#850">850</a>, <a href="lwg-defects.html#852">852</a>.</li>
<li>Added the following Review issues: <a href="lwg-closed.html#851">851</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#826">826</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#570">570</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#786">786</a>, <a href="lwg-closed.html#831">831</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-defects.html#756">756</a>, <a href="lwg-defects.html#767">767</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#723">723</a>, <a href="lwg-closed.html#726">726</a>, <a href="lwg-defects.html#794">794</a>, <a href="lwg-defects.html#815">815</a>, <a href="lwg-defects.html#825">825</a>, <a href="lwg-closed.html#830">830</a>, <a href="lwg-closed.html#833">833</a>, <a href="lwg-defects.html#834">834</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="lwg-defects.html#471">471</a>.</li>
<li>Changed the following issues from Review to Open: <a href="lwg-defects.html#539">539</a>, <a href="lwg-defects.html#711">711</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#713">713</a>, <a href="lwg-defects.html#714">714</a>, <a href="lwg-defects.html#769">769</a>, <a href="lwg-defects.html#772">772</a>, <a href="lwg-defects.html#779">779</a>, <a href="lwg-defects.html#787">787</a>, <a href="lwg-defects.html#805">805</a>, <a href="lwg-defects.html#806">806</a>, <a href="lwg-defects.html#807">807</a>, <a href="lwg-defects.html#808">808</a>, <a href="lwg-defects.html#809">809</a>, <a href="lwg-defects.html#813">813</a>, <a href="lwg-defects.html#824">824</a>, <a href="lwg-defects.html#829">829</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#180">180</a>, <a href="lwg-defects.html#396">396</a>, <a href="lwg-defects.html#522">522</a>, <a href="lwg-defects.html#720">720</a>, <a href="lwg-defects.html#762">762</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#691">691</a>, <a href="lwg-defects.html#728">728</a>, <a href="lwg-defects.html#771">771</a>, <a href="lwg-defects.html#776">776</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#692">692</a>, <a href="lwg-defects.html#698">698</a>, <a href="lwg-defects.html#752">752</a>, <a href="lwg-defects.html#804">804</a>, <a href="lwg-defects.html#823">823</a>, <a href="lwg-defects.html#828">828</a>, <a href="lwg-closed.html#832">832</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#23">23</a>, <a href="lwg-defects.html#675">675</a>, <a href="lwg-defects.html#734">734</a>, <a href="lwg-defects.html#803">803</a>.</li>
<li>Changed the following issues from Ready to Review: <a href="lwg-defects.html#758">758</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#387">387</a>, <a href="lwg-defects.html#518">518</a>, <a href="lwg-defects.html#550">550</a>, <a href="lwg-defects.html#574">574</a>, <a href="lwg-defects.html#595">595</a>, <a href="lwg-defects.html#596">596</a>, <a href="lwg-defects.html#612">612</a>, <a href="lwg-defects.html#618">618</a>, <a href="lwg-defects.html#629">629</a>, <a href="lwg-defects.html#638">638</a>, <a href="lwg-defects.html#672">672</a>, <a href="lwg-defects.html#673">673</a>, <a href="lwg-defects.html#685">685</a>, <a href="lwg-defects.html#710">710</a>, <a href="lwg-defects.html#715">715</a>, <a href="lwg-defects.html#722">722</a>, <a href="lwg-defects.html#740">740</a>, <a href="lwg-defects.html#743">743</a>, <a href="lwg-defects.html#744">744</a>, <a href="lwg-defects.html#746">746</a>, <a href="lwg-defects.html#749">749</a>, <a href="lwg-defects.html#755">755</a>, <a href="lwg-defects.html#759">759</a>, <a href="lwg-defects.html#761">761</a>, <a href="lwg-defects.html#766">766</a>, <a href="lwg-defects.html#768">768</a>, <a href="lwg-defects.html#770">770</a>, <a href="lwg-defects.html#775">775</a>, <a href="lwg-defects.html#777">777</a>, <a href="lwg-defects.html#778">778</a>, <a href="lwg-defects.html#781">781</a>, <a href="lwg-defects.html#782">782</a>, <a href="lwg-defects.html#783">783</a>, <a href="lwg-defects.html#789">789</a>, <a href="lwg-defects.html#792">792</a>, <a href="lwg-defects.html#798">798</a>.</li>
</ul></li>
</ul>
</li>
<li>R56: 
2008-05-16 pre-Sophia Antipolis mailing.
<ul>
<li><b>Summary:</b><ul>
<li>191 open issues, up by 24.</li>
<li>647 closed issues, up by 1.</li>
<li>838 issues total, up by 25.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#814">814</a>, <a href="lwg-defects.html#815">815</a>, <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#817">817</a>, <a href="lwg-defects.html#818">818</a>, <a href="lwg-defects.html#819">819</a>, <a href="lwg-defects.html#820">820</a>, <a href="lwg-defects.html#821">821</a>, <a href="lwg-closed.html#822">822</a>, <a href="lwg-defects.html#823">823</a>, <a href="lwg-defects.html#824">824</a>, <a href="lwg-defects.html#825">825</a>, <a href="lwg-closed.html#826">826</a>, <a href="lwg-defects.html#827">827</a>, <a href="lwg-defects.html#828">828</a>, <a href="lwg-defects.html#829">829</a>, <a href="lwg-closed.html#830">830</a>, <a href="lwg-closed.html#831">831</a>, <a href="lwg-closed.html#832">832</a>, <a href="lwg-closed.html#833">833</a>, <a href="lwg-defects.html#834">834</a>, <a href="lwg-defects.html#835">835</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-closed.html#837">837</a>, <a href="lwg-defects.html#838">838</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#802">802</a>.</li>
</ul></li>
</ul>
</li>
<li>R55: 
2008-03-14 post-Bellevue mailing.
<ul>
<li><b>Summary:</b><ul>
<li>167 open issues, down by 39.</li>
<li>646 closed issues, up by 65.</li>
<li>813 issues total, up by 26.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following Dup issues: <a href="lwg-closed.html#795">795</a>.</li>
<li>Added the following NAD issues: <a href="lwg-closed.html#790">790</a>, <a href="lwg-closed.html#791">791</a>, <a href="lwg-closed.html#796">796</a>, <a href="lwg-closed.html#797">797</a>, <a href="lwg-closed.html#799">799</a>.</li>
<li>Added the following New issues: <a href="lwg-defects.html#788">788</a>, <a href="lwg-defects.html#794">794</a>, <a href="lwg-closed.html#802">802</a>, <a href="lwg-defects.html#804">804</a>, <a href="lwg-defects.html#805">805</a>, <a href="lwg-defects.html#806">806</a>, <a href="lwg-defects.html#807">807</a>, <a href="lwg-defects.html#808">808</a>, <a href="lwg-defects.html#809">809</a>, <a href="lwg-defects.html#810">810</a>, <a href="lwg-defects.html#811">811</a>, <a href="lwg-closed.html#812">812</a>, <a href="lwg-defects.html#813">813</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#793">793</a>, <a href="lwg-defects.html#800">800</a>, <a href="lwg-defects.html#801">801</a>, <a href="lwg-defects.html#803">803</a>.</li>
<li>Added the following Ready issues: <a href="lwg-defects.html#789">789</a>, <a href="lwg-defects.html#792">792</a>, <a href="lwg-defects.html#798">798</a>.</li>
<li>Changed the following issues from NAD Future to Dup: <a href="lwg-closed.html#116">116</a>.</li>
<li>Changed the following issues from NAD Future to NAD: <a href="lwg-closed.html#188">188</a>, <a href="lwg-closed.html#323">323</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#729">729</a>, <a href="lwg-closed.html#730">730</a>, <a href="lwg-closed.html#731">731</a>, <a href="lwg-closed.html#733">733</a>, <a href="lwg-closed.html#735">735</a>, <a href="lwg-closed.html#736">736</a>, <a href="lwg-closed.html#737">737</a>, <a href="lwg-closed.html#739">739</a>, <a href="lwg-closed.html#741">741</a>, <a href="lwg-closed.html#745">745</a>, <a href="lwg-closed.html#748">748</a>, <a href="lwg-closed.html#763">763</a>, <a href="lwg-closed.html#764">764</a>, <a href="lwg-closed.html#773">773</a>, <a href="lwg-closed.html#784">784</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#388">388</a>, <a href="lwg-closed.html#462">462</a>, <a href="lwg-closed.html#579">579</a>, <a href="lwg-closed.html#627">627</a>, <a href="lwg-closed.html#653">653</a>, <a href="lwg-closed.html#686">686</a>, <a href="lwg-closed.html#707">707</a>.</li>
<li>Changed the following issues from NAD Future to NAD Editorial: <a href="lwg-closed.html#140">140</a>, <a href="lwg-closed.html#390">390</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#529">529</a>, <a href="lwg-closed.html#626">626</a>.</li>
<li>Changed the following issues from Review to NAD Editorial: <a href="lwg-closed.html#645">645</a>, <a href="lwg-closed.html#684">684</a>.</li>
<li>Changed the following issues from NAD Future to Open: <a href="lwg-closed.html#128">128</a>, <a href="lwg-defects.html#180">180</a>, <a href="lwg-closed.html#190">190</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-closed.html#617">617</a>, <a href="lwg-closed.html#718">718</a>, <a href="lwg-defects.html#719">719</a>, <a href="lwg-defects.html#720">720</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#732">732</a>, <a href="lwg-defects.html#734">734</a>, <a href="lwg-defects.html#742">742</a>, <a href="lwg-closed.html#747">747</a>, <a href="lwg-closed.html#750">750</a>, <a href="lwg-defects.html#753">753</a>, <a href="lwg-defects.html#756">756</a>, <a href="lwg-closed.html#760">760</a>, <a href="lwg-defects.html#762">762</a>, <a href="lwg-defects.html#767">767</a>, <a href="lwg-defects.html#774">774</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="lwg-defects.html#675">675</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#688">688</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="lwg-defects.html#709">709</a>, <a href="lwg-closed.html#717">717</a>, <a href="lwg-closed.html#725">725</a>, <a href="lwg-closed.html#738">738</a>, <a href="lwg-closed.html#754">754</a>, <a href="lwg-closed.html#757">757</a>.</li>
<li>Changed the following issues from Open to Pending NAD Editorial: <a href="lwg-closed.html#424">424</a>, <a href="lwg-closed.html#557">557</a>, <a href="lwg-defects.html#625">625</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#710">710</a>, <a href="lwg-defects.html#715">715</a>, <a href="lwg-defects.html#722">722</a>, <a href="lwg-defects.html#740">740</a>, <a href="lwg-defects.html#743">743</a>, <a href="lwg-defects.html#744">744</a>, <a href="lwg-defects.html#746">746</a>, <a href="lwg-defects.html#749">749</a>, <a href="lwg-defects.html#755">755</a>, <a href="lwg-defects.html#758">758</a>, <a href="lwg-defects.html#759">759</a>, <a href="lwg-defects.html#761">761</a>, <a href="lwg-defects.html#766">766</a>, <a href="lwg-defects.html#768">768</a>, <a href="lwg-defects.html#770">770</a>, <a href="lwg-defects.html#775">775</a>, <a href="lwg-defects.html#777">777</a>, <a href="lwg-defects.html#778">778</a>, <a href="lwg-defects.html#781">781</a>, <a href="lwg-defects.html#782">782</a>, <a href="lwg-defects.html#783">783</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#387">387</a>, <a href="lwg-defects.html#471">471</a>, <a href="lwg-defects.html#550">550</a>, <a href="lwg-defects.html#612">612</a>, <a href="lwg-defects.html#629">629</a>, <a href="lwg-defects.html#673">673</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#518">518</a>, <a href="lwg-defects.html#574">574</a>, <a href="lwg-defects.html#596">596</a>, <a href="lwg-defects.html#618">618</a>, <a href="lwg-defects.html#638">638</a>, <a href="lwg-defects.html#672">672</a>, <a href="lwg-defects.html#685">685</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#711">711</a>, <a href="lwg-defects.html#728">728</a>, <a href="lwg-defects.html#771">771</a>, <a href="lwg-defects.html#776">776</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#539">539</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#561">561</a>, <a href="lwg-defects.html#562">562</a>, <a href="lwg-defects.html#563">563</a>, <a href="lwg-defects.html#567">567</a>, <a href="lwg-defects.html#581">581</a>, <a href="lwg-defects.html#620">620</a>, <a href="lwg-defects.html#621">621</a>, <a href="lwg-defects.html#622">622</a>, <a href="lwg-defects.html#623">623</a>, <a href="lwg-defects.html#624">624</a>, <a href="lwg-defects.html#661">661</a>, <a href="lwg-defects.html#664">664</a>, <a href="lwg-defects.html#665">665</a>, <a href="lwg-defects.html#666">666</a>, <a href="lwg-defects.html#674">674</a>, <a href="lwg-defects.html#679">679</a>, <a href="lwg-defects.html#680">680</a>, <a href="lwg-defects.html#687">687</a>, <a href="lwg-defects.html#689">689</a>, <a href="lwg-defects.html#693">693</a>, <a href="lwg-defects.html#694">694</a>, <a href="lwg-defects.html#695">695</a>, <a href="lwg-defects.html#700">700</a>, <a href="lwg-defects.html#703">703</a>, <a href="lwg-defects.html#705">705</a>, <a href="lwg-defects.html#706">706</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="lwg-defects.html#527">527</a>.</li>
</ul></li>
</ul>
</li>
<li>R54: 
2008-02-01 pre-Bellevue mailing.
<ul>
<li><b>Summary:</b><ul>
<li>206 open issues, up by 23.</li>
<li>581 closed issues, up by 0.</li>
<li>787 issues total, up by 23.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#765">765</a>, <a href="lwg-defects.html#766">766</a>, <a href="lwg-defects.html#767">767</a>, <a href="lwg-defects.html#768">768</a>, <a href="lwg-defects.html#769">769</a>, <a href="lwg-defects.html#770">770</a>, <a href="lwg-defects.html#771">771</a>, <a href="lwg-defects.html#772">772</a>, <a href="lwg-closed.html#773">773</a>, <a href="lwg-defects.html#774">774</a>, <a href="lwg-defects.html#775">775</a>, <a href="lwg-defects.html#776">776</a>, <a href="lwg-defects.html#777">777</a>, <a href="lwg-defects.html#778">778</a>, <a href="lwg-defects.html#779">779</a>, <a href="lwg-defects.html#780">780</a>, <a href="lwg-defects.html#781">781</a>, <a href="lwg-defects.html#782">782</a>, <a href="lwg-defects.html#783">783</a>, <a href="lwg-closed.html#784">784</a>, <a href="lwg-closed.html#785">785</a>, <a href="lwg-defects.html#786">786</a>, <a href="lwg-defects.html#787">787</a>.</li>
<li>Changed the following issues from NAD Future to Dup: <a href="lwg-closed.html#105">105</a>, <a href="lwg-closed.html#348">348</a>.</li>
<li>Changed the following issues from NAD Future to NAD Editorial: <a href="lwg-defects.html#353">353</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#697">697</a>.</li>
<li>Changed the following issues from NAD Future to Open: <a href="lwg-closed.html#388">388</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#527">527</a>.</li>
</ul></li>
</ul>
</li>
<li>R53: 
2007-12-09 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>183 open issues, up by 11.</li>
<li>581 closed issues, down by 1.</li>
<li>764 issues total, up by 10.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#755">755</a>, <a href="lwg-defects.html#756">756</a>, <a href="lwg-closed.html#757">757</a>, <a href="lwg-defects.html#758">758</a>, <a href="lwg-defects.html#759">759</a>, <a href="lwg-closed.html#760">760</a>, <a href="lwg-defects.html#761">761</a>, <a href="lwg-defects.html#762">762</a>, <a href="lwg-closed.html#763">763</a>, <a href="lwg-closed.html#764">764</a>.</li>
<li>Changed the following issues from NAD to Open: <a href="lwg-closed.html#463">463</a>.</li>
<li>Changed the following issues from Pending WP to WP: <a href="lwg-defects.html#607">607</a>, <a href="lwg-defects.html#608">608</a>, <a href="lwg-defects.html#654">654</a>, <a href="lwg-defects.html#655">655</a>, <a href="lwg-defects.html#677">677</a>, <a href="lwg-defects.html#682">682</a>.</li>
</ul></li>
</ul>
</li>
<li>R52: 
2007-10-19 post-Kona mailing.
<ul>
<li><b>Summary:</b><ul>
<li>172 open issues, up by 4.</li>
<li>582 closed issues, up by 27.</li>
<li>754 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#724">724</a>, <a href="lwg-closed.html#725">725</a>, <a href="lwg-closed.html#726">726</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#728">728</a>, <a href="lwg-closed.html#729">729</a>, <a href="lwg-closed.html#730">730</a>, <a href="lwg-closed.html#731">731</a>, <a href="lwg-defects.html#732">732</a>, <a href="lwg-closed.html#733">733</a>, <a href="lwg-defects.html#734">734</a>, <a href="lwg-closed.html#735">735</a>, <a href="lwg-closed.html#736">736</a>, <a href="lwg-closed.html#737">737</a>, <a href="lwg-closed.html#738">738</a>, <a href="lwg-closed.html#739">739</a>, <a href="lwg-defects.html#740">740</a>, <a href="lwg-closed.html#741">741</a>, <a href="lwg-defects.html#742">742</a>, <a href="lwg-defects.html#743">743</a>, <a href="lwg-defects.html#744">744</a>, <a href="lwg-closed.html#745">745</a>, <a href="lwg-defects.html#746">746</a>, <a href="lwg-closed.html#747">747</a>, <a href="lwg-closed.html#748">748</a>, <a href="lwg-defects.html#749">749</a>, <a href="lwg-closed.html#750">750</a>, <a href="lwg-closed.html#751">751</a>, <a href="lwg-defects.html#752">752</a>, <a href="lwg-defects.html#753">753</a>, <a href="lwg-closed.html#754">754</a>.</li>
<li>Changed the following issues from NAD Future to Dup: <a href="lwg-closed.html#77">77</a>, <a href="lwg-closed.html#350">350</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#639">639</a>, <a href="lwg-closed.html#657">657</a>, <a href="lwg-closed.html#663">663</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#548">548</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-closed.html#546">546</a>, <a href="lwg-defects.html#550">550</a>, <a href="lwg-defects.html#564">564</a>, <a href="lwg-defects.html#565">565</a>, <a href="lwg-closed.html#573">573</a>, <a href="lwg-closed.html#585">585</a>, <a href="lwg-closed.html#588">588</a>, <a href="lwg-closed.html#627">627</a>, <a href="lwg-defects.html#629">629</a>, <a href="lwg-defects.html#630">630</a>, <a href="lwg-closed.html#632">632</a>, <a href="lwg-defects.html#635">635</a>, <a href="lwg-closed.html#653">653</a>, <a href="lwg-defects.html#659">659</a>, <a href="lwg-closed.html#667">667</a>, <a href="lwg-closed.html#668">668</a>, <a href="lwg-closed.html#669">669</a>, <a href="lwg-closed.html#670">670</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#673">673</a>, <a href="lwg-closed.html#686">686</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-closed.html#707">707</a>, <a href="lwg-closed.html#708">708</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="lwg-closed.html#393">393</a>, <a href="lwg-closed.html#592">592</a>.</li>
<li>Changed the following issues from New to Pending WP: <a href="lwg-defects.html#607">607</a>, <a href="lwg-defects.html#608">608</a>, <a href="lwg-defects.html#654">654</a>, <a href="lwg-defects.html#655">655</a>, <a href="lwg-defects.html#677">677</a>, <a href="lwg-defects.html#682">682</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#561">561</a>, <a href="lwg-defects.html#562">562</a>, <a href="lwg-defects.html#563">563</a>, <a href="lwg-defects.html#567">567</a>, <a href="lwg-defects.html#581">581</a>, <a href="lwg-defects.html#595">595</a>, <a href="lwg-defects.html#620">620</a>, <a href="lwg-defects.html#621">621</a>, <a href="lwg-defects.html#622">622</a>, <a href="lwg-defects.html#623">623</a>, <a href="lwg-defects.html#624">624</a>, <a href="lwg-defects.html#661">661</a>, <a href="lwg-defects.html#664">664</a>, <a href="lwg-defects.html#665">665</a>, <a href="lwg-defects.html#666">666</a>, <a href="lwg-defects.html#674">674</a>, <a href="lwg-defects.html#675">675</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#679">679</a>, <a href="lwg-defects.html#687">687</a>, <a href="lwg-defects.html#688">688</a>, <a href="lwg-defects.html#689">689</a>, <a href="lwg-defects.html#693">693</a>, <a href="lwg-defects.html#694">694</a>, <a href="lwg-defects.html#695">695</a>, <a href="lwg-defects.html#700">700</a>, <a href="lwg-defects.html#703">703</a>, <a href="lwg-defects.html#705">705</a>, <a href="lwg-defects.html#706">706</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#680">680</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#574">574</a>, <a href="lwg-defects.html#596">596</a>, <a href="lwg-defects.html#618">618</a>, <a href="lwg-defects.html#638">638</a>, <a href="lwg-closed.html#645">645</a>, <a href="lwg-defects.html#672">672</a>, <a href="lwg-closed.html#684">684</a>, <a href="lwg-defects.html#685">685</a>, <a href="lwg-defects.html#691">691</a>.</li>
<li>Changed the following issues from New to WP: <a href="lwg-defects.html#552">552</a>, <a href="lwg-defects.html#634">634</a>, <a href="lwg-defects.html#650">650</a>, <a href="lwg-defects.html#651">651</a>, <a href="lwg-defects.html#652">652</a>, <a href="lwg-defects.html#678">678</a>, <a href="lwg-defects.html#681">681</a>, <a href="lwg-defects.html#699">699</a>, <a href="lwg-defects.html#712">712</a>.</li>
<li>Changed the following issues from Open to WP: <a href="lwg-defects.html#258">258</a>, <a href="lwg-defects.html#401">401</a>, <a href="lwg-defects.html#524">524</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#488">488</a>, <a href="lwg-defects.html#577">577</a>, <a href="lwg-defects.html#660">660</a>.</li>
</ul></li>
</ul>
</li>
<li>R51: 
2007-09-09 pre-Kona mailing.
<ul>
<li><b>Summary:</b><ul>
<li>168 open issues, up by 15.</li>
<li>555 closed issues, up by 0.</li>
<li>723 issues total, up by 15.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#709">709</a>, <a href="lwg-defects.html#710">710</a>, <a href="lwg-defects.html#711">711</a>, <a href="lwg-defects.html#712">712</a>, <a href="lwg-defects.html#713">713</a>, <a href="lwg-defects.html#714">714</a>, <a href="lwg-defects.html#715">715</a>, <a href="lwg-defects.html#716">716</a>, <a href="lwg-closed.html#717">717</a>, <a href="lwg-closed.html#718">718</a>, <a href="lwg-defects.html#719">719</a>, <a href="lwg-defects.html#720">720</a>, <a href="lwg-closed.html#721">721</a>, <a href="lwg-defects.html#722">722</a>, <a href="lwg-defects.html#723">723</a>.</li>
</ul></li>
</ul>
</li>
<li>R50: 
2007-08-05 post-Toronto mailing.
<ul>
<li><b>Summary:</b><ul>
<li>153 open issues, down by 5.</li>
<li>555 closed issues, up by 17.</li>
<li>708 issues total, up by 12.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#697">697</a>, <a href="lwg-defects.html#698">698</a>, <a href="lwg-defects.html#699">699</a>, <a href="lwg-defects.html#700">700</a>, <a href="lwg-closed.html#701">701</a>, <a href="lwg-closed.html#702">702</a>, <a href="lwg-defects.html#703">703</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#705">705</a>, <a href="lwg-defects.html#706">706</a>, <a href="lwg-closed.html#707">707</a>, <a href="lwg-closed.html#708">708</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#583">583</a>, <a href="lwg-closed.html#584">584</a>, <a href="lwg-closed.html#662">662</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#528">528</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-closed.html#637">637</a>, <a href="lwg-closed.html#647">647</a>, <a href="lwg-defects.html#658">658</a>, <a href="lwg-closed.html#690">690</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-defects.html#525">525</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#553">553</a>, <a href="lwg-closed.html#571">571</a>, <a href="lwg-closed.html#591">591</a>, <a href="lwg-closed.html#633">633</a>, <a href="lwg-closed.html#636">636</a>, <a href="lwg-closed.html#641">641</a>, <a href="lwg-closed.html#642">642</a>, <a href="lwg-closed.html#648">648</a>, <a href="lwg-closed.html#649">649</a>, <a href="lwg-closed.html#656">656</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-closed.html#579">579</a>, <a href="lwg-closed.html#631">631</a>, <a href="lwg-defects.html#680">680</a>.</li>
<li>Changed the following issues from Pending WP to Open: <a href="lwg-defects.html#258">258</a>.</li>
<li>Changed the following issues from Ready to Pending WP: <a href="lwg-closed.html#644">644</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#577">577</a>, <a href="lwg-defects.html#660">660</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#488">488</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#518">518</a>.</li>
<li>Changed the following issues from Ready to TRDec: <a href="lwg-defects.html#604">604</a>.</li>
<li>Changed the following issues from DR to WP: <a href="lwg-defects.html#453">453</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#531">531</a>, <a href="lwg-defects.html#551">551</a>, <a href="lwg-defects.html#566">566</a>, <a href="lwg-defects.html#628">628</a>, <a href="lwg-defects.html#640">640</a>, <a href="lwg-defects.html#643">643</a>, <a href="lwg-defects.html#646">646</a>.</li>
</ul></li>
</ul>
</li>
<li>R49: 
2007-06-23 pre-Toronto mailing.
<ul>
<li><b>Summary:</b><ul>
<li>158 open issues, up by 13.</li>
<li>538 closed issues, up by 7.</li>
<li>696 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#677">677</a>, <a href="lwg-defects.html#678">678</a>, <a href="lwg-defects.html#679">679</a>, <a href="lwg-defects.html#680">680</a>, <a href="lwg-defects.html#681">681</a>, <a href="lwg-defects.html#682">682</a>, <a href="lwg-closed.html#684">684</a>, <a href="lwg-defects.html#685">685</a>, <a href="lwg-closed.html#686">686</a>, <a href="lwg-defects.html#687">687</a>, <a href="lwg-defects.html#688">688</a>, <a href="lwg-defects.html#689">689</a>, <a href="lwg-closed.html#690">690</a>, <a href="lwg-defects.html#691">691</a>, <a href="lwg-defects.html#692">692</a>, <a href="lwg-defects.html#693">693</a>, <a href="lwg-defects.html#694">694</a>, <a href="lwg-defects.html#695">695</a>, <a href="lwg-defects.html#696">696</a>.</li>
<li>Added the following Pending NAD Editorial issues: <a href="lwg-closed.html#683">683</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-closed.html#587">587</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#590">590</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="lwg-closed.html#636">636</a>, <a href="lwg-closed.html#642">642</a>, <a href="lwg-closed.html#648">648</a>, <a href="lwg-closed.html#649">649</a>.</li>
</ul></li>
</ul>
</li>
<li>R48: 
2007-05-06 post-Oxford mailing.
<ul>
<li><b>Summary:</b><ul>
<li>145 open issues, down by 33.</li>
<li>531 closed issues, up by 53.</li>
<li>676 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-closed.html#657">657</a>, <a href="lwg-defects.html#658">658</a>, <a href="lwg-defects.html#659">659</a>, <a href="lwg-defects.html#660">660</a>, <a href="lwg-defects.html#661">661</a>, <a href="lwg-closed.html#662">662</a>, <a href="lwg-closed.html#663">663</a>, <a href="lwg-defects.html#664">664</a>, <a href="lwg-defects.html#665">665</a>, <a href="lwg-defects.html#666">666</a>, <a href="lwg-closed.html#667">667</a>, <a href="lwg-closed.html#668">668</a>, <a href="lwg-closed.html#669">669</a>, <a href="lwg-closed.html#670">670</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#672">672</a>, <a href="lwg-defects.html#673">673</a>, <a href="lwg-defects.html#674">674</a>, <a href="lwg-defects.html#675">675</a>, <a href="lwg-defects.html#676">676</a>.</li>
<li>Changed the following issues from Tentatively Ready to Dup: <a href="lwg-closed.html#479">479</a>, <a href="lwg-closed.html#536">536</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD: <a href="lwg-closed.html#385">385</a>, <a href="lwg-closed.html#463">463</a>, <a href="lwg-closed.html#466">466</a>, <a href="lwg-closed.html#470">470</a>, <a href="lwg-closed.html#515">515</a>, <a href="lwg-closed.html#526">526</a>, <a href="lwg-closed.html#547">547</a>, <a href="lwg-closed.html#560">560</a>, <a href="lwg-closed.html#572">572</a>.</li>
<li>Changed the following issues from NAD to NAD Editorial: <a href="lwg-closed.html#351">351</a>, <a href="lwg-closed.html#357">357</a>, <a href="lwg-closed.html#368">368</a>, <a href="lwg-closed.html#499">499</a>, <a href="lwg-closed.html#504">504</a>, <a href="lwg-closed.html#512">512</a>, <a href="lwg-closed.html#513">513</a>, <a href="lwg-closed.html#514">514</a>, <a href="lwg-closed.html#516">516</a>, <a href="lwg-closed.html#544">544</a>, <a href="lwg-closed.html#549">549</a>, <a href="lwg-closed.html#555">555</a>, <a href="lwg-closed.html#558">558</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="lwg-defects.html#482">482</a>, <a href="lwg-closed.html#615">615</a>.</li>
<li>Changed the following issues from NAD_Future to NAD Future: <a href="lwg-closed.html#77">77</a>, <a href="lwg-closed.html#105">105</a>, <a href="lwg-closed.html#111">111</a>, <a href="lwg-closed.html#116">116</a>, <a href="lwg-closed.html#128">128</a>, <a href="lwg-closed.html#138">138</a>, <a href="lwg-closed.html#140">140</a>, <a href="lwg-defects.html#149">149</a>, <a href="lwg-defects.html#180">180</a>, <a href="lwg-closed.html#188">188</a>, <a href="lwg-closed.html#190">190</a>, <a href="lwg-closed.html#219">219</a>, <a href="lwg-closed.html#323">323</a>, <a href="lwg-closed.html#348">348</a>, <a href="lwg-closed.html#350">350</a>, <a href="lwg-defects.html#353">353</a>, <a href="lwg-closed.html#388">388</a>, <a href="lwg-closed.html#390">390</a>.</li>
<li>Changed the following issues from Tentatively Ready to Open: <a href="lwg-defects.html#471">471</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="lwg-closed.html#633">633</a>, <a href="lwg-closed.html#641">641</a>, <a href="lwg-closed.html#656">656</a>.</li>
<li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="lwg-closed.html#532">532</a>, <a href="lwg-closed.html#553">553</a>, <a href="lwg-closed.html#571">571</a>, <a href="lwg-closed.html#591">591</a>, <a href="lwg-defects.html#594">594</a>.</li>
<li>Changed the following issues from Tentatively Ready to Pending WP: <a href="lwg-defects.html#258">258</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#566">566</a>, <a href="lwg-defects.html#628">628</a>, <a href="lwg-defects.html#640">640</a>, <a href="lwg-defects.html#643">643</a>, <a href="lwg-closed.html#644">644</a>, <a href="lwg-defects.html#646">646</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#531">531</a>, <a href="lwg-defects.html#551">551</a>, <a href="lwg-defects.html#604">604</a>.</li>
<li>Changed the following issues from Ready to TRDec: <a href="lwg-defects.html#598">598</a>, <a href="lwg-defects.html#599">599</a>, <a href="lwg-defects.html#600">600</a>, <a href="lwg-defects.html#601">601</a>, <a href="lwg-defects.html#602">602</a>, <a href="lwg-defects.html#603">603</a>, <a href="lwg-defects.html#605">605</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#543">543</a>, <a href="lwg-defects.html#545">545</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="lwg-defects.html#201">201</a>, <a href="lwg-defects.html#206">206</a>, <a href="lwg-defects.html#233">233</a>, <a href="lwg-defects.html#254">254</a>, <a href="lwg-defects.html#416">416</a>, <a href="lwg-defects.html#422">422</a>, <a href="lwg-defects.html#456">456</a>, <a href="lwg-defects.html#534">534</a>, <a href="lwg-defects.html#542">542</a>, <a href="lwg-defects.html#559">559</a>, <a href="lwg-defects.html#575">575</a>, <a href="lwg-defects.html#576">576</a>, <a href="lwg-defects.html#578">578</a>, <a href="lwg-defects.html#586">586</a>, <a href="lwg-defects.html#589">589</a>, <a href="lwg-defects.html#593">593</a>, <a href="lwg-defects.html#609">609</a>, <a href="lwg-defects.html#610">610</a>, <a href="lwg-defects.html#611">611</a>, <a href="lwg-defects.html#613">613</a>, <a href="lwg-defects.html#616">616</a>, <a href="lwg-defects.html#619">619</a>.</li>
</ul></li>
</ul>
</li>
<li>R47: 
2007-03-09 pre-Oxford mailing.
<ul>
<li><b>Summary:</b><ul>
<li>178 open issues, up by 37.</li>
<li>478 closed issues, up by 0.</li>
<li>656 issues total, up by 37.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#620">620</a>, <a href="lwg-defects.html#621">621</a>, <a href="lwg-defects.html#622">622</a>, <a href="lwg-defects.html#623">623</a>, <a href="lwg-defects.html#624">624</a>, <a href="lwg-closed.html#627">627</a>, <a href="lwg-defects.html#628">628</a>, <a href="lwg-defects.html#629">629</a>, <a href="lwg-defects.html#630">630</a>, <a href="lwg-closed.html#631">631</a>, <a href="lwg-closed.html#632">632</a>, <a href="lwg-closed.html#633">633</a>, <a href="lwg-defects.html#634">634</a>, <a href="lwg-defects.html#635">635</a>, <a href="lwg-closed.html#636">636</a>, <a href="lwg-closed.html#637">637</a>, <a href="lwg-defects.html#638">638</a>, <a href="lwg-closed.html#639">639</a>, <a href="lwg-defects.html#640">640</a>, <a href="lwg-closed.html#641">641</a>, <a href="lwg-closed.html#642">642</a>, <a href="lwg-defects.html#643">643</a>, <a href="lwg-closed.html#644">644</a>, <a href="lwg-closed.html#645">645</a>, <a href="lwg-defects.html#646">646</a>, <a href="lwg-closed.html#647">647</a>, <a href="lwg-closed.html#648">648</a>, <a href="lwg-closed.html#649">649</a>, <a href="lwg-defects.html#650">650</a>, <a href="lwg-defects.html#651">651</a>, <a href="lwg-defects.html#652">652</a>, <a href="lwg-closed.html#653">653</a>, <a href="lwg-defects.html#654">654</a>, <a href="lwg-defects.html#655">655</a>, <a href="lwg-closed.html#656">656</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#625">625</a>, <a href="lwg-closed.html#626">626</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-closed.html#570">570</a>, <a href="lwg-closed.html#580">580</a>, <a href="lwg-closed.html#582">582</a>, <a href="lwg-closed.html#590">590</a>, <a href="lwg-defects.html#612">612</a>, <a href="lwg-closed.html#614">614</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-closed.html#547">547</a>, <a href="lwg-closed.html#553">553</a>, <a href="lwg-closed.html#560">560</a>, <a href="lwg-closed.html#571">571</a>, <a href="lwg-closed.html#572">572</a>, <a href="lwg-defects.html#575">575</a>, <a href="lwg-defects.html#576">576</a>, <a href="lwg-defects.html#578">578</a>, <a href="lwg-defects.html#586">586</a>, <a href="lwg-defects.html#589">589</a>, <a href="lwg-closed.html#591">591</a>, <a href="lwg-defects.html#593">593</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-defects.html#609">609</a>, <a href="lwg-defects.html#610">610</a>, <a href="lwg-defects.html#611">611</a>, <a href="lwg-defects.html#613">613</a>, <a href="lwg-closed.html#615">615</a>, <a href="lwg-defects.html#616">616</a>, <a href="lwg-defects.html#619">619</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#201">201</a>, <a href="lwg-defects.html#206">206</a>, <a href="lwg-defects.html#233">233</a>, <a href="lwg-defects.html#254">254</a>, <a href="lwg-defects.html#258">258</a>, <a href="lwg-closed.html#385">385</a>, <a href="lwg-defects.html#416">416</a>, <a href="lwg-defects.html#422">422</a>, <a href="lwg-defects.html#456">456</a>, <a href="lwg-closed.html#463">463</a>, <a href="lwg-closed.html#466">466</a>, <a href="lwg-closed.html#470">470</a>, <a href="lwg-defects.html#471">471</a>, <a href="lwg-closed.html#479">479</a>, <a href="lwg-defects.html#482">482</a>, <a href="lwg-closed.html#515">515</a>, <a href="lwg-closed.html#526">526</a>, <a href="lwg-closed.html#532">532</a>, <a href="lwg-closed.html#536">536</a>, <a href="lwg-defects.html#542">542</a>, <a href="lwg-defects.html#559">559</a>.</li>
<li>Changed the following issues from Review to Tentatively Ready: <a href="lwg-defects.html#534">534</a>.</li>
</ul></li>
</ul>
</li>
<li>R46: 
2007-01-12 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>141 open issues, up by 11.</li>
<li>478 closed issues, down by 1.</li>
<li>619 issues total, up by 10.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-defects.html#610">610</a>, <a href="lwg-defects.html#611">611</a>, <a href="lwg-defects.html#612">612</a>, <a href="lwg-defects.html#613">613</a>, <a href="lwg-closed.html#614">614</a>, <a href="lwg-closed.html#615">615</a>, <a href="lwg-defects.html#616">616</a>, <a href="lwg-closed.html#617">617</a>, <a href="lwg-defects.html#618">618</a>, <a href="lwg-defects.html#619">619</a>.</li>
</ul></li>
</ul>
</li>
<li>R45: 
2006-11-03 post-Portland mailing.
<ul>
<li><b>Summary:</b><ul>
<li>130 open issues, up by 0.</li>
<li>479 closed issues, up by 17.</li>
<li>609 issues total, up by 17.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Moved issues <a href="lwg-defects.html#520">520</a>, <a href="lwg-defects.html#521">521</a>, <a href="lwg-defects.html#530">530</a>, <a href="lwg-defects.html#535">535</a>, <a href="lwg-defects.html#537">537</a>, <a href="lwg-defects.html#538">538</a>, <a href="lwg-defects.html#540">540</a>, <a href="lwg-defects.html#541">541</a> to WP.</li>
<li>Moved issues <a href="lwg-closed.html#504">504</a>, <a href="lwg-closed.html#512">512</a>, <a href="lwg-closed.html#516">516</a>, <a href="lwg-closed.html#544">544</a>, <a href="lwg-closed.html#549">549</a>, <a href="lwg-closed.html#554">554</a>, <a href="lwg-closed.html#555">555</a>, <a href="lwg-closed.html#558">558</a> to NAD.</li>
<li>Moved issue <a href="lwg-closed.html#569">569</a> to Dup.</li>
<li>Moved issues <a href="lwg-defects.html#518">518</a>, <a href="lwg-closed.html#523">523</a>, <a href="lwg-defects.html#524">524</a>, <a href="lwg-defects.html#542">542</a>, <a href="lwg-defects.html#556">556</a>, <a href="lwg-closed.html#557">557</a>, <a href="lwg-defects.html#559">559</a>, <a href="lwg-closed.html#597">597</a>, <a href="lwg-closed.html#606">606</a> to Open.</li>
<li>Moved issues <a href="lwg-defects.html#543">543</a>, <a href="lwg-defects.html#545">545</a>, <a href="lwg-closed.html#549">549</a>, <a href="lwg-closed.html#549">549</a>, <a href="lwg-defects.html#598">598</a> - <a href="lwg-defects.html#603">603</a>, <a href="lwg-defects.html#605">605</a> to Ready.</li>
<li>Moved issues <a href="lwg-defects.html#531">531</a>, <a href="lwg-defects.html#551">551</a>, <a href="lwg-defects.html#604">604</a> to Review.</li>
<li>Added new issues <a href="lwg-defects.html#593">593</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-defects.html#595">595</a>, <a href="lwg-defects.html#596">596</a>, <a href="lwg-closed.html#597">597</a>, <a href="lwg-defects.html#598">598</a>, <a href="lwg-defects.html#599">599</a>, <a href="lwg-defects.html#600">600</a>, <a href="lwg-defects.html#601">601</a>, <a href="lwg-defects.html#602">602</a>, <a href="lwg-defects.html#603">603</a>, <a href="lwg-defects.html#604">604</a>, <a href="lwg-defects.html#605">605</a>, <a href="lwg-closed.html#606">606</a>, <a href="lwg-defects.html#607">607</a>, <a href="lwg-defects.html#608">608</a>, <a href="lwg-defects.html#609">609</a>.</li>
</ul></li>
</ul>
</li>
<li>R44: 
2006-09-08 pre-Portland mailing.
<ul>
<li><b>Summary:</b><ul>
<li>130 open issues, up by 6.</li>
<li>462 closed issues, down by 1.</li>
<li>592 issues total, up by 5.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-closed.html#583">583</a>, <a href="lwg-closed.html#584">584</a>, <a href="lwg-closed.html#585">585</a>, <a href="lwg-defects.html#586">586</a>, <a href="lwg-closed.html#587">587</a>, <a href="lwg-closed.html#588">588</a>, <a href="lwg-defects.html#589">589</a>, <a href="lwg-closed.html#590">590</a>, <a href="lwg-closed.html#591">591</a>, <a href="lwg-closed.html#592">592</a>.</li>
</ul></li>
</ul>
</li>
<li>R43: 
2006-06-23 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>124 open issues, up by 14.</li>
<li>463 closed issues, down by 1.</li>
<li>587 issues total, up by 13.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-defects.html#575">575</a>, <a href="lwg-defects.html#576">576</a>, <a href="lwg-defects.html#577">577</a>, <a href="lwg-defects.html#578">578</a>, <a href="lwg-closed.html#579">579</a>, <a href="lwg-closed.html#580">580</a>, <a href="lwg-defects.html#581">581</a>, <a href="lwg-closed.html#582">582</a>.</li>
<li>Reopened <a href="lwg-closed.html#255">255</a>.</li>
<li>Moved issues <a href="lwg-defects.html#520">520</a>, <a href="lwg-defects.html#541">541</a>, <a href="lwg-closed.html#544">544</a>, <a href="lwg-closed.html#569">569</a> to Tentatively Ready.</li>
</ul></li>
</ul>
</li>
<li>R42: 
2006-04-21 post-Berlin mailing.
<ul>
<li><b>Summary:</b><ul>
<li>110 open issues, down by 16.</li>
<li>464 closed issues, up by 24.</li>
<li>574 issues total, up by 8.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-defects.html#567">567</a>, <a href="lwg-closed.html#568">568</a>, <a href="lwg-closed.html#569">569</a>, <a href="lwg-closed.html#570">570</a>, <a href="lwg-closed.html#571">571</a>, <a href="lwg-closed.html#572">572</a>.</li>
<li>Moved issues <a href="lwg-closed.html#499">499</a>, <a href="lwg-closed.html#501">501</a>, <a href="lwg-closed.html#506">506</a>, <a href="lwg-closed.html#509">509</a>, <a href="lwg-closed.html#510">510</a>, <a href="lwg-closed.html#511">511</a>, <a href="lwg-closed.html#513">513</a>, <a href="lwg-closed.html#514">514</a>, <a href="lwg-closed.html#517">517</a> to NAD.</li>
<li>Moved issues <a href="lwg-closed.html#502">502</a>, <a href="lwg-closed.html#503">503</a>, <a href="lwg-closed.html#515">515</a>, <a href="lwg-closed.html#516">516</a>, <a href="lwg-defects.html#522">522</a>, <a href="lwg-defects.html#525">525</a>, <a href="lwg-closed.html#526">526</a>, <a href="lwg-defects.html#527">527</a>, <a href="lwg-closed.html#528">528</a>, <a href="lwg-closed.html#529">529</a>, <a href="lwg-closed.html#532">532</a>, <a href="lwg-closed.html#536">536</a>, <a href="lwg-defects.html#539">539</a>, <a href="lwg-closed.html#548">548</a> to Open.</li>
<li>Moved issue <a href="lwg-closed.html#504">504</a>, <a href="lwg-closed.html#512">512</a>, <a href="lwg-defects.html#521">521</a>, <a href="lwg-defects.html#530">530</a>, <a href="lwg-defects.html#531">531</a>, <a href="lwg-defects.html#535">535</a>, <a href="lwg-defects.html#537">537</a>, <a href="lwg-defects.html#538">538</a>, <a href="lwg-defects.html#540">540</a>, <a href="lwg-closed.html#549">549</a> to Ready.</li>
<li>Moved issues <a href="lwg-defects.html#247">247</a>, <a href="lwg-defects.html#294">294</a>, <a href="lwg-defects.html#362">362</a>, <a href="lwg-defects.html#369">369</a>, <a href="lwg-defects.html#371">371</a>, <a href="lwg-defects.html#376">376</a>, <a href="lwg-defects.html#384">384</a>, <a href="lwg-defects.html#475">475</a>, <a href="lwg-defects.html#478">478</a>, <a href="lwg-defects.html#495">495</a>, <a href="lwg-defects.html#497">497</a>, <a href="lwg-defects.html#505">505</a>, <a href="lwg-defects.html#507">507</a>, <a href="lwg-defects.html#508">508</a>, <a href="lwg-defects.html#519">519</a> to WP.</li>
<li>Moved issue <a href="lwg-defects.html#534">534</a> to Review.</li>
</ul></li>
</ul>
</li>
<li>R41: 
2006-02-24 pre-Berlin mailing.
<ul>
<li><b>Summary:</b><ul>
<li>126 open issues, up by 31.</li>
<li>440 closed issues, up by 0.</li>
<li>566 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-closed.html#536">536</a>, <a href="lwg-defects.html#537">537</a>, <a href="lwg-defects.html#538">538</a>, <a href="lwg-defects.html#539">539</a>, <a href="lwg-defects.html#540">540</a>, <a href="lwg-defects.html#541">541</a>, <a href="lwg-defects.html#542">542</a>, <a href="lwg-defects.html#543">543</a>, <a href="lwg-closed.html#544">544</a>, <a href="lwg-defects.html#545">545</a>, <a href="lwg-closed.html#546">546</a>, <a href="lwg-closed.html#547">547</a>, <a href="lwg-closed.html#548">548</a>, <a href="lwg-closed.html#549">549</a>, <a href="lwg-defects.html#550">550</a> ,<a href="lwg-defects.html#551">551</a>, <a href="lwg-defects.html#552">552</a>, <a href="lwg-closed.html#553">553</a>, <a href="lwg-closed.html#554">554</a>, <a href="lwg-closed.html#555">555</a>, <a href="lwg-defects.html#556">556</a>, <a href="lwg-closed.html#557">557</a>, <a href="lwg-closed.html#558">558</a>, <a href="lwg-defects.html#559">559</a>, <a href="lwg-closed.html#560">560</a>, <a href="lwg-defects.html#561">561</a>, <a href="lwg-defects.html#562">562</a>, <a href="lwg-defects.html#563">563</a>, <a href="lwg-defects.html#564">564</a>, <a href="lwg-defects.html#565">565</a>, <a href="lwg-defects.html#566">566</a>.</li>
<li>Moved <a href="lwg-closed.html#342">342</a> from Ready to Open.</li>
<li>Reopened <a href="lwg-closed.html#309">309</a>.</li>
</ul></li>
</ul>
</li>
<li>R40: 
2005-12-16 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>95 open issues.</li>
<li>440 closed issues.</li>
<li>535 issues total.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-closed.html#529">529</a>, <a href="lwg-defects.html#530">530</a>, <a href="lwg-defects.html#531">531</a>, <a href="lwg-closed.html#532">532</a>, <a href="lwg-defects.html#533">533</a>, <a href="lwg-defects.html#534">534</a>, <a href="lwg-defects.html#535">535</a>.</li>
</ul></li>
</ul>
</li>
<li>R39: 
2005-10-14 post-Mont Tremblant mailing.
Added new issues <a href="lwg-closed.html#526">526</a>-<a href="lwg-closed.html#528">528</a>.
Moved issues <a href="lwg-defects.html#280">280</a>, <a href="lwg-defects.html#461">461</a>, <a href="lwg-defects.html#464">464</a>, <a href="lwg-defects.html#465">465</a>, <a href="lwg-defects.html#467">467</a>, <a href="lwg-defects.html#468">468</a>, <a href="lwg-defects.html#474">474</a>, <a href="lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
Moved issues <a href="lwg-defects.html#247">247</a>, <a href="lwg-defects.html#294">294</a>, <a href="lwg-closed.html#342">342</a>, <a href="lwg-defects.html#362">362</a>, <a href="lwg-defects.html#369">369</a>, <a href="lwg-defects.html#371">371</a>, <a href="lwg-defects.html#376">376</a>, <a href="lwg-defects.html#384">384</a>, <a href="lwg-defects.html#475">475</a>, <a href="lwg-defects.html#478">478</a>, <a href="lwg-defects.html#495">495</a>, <a href="lwg-defects.html#497">497</a> from Review to Ready.
Moved issues <a href="lwg-defects.html#498">498</a>, <a href="lwg-closed.html#504">504</a>, <a href="lwg-closed.html#506">506</a>, <a href="lwg-closed.html#509">509</a>, <a href="lwg-closed.html#510">510</a>, <a href="lwg-closed.html#511">511</a>, <a href="lwg-closed.html#512">512</a>, <a href="lwg-closed.html#513">513</a>, <a href="lwg-closed.html#514">514</a> from New to Open.
Moved issues <a href="lwg-defects.html#505">505</a>, <a href="lwg-defects.html#507">507</a>, <a href="lwg-defects.html#508">508</a>, <a href="lwg-defects.html#519">519</a> from New to Ready.
Moved issue <a href="lwg-closed.html#500">500</a> from New to NAD.
Moved issue <a href="lwg-defects.html#518">518</a> from New to Review.
</li>
<li>R38: 
2005-07-03 pre-Mont Tremblant mailing.
Merged open TR1 issues in <a href="lwg-closed.html#504">504</a>-<a href="lwg-defects.html#522">522</a>.
Added new issues <a href="lwg-closed.html#523">523</a>-<a href="lwg-closed.html#523">523</a>
</li>
<li>R37: 
2005-06 mid-term mailing.
Added new issues <a href="lwg-defects.html#498">498</a>-<a href="lwg-closed.html#503">503</a>.
</li>
<li>R36: 
2005-04 post-Lillehammer mailing. All issues in "ready" status except
for <a href="lwg-closed.html#454">454</a> were moved to "DR" status, and all issues
previously in "DR" status were moved to "WP".
</li>
<li>R35: 
2005-03 pre-Lillehammer mailing.
</li>
<li>R34: 
2005-01 mid-term mailing.  Added new issues <a href="lwg-defects.html#488">488</a>-<a href="lwg-closed.html#494">494</a>.
</li>
<li>R33: 
2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
</li>
<li>R32: 
2004-09 pre-Redmond mailing: reflects new proposed resolutions and
new issues received after the 2004-07 mailing.  Added
new issues <a href="lwg-closed.html#479">479</a>-<a href="lwg-closed.html#481">481</a>.
</li>
<li>R31: 
2004-07 mid-term mailing: reflects new proposed resolutions and
new issues received after the post-Sydney mailing.  Added
new issues <a href="lwg-closed.html#463">463</a>-<a href="lwg-defects.html#478">478</a>.
</li>
<li>R30: 
Post-Sydney mailing: reflects decisions made at the Sydney meeting.
Voted all "Ready" issues from R29 into the working paper.
Added new issues <a href="lwg-defects.html#460">460</a>-<a href="lwg-closed.html#462">462</a>.
</li>
<li>R29: 
Pre-Sydney mailing.  Added new issues <a href="lwg-defects.html#441">441</a>-<a href="lwg-defects.html#457">457</a>.
</li>
<li>R28: 
Post-Kona mailing: reflects decisions made at the Kona meeting.
Added new issues <a href="lwg-defects.html#432">432</a>-<a href="lwg-closed.html#440">440</a>.
</li>
<li>R27: 
Pre-Kona mailing.  Added new issues <a href="lwg-defects.html#404">404</a>-<a href="lwg-defects.html#431">431</a>.
</li>
<li>R26: 
Post-Oxford mailing: reflects decisions made at the Oxford meeting.
All issues in Ready status were voted into DR status.  All issues in
DR status were voted into WP status.
</li>
<li>R25: 
Pre-Oxford mailing.  Added new issues <a href="lwg-closed.html#390">390</a>-<a href="lwg-defects.html#402">402</a>.
</li>
<li>R24: 
Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
meeting.  All Ready issues from R23 with the exception of <a href="lwg-defects.html#253">253</a>, 
which has been given a new proposed resolution, were
moved to DR status.  Added new issues <a href="lwg-defects.html#383">383</a>-<a href="lwg-defects.html#389">389</a>.  
(Issues <a href="lwg-defects.html#387">387</a>-<a href="lwg-defects.html#389">389</a> were discussed
at the meeting.)  Made progress on issues <a href="lwg-defects.html#225">225</a>, <a href="lwg-defects.html#226">226</a>, 
<a href="lwg-defects.html#229">229</a>: <a href="lwg-defects.html#225">225</a> and <a href="lwg-defects.html#229">229</a> have been moved to 
Ready status, and the only remaining concerns with <a href="lwg-defects.html#226">226</a> involve wording.
</li>
<li>R23: 
Pre-Santa Cruz mailing.  Added new issues <a href="lwg-closed.html#367">367</a>-<a href="lwg-closed.html#382">382</a>.
Moved issues in the TC to TC status.
</li>
<li>R22: 
Post-Cura&ccedil;ao mailing.  Added new issues <a href="lwg-defects.html#362">362</a>-<a href="lwg-closed.html#366">366</a>.
</li>
<li>R21: 
Pre-Cura&ccedil;ao mailing.  Added new issues <a href="lwg-closed.html#351">351</a>-<a href="lwg-closed.html#361">361</a>.
</li>
<li>R20: 
Post-Redmond mailing; reflects actions taken in Redmond.  Added
new issues <a href="lwg-defects.html#336">336</a>-<a href="lwg-closed.html#350">350</a>, of which issues 
<a href="lwg-defects.html#347">347</a>-<a href="lwg-closed.html#350">350</a> were added since Redmond, hence
not discussed at the meeting.  

All Ready issues were moved to DR status, with the exception of issues
<a href="lwg-defects.html#284">284</a>, <a href="lwg-defects.html#241">241</a>, and <a href="lwg-closed.html#267">267</a>.

Noteworthy issues discussed at Redmond include 
<a href="lwg-defects.html#120">120</a> <a href="lwg-defects.html#202">202</a>, <a href="lwg-defects.html#226">226</a>, <a href="lwg-defects.html#233">233</a>, 
<a href="lwg-defects.html#270">270</a>, <a href="lwg-defects.html#253">253</a>, <a href="lwg-defects.html#254">254</a>, <a href="lwg-closed.html#323">323</a>.
</li>
<li>R19: 
Pre-Redmond mailing.  Added new issues 
<a href="lwg-closed.html#323">323</a>-<a href="lwg-defects.html#335">335</a>.
</li>
<li>R18: 
Post-Copenhagen mailing; reflects actions taken in Copenhagen.
Added new issues <a href="lwg-defects.html#312">312</a>-<a href="lwg-defects.html#317">317</a>, and discussed
new issues <a href="lwg-defects.html#271">271</a>-<a href="lwg-closed.html#314">314</a>.

Changed status of issues
<a href="lwg-defects.html#103">103</a> <a href="lwg-defects.html#118">118</a> <a href="lwg-defects.html#136">136</a> <a href="lwg-defects.html#153">153</a>
<a href="lwg-defects.html#165">165</a> <a href="lwg-defects.html#171">171</a> <a href="lwg-defects.html#183">183</a> <a href="lwg-defects.html#184">184</a>
<a href="lwg-defects.html#185">185</a> <a href="lwg-defects.html#186">186</a> <a href="lwg-defects.html#214">214</a> <a href="lwg-defects.html#221">221</a>
<a href="lwg-defects.html#234">234</a> <a href="lwg-defects.html#237">237</a> <a href="lwg-defects.html#243">243</a> <a href="lwg-defects.html#248">248</a>
<a href="lwg-defects.html#251">251</a> <a href="lwg-defects.html#252">252</a> <a href="lwg-defects.html#256">256</a> <a href="lwg-defects.html#260">260</a>
<a href="lwg-defects.html#261">261</a> <a href="lwg-defects.html#262">262</a> <a href="lwg-defects.html#263">263</a> <a href="lwg-defects.html#265">265</a>
<a href="lwg-defects.html#268">268</a>
to DR.

Changed status of issues
<a href="lwg-defects.html#49">49</a>  <a href="lwg-defects.html#109">109</a> <a href="lwg-defects.html#117">117</a> <a href="lwg-defects.html#182">182</a>
<a href="lwg-defects.html#228">228</a> <a href="lwg-defects.html#230">230</a> <a href="lwg-defects.html#232">232</a> <a href="lwg-defects.html#235">235</a>
<a href="lwg-defects.html#238">238</a> <a href="lwg-defects.html#241">241</a> <a href="lwg-defects.html#242">242</a> <a href="lwg-defects.html#250">250</a>
<a href="lwg-defects.html#259">259</a> <a href="lwg-defects.html#264">264</a> <a href="lwg-defects.html#266">266</a> <a href="lwg-closed.html#267">267</a>
<a href="lwg-defects.html#271">271</a> <a href="lwg-defects.html#272">272</a> <a href="lwg-defects.html#273">273</a> <a href="lwg-defects.html#275">275</a>
<a href="lwg-defects.html#281">281</a> <a href="lwg-defects.html#284">284</a> <a href="lwg-defects.html#285">285</a> <a href="lwg-defects.html#286">286</a>
<a href="lwg-defects.html#288">288</a> <a href="lwg-defects.html#292">292</a> <a href="lwg-defects.html#295">295</a> <a href="lwg-defects.html#297">297</a>
<a href="lwg-defects.html#298">298</a> <a href="lwg-defects.html#301">301</a> <a href="lwg-defects.html#303">303</a> <a href="lwg-defects.html#306">306</a>
<a href="lwg-defects.html#307">307</a> <a href="lwg-defects.html#308">308</a> <a href="lwg-defects.html#312">312</a>
to Ready.

Closed issues 
<a href="lwg-closed.html#111">111</a> <a href="lwg-closed.html#277">277</a> <a href="lwg-closed.html#279">279</a> <a href="lwg-closed.html#287">287</a>
<a href="lwg-closed.html#289">289</a> <a href="lwg-closed.html#293">293</a> <a href="lwg-closed.html#302">302</a> <a href="lwg-closed.html#313">313</a>
<a href="lwg-closed.html#314">314</a>
as NAD.

</li>
<li>R17: 
Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
resolutions for issues <a href="lwg-defects.html#49">49</a>, <a href="lwg-defects.html#76">76</a>, <a href="lwg-defects.html#91">91</a>, 
<a href="lwg-defects.html#235">235</a>, <a href="lwg-defects.html#250">250</a>, <a href="lwg-closed.html#267">267</a>.
Added new issues <a href="lwg-defects.html#278">278</a>-<a href="lwg-defects.html#311">311</a>.
</li>
<li>R16:  
post-Toronto mailing; reflects actions taken in Toronto. Added new
issues <a href="lwg-defects.html#265">265</a>-<a href="lwg-closed.html#277">277</a>.  Changed status of issues
<a href="lwg-defects.html#3">3</a>, <a href="lwg-defects.html#8">8</a>, <a href="lwg-defects.html#9">9</a>, <a href="lwg-defects.html#19">19</a>,
<a href="lwg-defects.html#26">26</a>, <a href="lwg-defects.html#31">31</a>, <a href="lwg-defects.html#61">61</a>,
<a href="lwg-defects.html#63">63</a>, <a href="lwg-defects.html#86">86</a>, <a href="lwg-defects.html#108">108</a>,
<a href="lwg-defects.html#112">112</a>, <a href="lwg-defects.html#114">114</a>, <a href="lwg-defects.html#115">115</a>,
<a href="lwg-defects.html#122">122</a>, <a href="lwg-defects.html#127">127</a>, <a href="lwg-defects.html#129">129</a>,
<a href="lwg-defects.html#134">134</a>, <a href="lwg-defects.html#137">137</a>, <a href="lwg-defects.html#142">142</a>,
<a href="lwg-defects.html#144">144</a>, <a href="lwg-defects.html#146">146</a>, <a href="lwg-defects.html#147">147</a>,
<a href="lwg-defects.html#159">159</a>, <a href="lwg-defects.html#164">164</a>, <a href="lwg-defects.html#170">170</a>,
<a href="lwg-defects.html#181">181</a>, <a href="lwg-defects.html#199">199</a>, <a href="lwg-defects.html#208">208</a>,
<a href="lwg-defects.html#209">209</a>, <a href="lwg-defects.html#210">210</a>, <a href="lwg-defects.html#211">211</a>,
<a href="lwg-defects.html#212">212</a>, <a href="lwg-defects.html#217">217</a>, <a href="lwg-defects.html#220">220</a>,
<a href="lwg-defects.html#222">222</a>, <a href="lwg-defects.html#223">223</a>, <a href="lwg-defects.html#224">224</a>,
<a href="lwg-defects.html#227">227</a> to "DR".  Reopened issue <a href="lwg-defects.html#23">23</a>. Reopened
issue <a href="lwg-defects.html#187">187</a>. Changed issues <a href="lwg-closed.html#2">2</a> and
<a href="lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="lwg-defects.html#17">17</a>. Fixed
issue <a href="lwg-defects.html#70">70</a>: signature should be changed both places it
appears. Fixed issue <a href="lwg-defects.html#160">160</a>: previous version didn't fix
the bug in enough places.
</li>
<li>R15: 
pre-Toronto mailing. Added issues
<a href="lwg-defects.html#233">233</a>-<a href="lwg-defects.html#264">264</a>. Some small HTML formatting
changes so that we pass Weblint tests.
</li>
<li>R14: 
post-Tokyo II mailing; reflects committee actions taken in
Tokyo. Added issues <a href="lwg-defects.html#228">228</a> to <a href="lwg-defects.html#232">232</a>. (00-0019R1/N1242)
</li>
<li>R13: 
pre-Tokyo II updated: Added issues <a href="lwg-defects.html#212">212</a> to <a href="lwg-defects.html#227">227</a>.
</li>
<li>R12: 
pre-Tokyo II mailing: Added issues <a href="lwg-defects.html#199">199</a> to
<a href="lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
of issue <a href="lwg-defects.html#29">29</a>.  Add further rationale to issue
<a href="lwg-closed.html#178">178</a>.
</li>
<li>R11: 
post-Kona mailing: Updated to reflect LWG and full committee actions
in Kona (99-0048/N1224). Note changed resolution of issues
<a href="lwg-closed.html#4">4</a> and <a href="lwg-defects.html#38">38</a>. Added issues <a href="lwg-closed.html#196">196</a>
to <a href="lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
"closed" documents.  Changed the proposed resolution of issue
<a href="lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
of issue <a href="lwg-defects.html#38">38</a>.
</li>
<li>R10: 
pre-Kona updated.  Added proposed resolutions <a href="lwg-defects.html#83">83</a>,
<a href="lwg-defects.html#86">86</a>, <a href="lwg-defects.html#91">91</a>, <a href="lwg-defects.html#92">92</a>,
<a href="lwg-defects.html#109">109</a>. Added issues <a href="lwg-closed.html#190">190</a> to
<a href="lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
</li>
<li>R9: 
pre-Kona mailing.  Added issues <a href="lwg-closed.html#140">140</a> to
<a href="lwg-defects.html#189">189</a>. Issues list split into separate "active" and
"closed" documents. (99-0030/N1206, 25 Aug 99)
</li>
<li>R8: 
post-Dublin mailing. Updated to reflect LWG and full committee actions
in Dublin. (99-0016/N1193, 21 Apr 99)
</li>
<li>R7: 
pre-Dublin updated: Added issues <a href="lwg-defects.html#130">130</a>, <a href="lwg-closed.html#131">131</a>,
<a href="lwg-defects.html#132">132</a>, <a href="lwg-defects.html#133">133</a>, <a href="lwg-defects.html#134">134</a>,
<a href="lwg-closed.html#135">135</a>, <a href="lwg-defects.html#136">136</a>, <a href="lwg-defects.html#137">137</a>,
<a href="lwg-closed.html#138">138</a>, <a href="lwg-defects.html#139">139</a> (31 Mar 99)
</li>
<li>R6: 
pre-Dublin mailing. Added issues <a href="lwg-defects.html#127">127</a>, <a href="lwg-closed.html#128">128</a>,
and <a href="lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
</li>
<li>R5: 
update issues <a href="lwg-defects.html#103">103</a>, <a href="lwg-defects.html#112">112</a>; added issues
<a href="lwg-defects.html#114">114</a> to <a href="lwg-defects.html#126">126</a>. Format revisions to prepare
for making list public. (30 Dec 98)
</li>
<li>R4: 
post-Santa Cruz II updated: Issues <a href="lwg-defects.html#110">110</a>,
<a href="lwg-closed.html#111">111</a>, <a href="lwg-defects.html#112">112</a>, <a href="lwg-closed.html#113">113</a> added, several
issues corrected. (22 Oct 98)
</li>
<li>R3: 
post-Santa Cruz II: Issues <a href="lwg-closed.html#94">94</a> to <a href="lwg-defects.html#109">109</a>
added, many issues updated to reflect LWG consensus (12 Oct 98)
</li>
<li>R2: 
pre-Santa Cruz II: Issues <a href="lwg-closed.html#73">73</a> to <a href="lwg-closed.html#93">93</a> added,
issue <a href="lwg-defects.html#17">17</a> updated. (29 Sep 98)
</li>
<li>R1: 
Correction to issue <a href="lwg-defects.html#55">55</a> resolution, <a href="lwg-defects.html#60">60</a> code
format, <a href="lwg-defects.html#64">64</a> title. (17 Sep 98)
</li>
</ul>

<h2><a name="Status"></a>Issue Status</h2>

  <p>Issues reported to the LWG transition through a variety of statuses,
  indicating their progress towards a resolution.  Typically, most issues
  will flow through the following stages.
  </p>

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

  <p><b><a name="Open">Open</a></b> - The LWG 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 LWG awaits
            exact <b>Proposed Resolution</b> wording for review.</li>
        <li>The LWG wishes to consult additional technical experts before
            proceeding.</li>
        <li>The issue may require further study.</li>
     </ul>

  <p>A <b>Proposed Resolution</b> for an open issue is still not be
  construed as the view of LWG. 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="Review">Review</a></b> - Exact wording of a
  <b>Proposed Resolution</b> is now available for review on an issue
  for which the LWG previously reached informal consensus.</p>

  <p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus
  that the issue is a defect in the Standard, the <b>Proposed
  Resolution</b> is correct, and the issue is ready to forward to the
  full committee for further action as a Defect Report (DR).</p>

  <p>Typically, an issue must have a proposed resolution in the currently
  published issues list, whose wording does not change during LWG review, to
  move to the Ready status.</p>

  <p><b><a name="Voting">Voting</a></b> - This status should not be seen
  in a published issues list, but is a marker for use during meetings to
  indicate an issues was Ready in the pre-meeting mailing, the <b>Proposed
  Resolution</b> is correct, and the issue will be offered to the working
  group at the end of the current meeting to apply to the current working
  paper (WP) or to close in some other appropriate manner.  This easily
  distinguishes such issues from those moving to Ready status during the
  meeting itself, that should not be forwarded until the next meeting.  If
  the issue does not move forward, it should fall back to one of the other
  open states before the next list is published.</p>

  <p><b><a name="Immediate">Immediate</a></b> - This status should not be
  seen in a published issues list, but is a marker for use during meetings
  to indicate an issues was not Ready in the pre-meeting mailing, but the
  <b>Proposed Resolution</b> is correct, and the issue will be offered to
  the working group at the end of the current meeting to apply to the
  current working paper (WP) or to close in some other appropriate manner.
  This status is used only rarely, typically for fixes that are both small
  and obvious, and usually within a meeting of the expected publication of
  a revised standard.  If the issue does not move forward, it should fall
  back to one of the other open states before the next list is published.</p>

  <p>In addition, there are a few ways to categorise and issue that remains
  open to a resolution within the library, but is not actively being worked
  on.
  </p>

  <p><b><a name="Deferred">Deferred</a></b> - The LWG 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>Proposed Resolution</b> for a deferred issue is still not be
  construed as the view of LWG. 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="Core">Core</a></b> - The LWG has discussed the issue, and feels
  that some key part of resolving the issue is better handled by a cleanup of
  the language in the Core part of the standard.  The issue is passed to the Core
  Working Group, which should ideally open a corresponding issue that can be
  linked from the library issue.  Such issues will be revisitted after Core have
  made (or declined to make) any changes.
  </p>

  <p><b><a name="EWG">EWG</a></b> - The LWG has discussed the issue, and wonder
  that some key part of resolving the issue is better handled by some (hopefully
  small) extension to the language.  The issue is passed to the Evolution Working
  Group, which should ideally open a corresponding issue that can be linked from
  the library issue.  Such issues will be revisitted after Evoltion have made (or
  declined to make) any recommendations.  Positive recommendations from EWG will
  often mean the issue transition to <i>Core</i> status while we wait for some
  proposed new feature to land in the working paper.
  </p>

  <p>Ultimately, all issues should reach closure with one of the following statuses.
  </p>

  <p><b><a name="DR">DR</a></b> - (Defect Report) - The full WG21/PL22.16
  committee has voted to forward the issue to the Project Editor to be
  processed as a Potential Defect Report. The Project Editor reviews
  the issue, and then forwards it to the WG21 Convenor, who returns it
  to the full committee for final disposition. This issues list
  accords the status of DR to all these Defect Reports regardless of
  where they are in that process.</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 Defect Report's Proposed Resolution to the working paper.</p>

  <p><b><a name="C++11">C++11</a></b> - (C++ Standard, as revised for 2011) - The full
  WG21/PL22.16 committee has voted to accept the Defect Report's Proposed Resolution into
  the published 2011 revision to the C++ standard, ISO/IEC IS 14882:2011(E).</p>

   <p><b><a name="CD1">CD1</a></b> - (Committee Draft 2008) - The full
  WG21/PL22.16 committee has voted to accept the Defect Report's Proposed
  Resolution into the Fall 2008 Committee Draft.</p>

  <p><b><a name="TC1">TC1</a></b> - (Technical Corrigenda 1) - The full
  WG21/PL22.16 committee has voted to accept the Defect Report's Proposed
  Resolution as a Technical Corrigenda.  Action on this issue is thus
  complete and no further action is possible under ISO rules.</p>

  <p><b><a name="TRDec">TRDec</a></b> - (Decimal TR defect) - The LWG has voted to
  accept the Defect Report's Proposed Resolution into the Decimal TR.  Action on this
  issue is thus complete and no further action is expected.</p>

  <p><b><a name="Resolved">Resolved</a></b> - The LWG has reached consensus
  that the issue is a defect in 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="Dup">Dup</a></b> - The LWG 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 LWG has reached consensus that
  the issue is not a defect in the Standard.</p>

  <p><b><a name="NAD Editorial">NAD Editorial</a></b> - The LWG has reached consensus that
  the issue can either be handled editorially, or is handled by a paper (usually
  linked to in the rationale).</p>

  <p><b><a name="NAD Future">NAD Future</a></b> - In addition to the regular
  status, the LWG believes that this issue should be revisited at the next
  revision of the standard.</p>

  <p><b><a name="NAD Concepts">NAD Concepts</a></b> - This status reflects an evolution
  of the language during the development of C++11, where a new feature entered the
  language, called <i>concepts</i>, that fundamentally changed the way templates would
  be specified and written.  While this language feature was removed towards the end of
  the C++11 project, there is a clear intent to revisit this part of the language design.
  During that development, a number of issues were opened against the updated library
  related to use of that feature, or requesting fixes that would require exliciit use of
  the concepts feature.  All such issues have been closed with this status, and may be
  revisitted should this or a similar language feature return for a future standard.</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="lwg-active.html#New">New</a> when
  they first appear on the issues list. They may progress to
  <a href="lwg-active.html#Open">Open</a> or <a href="lwg-active.html#Review">Review</a>
  while the LWG is actively working on them. When the LWG has reached consensus on
  the disposition of an issue, the status will then change to
  <a href="lwg-active.html#Dup">Dup</a>, <a href="lwg-active.html#NAD">NAD</a>, or
  <a href="lwg-active.html#Ready">Ready</a> as appropriate.  Once the full PL22.16 committee
  votes to forward Ready issues to the Project Editor, they are given the status of Defect
  Report ( <a href="lwg-active.html#DR">DR</a>). These in turn may become the basis for
  Technical Corrigenda (<a href="lwg-active.html#TC1">TC1</a>), or are closed without action
  other than a Record of Response (<a href="lwg-active.html#Resolved">Resolved</a> ).  The
  intent of this LWG process is that only issues which are truly defects in the Standard move
  to the formal ISO DR status.
  </p>


<h2>Active Issues</h2>
<hr>
<h3><a name="1169"></a>1169. <tt>num_get</tt> not fully compatible with <tt>strto*</tt></h3>
<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Cosmin Truta <b>Opened:</b> 2009-07-04 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all other</b> <a href="lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As specified in the latest draft,
<a 
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>,
<code>num_get</code> is still not fully compatible with the following C
functions: <code>strtoul</code>, <code>strtoull</code>, 
<code>strtof</code> and
<code>strtod</code>.
</p>
<p>
In C, when conversion of a string to an unsigned integer type falls 
outside the
representable range, <code>strtoul</code> and <code>strtoull</code> return
<code>ULONG_MAX</code> and <code>ULLONG_MAX</code>, respectively, 
regardless
whether the input field represents a positive or a negative value.
On the other hand, the result of <code>num_get</code> conversion of 
negative
values to unsigned integer types is zero. This raises a compatibility 
issue.
</p>
<p>
Moreover, in C, when conversion of a string to a floating-point type falls
outside the representable range, <code>strtof</code>, <code>strtod</code> 
and
<code>strtold</code> return <code>&#xB1;HUGE_VALF</code>,
<code>&#xB1;HUGE_VAL</code> and <code>&#xB1;HUGE_VALL</code>, respectively.
On the other hand, the result of <code>num_get</code> conversion of such
out-of-range floating-point values results in the most positive/negative
representable value.
Although many C library implementations do implement <code>HUGE_VAL</code>
(etc.) as the highest representable (which is, usually, the infinity), 
this isn't required by the C standard. The C library specification makes no
statement regarding the value of <code>HUGE_VAL</code> and friends, which
potentially raises the same compatibility issue as in the above case of
unsigned integers.
In addition, neither C nor C++ define symbolic constants for the maximum
representable floating-point values (they only do so only for the maximum
representable <i>finite</i> floating-point values), which raises a 
usability
issue (it would be hard for the programmer to check the result of
<code>num_get</code> against overflow).
</p>
<p>
As such, we propose to adjust the specification of <code>num_get</code> to
closely follow the behavior of all of its underlying C functions.
</p>



<p><i>[
2010 Rapperswil:
]</i></p>


<blockquote><p>
Some concern that this is changing the specification for an existing C++03 function, but it was 
pointed out that this was underspecified as resolved by issue 23.  This is clean-up for that 
issue in turn. Some concern that we are trying to solve the same problem in both clause 22 and 27.
</p>
<p>
Bill: There's a change here as to whether val is stored to in an error case.
</p>
<p>
Pablo: Don't think this changes whether val is stored to or not, but changes the value that is stored.
</p>
<p>
Bill: Remembers having skirmishes with customers and testers as to whether val is stored to, and the resolution was not to store in error cases.
</p>
<p>
Howard: Believes since C++03 we made a change to always store in overflow.
</p>
<p>
Everyone took some time to review the issue.
</p>
<p>
Pablo: C++98 definitely did not store any value during an error condition.
</p>
<p>
Dietmar: Depends on the question of what is considered an error, and whether overflow is an error or not, which was the crux of LWG 23.
</p>
<p>
Pablo: Yes, but given the "zero, if the conversion function fails to convert the entire field", we are requiring every error condition to store.
</p>
<p>
Bill: When did this happen?
</p>
<p>
Alisdair: One of the last two or three meetings.
</p>
<p>
Dietmar: To store a value in case of failure is a very bad idea.
</p>
<p>
Move to Open, needs more study.
</p>
</blockquote>

<p><i>[2011-03-24 Madrid meeting]</i></p>


<p>Move to deferred</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
The proposed wording looks good, no-one sure why this was held back before.  Move to Review.
</p>


<p><i>[2012,Kona]</i></p>

<p>
Move to Open.
</p>
<p>
THe issues is what to do with <tt>-1</tt>.  Should it match 'C' or do the "sane" thing.
A fix here changes behavior, but is probably what we want.
</p>
<p>
Pablo to provide wording, with help from Howard.
</p>



<p><b>Proposed resolution:</b></p>

<p>
Change 22.4.2.1.2 [facet.num.get.virtuals] as follows:
</p>
<blockquote>
<p>
<b>Stage 3:</b>
The sequence of <code>char</code>s accumulated in stage 2 (the field) is
converted to a numeric value by the rules of one of the functions declared in
the header <code>&lt;cstdlib&gt;</code>:
</p>
<ul>
<li>For a signed integer value, the function <code>strtoll</code>.</li>
<li>For an unsigned integer value, the function <code>strtoull</code>.</li>
<li><ins>For a <code>float</code> value, the function
    <code>strtof</code>.</ins></li>
<li><ins>For a <code>double</code> value, the function
    <code>strtod</code>.</ins></li>
<li>For a <del>floating-point</del> <ins><code>long double</code></ins>
    value, the function <code>strtold</code>.</li>
</ul>
<p>
The numeric value to be stored can be one of:
</p>
<ul>
<li>zero, if the conversion function fails to convert the entire field.
    <del><code>ios_base::failbit</code> is assigned to <code>err</code>.</del></li>
<li>the most positive <ins>(or negative)</ins> representable value, if
    the field <ins>to be converted to a signed integer type</ins> represents a
    value too large positive <ins>(or negative)</ins> to be represented in
    <code>val</code>.
    <del><code>ios_base::failbit</code> is assigned to <code>err</code>.</del></li>
<li><del>the most negative representable value or zero for an unsigned integer
    type, if the field represents a value too large negative to be represented
    in <code>val</code>.
    <code>ios_base::failbit</code> is assigned to <code>err</code>.</del></li>
<li><ins>the most positive representable value, if the field to be converted to
    an unsigned integer type represents a value that cannot be represented in
    <code>val</code>.</ins></li>
<li>the converted value, otherwise.</li>
</ul>
<p>
The resultant numeric value is stored in <code>val</code>.
<ins>If the conversion function fails to convert the entire field, or if the
field represents a value outside the range of representable values,
<code>ios_base::failbit</code> is assigned to <code>err</code>.</ins>
</p>
</blockquote>






<hr>
<h3><a name="1175"></a>1175. <tt>unordered</tt> complexity</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-07-17 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
When I look at the <tt>unordered_*</tt> constructors, I think the complexity is poorly
described and does not follow the style of the rest of the standard.
</p>

<p>
The complexity for the default constructor is specified as constant.
Actually, it is proportional to <tt>n</tt>, but there are no invocations of
<tt>value_type</tt> constructors or other <tt>value_type</tt> operations.
</p>

<p>
For the iterator-based constructor the complexity should be:
</p>

<blockquote><p>
<i>Complexity:</i> exactly <tt>n</tt> calls to construct <tt>value_type</tt>
from <tt>InputIterator::value_type</tt> (where <tt>n = distance(f,l)</tt>).
The number of calls to <tt>key_equal::operator()</tt> is proportional to
<tt>n</tt> in the average case and <tt>n*n</tt> in the worst case.
</p></blockquote>



<p><i>[
2010 Rapperswil:
]</i></p>


<blockquote><p>
Concern that the current wording may require O(1) where that cannot be delivered.  We need to look at 
both the clause 23 requirements tables and the constructor description of each unordered container to be sure.
</p>
<p>
Howard suggests NAD Editorial as we updated the container requirement tables since this issue was written.
</p>
<p>
Daniel offers to look deeper, and hopefully produce wording addressing any outstanding concerns at the next meeting.
</p>
<p>
Move to Open.
</p>
</blockquote>

<p><i>[2011-02-26: Daniel provides wording]</i></p>


<p>I strongly suggest to clean-up the differences between requirement tables and individual
specifications. In the usual way, the most specific specifications wins, which is in this
case the wrong one. In regard to the concern expressed about missing <tt>DefaultConstructible</tt>
requirements of the value type I disagree: The function argument <tt>n</tt> is no size-control
parameter, but only some effective capacity parameter: No elements will be value-initialized
by these constructors. The necessary requirement for the value type, <tt>EmplaceConstructible</tt>
into <tt>*this</tt>, is already listed in Table 103 &mdash; Unordered associative container requirements.
Another part of the proposed resolution is the fact that there is an inconsistency of the
complexity counting when both a range <strong>and</strong> a bucket count is involved compared
to constructions where only bucket counts are provided: E.g. the construction <tt>X a(n);</tt>
has a complexity of <tt>n</tt> bucket allocations, but this part of the work is omitted for
<tt>X a(i, j, n);</tt>, even though it is considerable larger (in the average case) for 
<tt>n &#8811; distance(i, j)</tt>.
</p>

<p><i>[2011-03-24 Madrid meeting]</i></p>


<p>Move to deferred</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
The proposed wording looks good.  Move to Review.
</p>


<p><i>[2012, Kona]</i></p>

<p>
Fix up some presentation issues with the wording, combining the big-O expressions into single
expressions rather than the sum of two separate big-Os.
</p>
<p>
Strike "constant or linear", prefer "linear in the number of buckets".
This allows for number of buckets being larger than requested <tt>n</tt> as well.
</p>
<p>
Default <tt>n</tt> to "unspecified" rather than "implementation-defined".  It seems an un-necessary
burden asking vendors to document a quantity that is easily determined through the public API of
these classes.
</p>
<p>
Replace <tt>distance(f,l)</tt> with "number of elements in the range <tt>[f,l)</tt>"
</p>
<p>
Retain in Review with the updated wording
</p>


<p><i>[2012, Portland: Move to Open]</i></p>

<p>
The wording still does not call out Pablo's original concern, that the element constructor is called
no more than <tt>N</tt> times, and that the <tt>N</tt> squared term applies to moves during rehash.
</p>

<p>
Inconsistent use of O(n)+O(N) vs. O(n+N), with a preference for the former.
</p>

<p>
AJM to update wording with a reference to "no more than <tt>N</tt> element constructor calls".
</p>

<p>
Matt concerned that calling out the O(n) requirements is noise, and dangerous noise in suggesting a precision
we do not mean.  The cost of constructing a bucket is very different to constructing an element of user-supplied
type.
</p>

<p>
AJM notes that if there are multiple rehashes, the 'n' complexity is probably not linear.
</p>

<p>
Matt suggests back to Open, Pablo suggests potentially NAD if we keep revisitting without achieving a resolution.
</p>

<p>
Matt suggests complexity we are concerned with is the number of operations, such as constructing elements, moving
nodes, and comparing/hashing keys.  We are less concerned with constructing buckets, which are generally noise in
this bigger picture.
</p>



<p><b>Proposed resolution:</b></p>
<ol>
<li><p>Modify the following rows in Table 103 &mdash; Unordered associative container requirements to
add the explicit bucket allocation overhead of some constructions. As editorial recommendation it is 
suggested <em>not</em> to shorten the sum <tt>&#x1d4aa;(n) + &#x1d4aa;(<em>N</em>)</tt> to
<tt>&#x1d4aa;(n + <em>N</em>)</tt>, because two different work units are involved.</p>

<blockquote>
<table border="1">
<caption>Table 103 &mdash; Unordered associative container requirements (in addition to container)</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td colspan="4" style="text-align:center;">&hellip;</td>
</tr>

<tr>
<td><tt>X(i, j, n, hf, eq)</tt><br/>
<tt>X a(i, j, n, hf, eq)</tt>
</td>
<td><tt>X</tt></td>
<td>&hellip;<br/>
<i>Effects</i>: Constructs an empty container with at least <tt>n</tt><br/>
buckets, using <tt>hf</tt> as the hash function and <tt>eq</tt> as the key<br/>
equality predicate, and inserts elements from <tt>[i, j)</tt> into it.
</td>
<td>Average case &#x1d4aa;(<tt><i><ins>n + </ins>N</i></tt>) (<tt><i>N</i></tt> is <tt>distance(i, j)</tt>),<br/>
worst case <ins>&#x1d4aa;(<tt>n</tt>) +</ins> &#x1d4aa;(<tt><i>N</i><sup>2</sup></tt>)</td>
</tr>

<tr>
<td><tt>X(i, j, n, hf)</tt><br/>
<tt>X a(i, j, n, hf)</tt>
</td>
<td><tt>X</tt></td>
<td>&hellip;<br/>
<i>Effects</i>: Constructs an empty container with at least <tt>n</tt><br/>
buckets, using <tt>hf</tt> as the hash function and <tt>key_equal()</tt> as the key<br/>
equality predicate, and inserts elements from <tt>[i, j)</tt> into it.
</td>
<td>Average case &#x1d4aa;(<tt><i><ins>n + </ins>N</i></tt>) (<tt><i>N</i></tt> is <tt>distance(i, j)</tt>),<br/>
worst case &#x1d4aa;(<tt><i><ins>n + </ins>N</i><sup>2</sup></tt>)</td>
</tr>

<tr>
<td><tt>X(i, j, n)</tt><br/>
<tt>X a(i, j, n)</tt>
</td>
<td><tt>X</tt></td>
<td>&hellip;<br/>
<i>Effects</i>: Constructs an empty container with at least <tt>n</tt><br/>
buckets, using <tt>hasher()</tt> as the hash function and <tt>key_equal()</tt> as the key<br/>
equality predicate, and inserts elements from <tt>[i, j)</tt> into it.
</td>
<td>Average case &#x1d4aa;(<tt><i><ins>n + </ins>N</i></tt>) (<tt><i>N</i></tt> is <tt>distance(i, j)</tt>),<br/>
worst case &#x1d4aa;(<tt><i><ins>n + </ins>N</i><sup>2</sup></tt>)</td>
</tr>

<tr>
<td colspan="4" style="text-align:center;">&hellip;</td>
</tr>

</table>
</blockquote>

</li>

<li><p>Modify 23.5.4.2 [unord.map.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some
editorial oversight.):</p>

<blockquote><pre>
explicit unordered_map(size_type n = <i>see below</i>,
                       const hasher&amp; hf = hasher(),
                       const key_equal&amp; eql = key_equal(),
                       const allocator_type&amp; a = allocator_type());
</pre><blockquote><p>
1 <i>Effects</i>: Constructs an empty <tt>unordered_map</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is 
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_map</tt></del>. 
<tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p></blockquote>
<blockquote><p>
2 <i>Complexity</i>: <del>Constant</del><ins>Linear in the number of buckets</ins>.
</p></blockquote>
</blockquote>

<blockquote><pre>
template &lt;class InputIterator&gt;
unordered_map(InputIterator f, InputIterator l,
              size_type n = <i>see below</i>,
              const hasher&amp; hf = hasher(),
              const key_equal&amp; eql = key_equal(),
              const allocator_type&amp; a = allocator_type());
</pre><blockquote><p>
3 <i>Effects</i>: Constructs an empty <tt>unordered_map</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is 
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_map</tt></del>.
Then inserts elements from the range <tt>[f, l)</tt>. <tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p></blockquote>
<blockquote><p>
4 <i>Complexity</i>: <del>Average case linear, worst case quadratic</del><ins>Linear in the number of buckets.
In the average case linear in <tt><i>N</i></tt> and in the worst case quadratic in <tt><i>N</i></tt> to insert
the elements, where <tt><i>N</i></tt> is equal to number of elements in the range <tt>[f,l)</tt></ins>.
</p></blockquote>
</blockquote>
</li>

<li><p>Modify 23.5.5.2 [unord.multimap.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some
editorial oversight.):</p>

<blockquote><pre>
explicit unordered_multimap(size_type n = <i>see below</i>,
                            const hasher&amp; hf = hasher(),
                            const key_equal&amp; eql = key_equal(),
                            const allocator_type&amp; a = allocator_type());
</pre><blockquote><p>
1 <i>Effects</i>: Constructs an empty <tt>unordered_multimap</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is 
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_multimap</tt></del>. 
<tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p></blockquote>
<blockquote><p>
2 <i>Complexity</i>: <del>Constant</del><ins>Linear in the number of buckets</ins>.
</p></blockquote>
</blockquote>

<blockquote><pre>
template &lt;class InputIterator&gt;
unordered_multimap(InputIterator f, InputIterator l,
                   size_type n = <i>see below</i>,
                   const hasher&amp; hf = hasher(),
                   const key_equal&amp; eql = key_equal(),
                   const allocator_type&amp; a = allocator_type());
</pre><blockquote><p>
3 <i>Effects</i>: Constructs an empty <tt>unordered_multimap</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is 
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_multimap</tt></del>.
Then inserts elements from the range <tt>[f, l)</tt>. <tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p></blockquote>
<blockquote><p>
4 <i>Complexity</i>: <del>Average case linear, worst case quadratic</del><ins>Linear in the number of buckets.
In the average case linear in <tt><i>N</i></tt> and in the worst case quadratic in <tt><i>N</i></tt> to insert
the elements, where <tt><i>N</i></tt> is equal to number of elements in the range <tt>[f,l)</tt></ins>.
</p></blockquote>
</blockquote>
</li>

<li><p>Modify 23.5.6.2 [unord.set.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some
editorial oversight.):</p>

<blockquote><pre>
explicit unordered_set(size_type n = <i>see below</i>,
                       const hasher&amp; hf = hasher(),
                       const key_equal&amp; eql = key_equal(),
                       const allocator_type&amp; a = allocator_type());
</pre><blockquote><p>
1 <i>Effects</i>: Constructs an empty <tt>unordered_set</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is 
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_set</tt></del>. 
<tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p></blockquote>
<blockquote><p>
2 <i>Complexity</i>: <del>Constant</del><ins>Linear in the number of buckets</ins>.
</p></blockquote>
</blockquote>

<blockquote><pre>
template &lt;class InputIterator&gt;
unordered_set(InputIterator f, InputIterator l,
              size_type n = <i>see below</i>,
              const hasher&amp; hf = hasher(),
              const key_equal&amp; eql = key_equal(),
              const allocator_type&amp; a = allocator_type());
</pre><blockquote><p>
3 <i>Effects</i>: Constructs an empty <tt>unordered_set</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is 
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_set</tt></del>.
Then inserts elements from the range <tt>[f, l)</tt>. <tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p></blockquote>
<blockquote><p>
4 <i>Complexity</i>: <del>Average case linear, worst case quadratic</del><ins>Linear in the number of buckets.
In the average case linear in <tt><i>N</i></tt> and in the worst case quadratic in <tt><i>N</i></tt> to insert
the elements, where <tt><i>N</i></tt> is equal to number of elements in the range <tt>[f,l)</tt></ins>.
</p></blockquote>
</blockquote>
</li>

<li><p>Modify 23.5.7.2 [unord.multiset.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some
editorial oversight.):</p>

<blockquote><pre>
explicit unordered_multiset(size_type n = <i>see below</i>,
                            const hasher&amp; hf = hasher(),
                            const key_equal&amp; eql = key_equal(),
                            const allocator_type&amp; a = allocator_type());
</pre><blockquote><p>
1 <i>Effects</i>: Constructs an empty <tt>unordered_multiset</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is 
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_multiset</tt></del>. 
<tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p></blockquote>
<blockquote><p>
2 <i>Complexity</i>: <del>Constant</del><ins>Linear in the number of buckets</ins>.
</p></blockquote>
</blockquote>

<blockquote><pre>
template &lt;class InputIterator&gt;
unordered_multiset(InputIterator f, InputIterator l,
                   size_type n = <i>see below</i>,
                   const hasher&amp; hf = hasher(),
                   const key_equal&amp; eql = key_equal(),
                   const allocator_type&amp; a = allocator_type());
</pre><blockquote><p>
3 <i>Effects</i>: Constructs an empty <tt>unordered_multiset</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is 
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_multiset</tt></del>.
Then inserts elements from the range <tt>[f, l)</tt>. <tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p></blockquote>
<blockquote><p>
4 <i>Complexity</i>: <del>Average case linear, worst case quadratic</del><ins>Linear in the number of buckets.
In the average case linear in <tt><i>N</i></tt> and in the worst case quadratic in <tt><i>N</i></tt> to insert
the elements, where <tt><i>N</i></tt> is equal to number of elements in the range <tt>[f,l)</tt></ins>.
</p></blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="1213"></a>1213. Meaning of valid and singular iterator underspecified</h3>
<p><b>Section:</b> 24.2 [iterator.requirements] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2009-09-19 <b>Last modified:</b> 2014-02-20</p>
<p><b>View all other</b> <a href="lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The terms <em>valid</em> iterator and <em>singular</em> aren't
properly defined. The fuzziness of those terms became even worse
after the resolution of <a href="lwg-defects.html#208">208</a> (including further updates by <a href="lwg-defects.html#278">278</a>). In
24.2 [iterator.requirements] as of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
the standard says now:
</p>

<blockquote>
<p>
5 - These values are called past-the-end values. Values of an iterator <tt>i</tt> for
which the expression <tt>*i</tt> is defined are called dereferenceable. The library
never assumes that past-the-end values are dereferenceable. Iterators
can also have singular values that are not associated with any
container. [...] Results of most expressions are undefined for singular
values; the only exceptions are destroying an iterator that holds a
singular value and the assignment of a non-singular value to an iterator
that holds a singular value. [...] Dereferenceable values are always
non-singular.
</p>

<p>
10 - An invalid iterator is an iterator that may be singular.
</p>
</blockquote>

<p>
First, issue <a href="lwg-defects.html#208">208</a> intentionally removed the earlier constraint that past-the-end
values are always non-singular. The reason for this was to support null
pointers as past-the-end iterators of e.g. empty sequences. But there
seem to exist different views on what a singular (iterator) value is. E.g.
according to the <a href="http://www.sgi.com/tech/stl/trivial.html">SGI definition</a>
a null pointer is <em>not</em> a singular value:
</p>

<blockquote><p>
Dereferenceable iterators are always nonsingular, but the converse is
not true.
For example, a null pointer is nonsingular (there are well defined operations
involving null pointers) even thought it is not dereferenceable.
</p></blockquote>

<p>
and <a href="http://www.sgi.com/tech/stl/InputIterator.html">proceeds</a>:
</p>

<blockquote><p>
An iterator is valid if it is dereferenceable or past-the-end.
</p></blockquote>

<p>
Even if the standard prefers a different meaning of singular here, the
change was incomplete, because by restricting feasible expressions of singular
iterators to destruction and assignment isn't sufficient for a past-the-end
iterator: Of-course it must still be equality-comparable and in general be a readable value.
</p>

<p>
Second, the standard doesn't clearly say whether a past-the-end value is
a valid iterator or not. E.g. 20.7.12 [specialized.algorithms]/1 says:
</p>

<blockquote><p>
In all of the following algorithms, the formal template parameter <tt>ForwardIterator</tt> 
is required to satisfy the requirements of a forward iterator (24.1.3)
[..], and is required to have the property that no exceptions are thrown from [..], or
dereference of valid iterators.
</p></blockquote>

<p>
The standard should make better clear what "singular pointer" and "valid
iterator" means. The fact that the meaning of a valid <em>value</em>
has a core language meaning doesn't imply that for an iterator concept
the term "valid iterator" has the same meaning.
</p>

<p>
Let me add a final example: In X [allocator.concepts.members] of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>
we find:
</p>

<blockquote><pre>
pointer X::allocate(size_type n);
</pre>

<blockquote><p>
11 <i>Returns:</i> a pointer to the allocated memory. [<i>Note:</i> if <tt>n == 0</tt>, the return
value is unspecified. &mdash;<i>end note</i>]
</p></blockquote>

<p>
[..]
</p>

<pre>
void X::deallocate(pointer p, size_type n);
</pre>

<blockquote><p>
<i>Preconditions:</i> <tt>p</tt> shall be a non-singular pointer value obtained from a call
to <tt>allocate()</tt> on this allocator or one that compares equal to it.
</p></blockquote>
</blockquote>

<p>
If singular pointer value would include null pointers this make the
preconditions
unclear if the pointer value is a result of <tt>allocate(0)</tt>: Since the return value
is unspecified, it could be a null pointer. Does that mean that programmers
need to check the pointer value for a null value before calling deallocate?
</p>

<p><i>[
2010-11-09 Daniel comments:
]</i></p>


<p>
A later paper is in preparation.
</p>

<p><i>[
2010 Batavia:
]</i></p>


<p>
Doesn't need to be resolved for Ox
</p>


<p><i>[2014-02-20 Re-open Deferred issues as Priority 4]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Consider to await the paper.
</p>





<hr>
<h3><a name="1526"></a>1526. C++ should not impose thread safety requirements on C99 library implementations</h3>
<p><b>Section:</b> 17.6.5.9 [res.on.data.races] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2011-03-24 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-111</b></p>

<p>Section 17.6.5.9 [res.on.data.races], Data Race Avoidance, requires the C++ Standard Library to avoid data races 
that might otherwise result from two threads making calls to C++ Standard Library functions on 
distinct objects. The C standard library is part of the C++ Standard Library and some C++ Standary library 
functions (parts of the Localization library, as well as Numeric Conversions in 21.5), are specified 
to make use of the C standard library. Therefore, the C++ standard indirectly imposes a requirement 
on the thread safety of the C standard library. However, since the C standard does not address the 
concept of thread safety conforming C implementations exist that do no provide such guarantees. 
This conflict needs to be reconciled.</p>

<p>Suggested resolution by national body comment:</p>

<blockquote><p>
remove the requirement to make use of <tt>strtol()</tt> and <tt>sprintf()</tt> since these functions depend on the 
global C locale and thus cannot be made thread safe.
</p></blockquote>

<p><i>[2011-03-24 Madrid meeting]</i></p>


<p>Deferred</p>

<p><i>[
2011 Bloomington
]</i></p>

<p>
Alisdair: PJ, does this cause a problem in C?
</p>
<p>
PJ: Every implementation know of is thread safe.
</p>
<p>
Pete: There a couple of effects that are specified on strtol() and sprintf() which is a problem.
</p>
<p>
PJ: When C++ talks about C calls it should be "as if" calling the function.
</p>
<p>
Pete: Culprit is to string stuff. My fault.
</p>
<p>
PJ: Not your fault. You did what you were told. Distinct resolution to change wording.
</p>
<p>
Dietmar: What would we break if we change it back?
</p>
<p>
Pete: Nothing. If implemented on top of thread safe C library you are just fine.
</p>
<p>
Alisdair: Anyone want to clean up wording and put it back to what Pete gave us?
</p>
<p>
Alisdair: No volunteers. Do we want to mark as NAD? We could leave it as deferred.
</p>
<p>
Stefanus: Did original submitter care about this?
</p>
<p>
Lawrence: There is some work to make local calls thread safe. The resolution would be to call those thread safe version.
</p>
<p>
Pete: "As if called under single threaded C program"
</p>
<p>
<b>Action Item</b> (Alisdair): Write wording for this issue.
</p>

<p><i>[2012, Kona]</i></p>

<p>
Re-opened at the request of the concurrency subgroup, who feel there is an issue that needs
clarifying for the (planned) 2017 standard.
</p>

<p><b>Rationale:</b></p><p>No consensus to make a change at this time</p>

<p><i>[2012, Portland]</i></p>

<p>
The concurrency subgroup decided to encourage the LWG to consider a change to 17.2 [library.c] or thereabouts 
to clarify that we are requiring C++-like thread-safety for <tt>setlocale</tt>, so that races are not introduced 
by C locale accesses, even when the C library allows it. This would require e.g. adding "and data race avoidance" 
at the end of 17.2 [library.c] p1:
</p>
<p>
"The C++ standard library also makes available the facilities of the C standard library, suitably adjusted to 
ensure static type safety <ins>and data race avoidance</ins>.",
</p>
<p>
with some further clarifications in the sections mentioned in <a href="lwg-active.html#1526">1526</a>.
</p>
<p>
This seems to be consistent with existing implementations. This would technically not be constraining C implementation, 
but it would be further constraining C libraries used for both C and C++.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Change 17.2 [library.c] p1 as indicated:</p>

<blockquote><p>
-1- The C++ standard library also makes available the facilities of the C standard library, suitably adjusted to
ensure static type safety <ins>and data race avoidance</ins>.
</p></blockquote>
</li>
</ol>






<hr>
<h3><a name="2016"></a>2016. <tt>Allocators</tt> must be no-throw <i>swappable</i></h3>
<p><b>Section:</b> 17.6.3.5 [allocator.requirements] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2010-11-17 <b>Last modified:</b> 2014-02-15</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
During the Batavia meeting it turned out that there is a definition
hole for types satisfying the <tt>Allocators</tt> requirements: The problem
became obvious when it was discussed whether all <tt>swap</tt> functions 
of <tt>Containers</tt> with internal data handles can be safely tagged
with <tt>noexcept</tt> or not. While it is correct that the implicit
<tt>swap</tt> function of an allocator is required to be a no-throw
operation (because move/copy-constructors and assignment operators are
required to be no-throw functions), there are no such requirements
for specialized <tt>swap</tt> overloads for a particular allocator.
<p/>
But this requirement is essential because the <tt>Containers</tt> are
required to support <i>swappable</i> <tt>Allocators</tt>, when the value
<tt>allocator_traits&lt;&gt;::propagate_on_container_swap</tt> evaluates
to <tt>true</tt>.
</p>
<p><i>[2011-02-10 Alberto, Daniel, and Pablo collaborated on the proposed wording]</i></p>

<p>
The proposed resolution (based on N3225) attempts to solve the following problems:
</p>
<ol>
<li>Table 44 &mdash; Allocator requirements, expression rows 
<tt>X::propagate_on_container_copy_assignment</tt>, <tt>X::propagate_on_container_move_assignment</tt>, and
<tt>X::propagate_on_container_swap</tt> only describe operations, but no requirements. In fact, if and only
if these compile-time predicates evaluate to <tt>true</tt>, the <em>additional</em> requirements
<tt>CopyAssignable</tt>,  no-throw <tt>MoveAssignable</tt>, and no-throw lvalue <tt>Swappable</tt>, 
respectively, are imposed on the allocator types.</li>
<li>23.2.1 [container.requirements.general] p. 9 misses to refer to the correct swap conditions: The current wording does not relate to
17.6.3.2 [swappable.requirements] as it should and omits to mention that lvalues shall be swapped. Additional there is one
situation described twice in p. 8 and p. 9 (undefined behaviour unless <tt>a.get_allocator() == b.get_allocator()</tt>
or <tt>allocator_traits&lt;allocator_type&gt;::propagate_on_container_swap::value == true</tt>), which should be cleaned up.</li>
</ol>

<p><i>[2011-04-08 Pablo comments]</i></p>

<p>
I'm implementing a version of list now and I actually do find it impossible to write an exception-safe assignment 
operator unless I can assume that allocator assignment does not throw.  (The problem is that I use a sentinel node 
and I need to allocate a new sentinel using the new allocator without destroying the old one -- then swap the 
allocator and sentinel pointer in atomically, without risk of an exception leaving one inconsistent with the other.
<p/>
Please update the proposed resolution to add the nothrow requirement to copy-assignment.
</p>

<p><i>[2014-02-14 Issaquah: Move to Ready]</i></p>

<p>
Fix a couple of grammar issues related to calling <tt>swap</tt> and move to Ready.
</p>



<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Adapt the following three rows from Table 44 &mdash; Allocator requirements:
</p>

<blockquote>
<table border="1">
<caption>Table 44 &mdash; Allocator requirements</caption>
<tr>
<th>
Expression
</th>

<th>
Return type
</th>

<th>
Assertion/note<br/>pre-/post-condition
</th>

<th>
Default
</th>

</tr>

<tr>
<td><tt>X::propagate_on_container_copy_assignment</tt></td>

<td>Identical to or derived from <tt>true_type</tt><br/>
or <tt>false_type</tt></td>

<td><tt>true_type</tt> only if an allocator of type <tt>X</tt> should be copied<br/> 
when the client container is copy-assigned. <ins>See Note B, below.</ins></td>

<td><tt>false_type</tt></td>
</tr>

<tr>
<td><tt>X::propagate_on_container_move_assignment</tt></td>

<td>Identical to or derived from <tt>true_type</tt><br/>
or <tt>false_type</tt></td>

<td><tt>true_type</tt> only if an allocator of type <tt>X</tt> should be moved<br/>
when the client container is move-assigned. <ins>See Note B, below.</ins></td>

<td><tt>false_type</tt></td>
</tr>

<tr>
<td><tt>X::propagate_on_container_swap</tt></td>

<td>Identical to or derived from <tt>true_type</tt><br/>
or <tt>false_type</tt></td>

<td><tt>true_type</tt> only if an allocator of type <tt>X</tt> should be swapped<br/>
when the client container is swapped. <ins>See Note B, below.</ins></td>

<td><tt>false_type</tt></td>
</tr>

</table>
</blockquote>


</li>

<li>
<p>Following 17.6.3.5 [allocator.requirements] p. 3 insert a new normative paragraph:</p>

<blockquote><p>
<ins>Note B: If <tt>X::propagate_on_container_copy_assignment::value</tt> is true, <tt>X</tt> shall 
satisfy the <tt>CopyAssignable</tt> requirements (Table 39  [copyassignable]) and the copy 
operation shall not throw exceptions. If <tt>X::propagate_on_container_move_assignment::value</tt> is 
true, <tt>X</tt> shall satisfy the <tt>MoveAssignable</tt> requirements (Table 38  [moveassignable]) 
and the move operation shall not throw exceptions. If <tt>X::propagate_on_container_swap::value</tt> is 
true, lvalues of <tt>X</tt> shall be swappable (17.6.3.2 [swappable.requirements]) and the <tt>swap</tt> 
operation shall not throw exceptions.</ins>
</p></blockquote>
</li>

<li>
<p>Modify 23.2.1 [container.requirements.general] p. 8 and p. 9 as indicated:</p>

<blockquote><p>
8 - [..] The allocator may be replaced only via assignment or <tt>swap()</tt>. Allocator replacement is 
performed by copy assignment, move assignment, or swapping of the allocator only if 
<tt>allocator_traits&lt;allocator_type&gt;::propagate_on_container_copy_assignment::value</tt>,
<tt>allocator_traits&lt;allocator_type&gt;::propagate_on_container_move_assignment::value</tt>, 
or <tt>allocator_traits&lt;allocator_type&gt;::propagate_on_container_swap::value</tt> is true 
within the implementation of the corresponding container operation. <del>The behavior of a call to 
a container's <tt>swap</tt> function is undefined unless the objects being swapped have allocators that compare 
equal or <tt>allocator_traits&lt;allocator_type&gt;::propagate_on_container_swap::value</tt> is true</del>. In all 
container types defined in this Clause, the member <tt>get_allocator()</tt> returns a copy of the allocator 
used to construct the container or, if that allocator has been replaced, a copy of the most recent replacement.
<p/>
9 - The expression <tt>a.swap(b)</tt>, for containers <tt>a</tt> and <tt>b</tt> of a standard container type 
other than <tt>array</tt>, shall exchange the values of <tt>a</tt> and <tt>b</tt> without invoking any move, 
copy, or swap operations on the individual container elements. <ins>Lvalues of a</ins><del>A</del>ny <tt>Compare</tt>, 
<tt>Pred</tt>, or <tt>Hash</tt> <del>objects</del><ins>types</ins> belonging to <tt>a</tt> and <tt>b</tt> shall be swappable 
and shall be exchanged by <del>unqualified calls to non-member</del> <ins>calling</ins> <tt>swap</tt> 
<ins>as described in 17.6.3.2 [swappable.requirements]</ins>. If <tt>allocator_traits&lt;allocator_type&gt;::propagate_on_container_swap::value</tt> 
is <tt>true</tt>, then <ins>lvalues of <tt>allocator_type</tt> shall be swappable and</ins> the allocators of <tt>a</tt> and 
<tt>b</tt> shall also be exchanged <del>using an unqualified call to non-member</del><ins>by calling</ins>
<tt>swap</tt> <ins>as described in 17.6.3.2 [swappable.requirements]</ins>. Otherwise, 
<del>they</del><ins>the allocators</ins> shall not be swapped, and the behavior is undefined unless
<tt>a.get_allocator() == b.get_allocator()</tt>. Every iterator referring to an element in one container before
the swap shall refer to the same element in the other container after the swap. It is unspecified whether an
iterator with value <tt>a.end()</tt> before the swap will have value <tt>b.end()</tt> after the swap.
</p></blockquote>
</li>
</ol>






<hr>
<h3><a name="2035"></a>2035. Output iterator requirements are broken</h3>
<p><b>Section:</b> 24.2.4 [output.iterators] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-02-27 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#output.iterators">active issues</a> in [output.iterators].</p>
<p><b>View all other</b> <a href="lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>During the Pittsburgh meeting the proposal <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>
became accepted because it fixed several severe issues related to the iterator specification. But the current working draft (N3225)
does not reflect all these changes. Since I'm unaware whether every correction can be done editorial, this issue is submitted to take
care of that. To give one example: All expressions of Table 108 &mdash; &quot;Output iterator requirements&quot; have a post-condition
that the iterator is incrementable. This is impossible, because it would exclude any finite sequence that is accessed by an output 
iterator, such as a pointer to a C array. The N3066 wording changes did not have these effects.
</p>

<p><i>[2011-03-01: Daniel comments:]</i></p>


<p>This issue has some overlap with the issue <a href="lwg-active.html#2038">2038</a> and I would prefer if we
could solve both at one location. I suggest the following approach:
</p>
<ol>
<li><p>The terms <tt><i>dereferencable</i></tt> and <tt><i>incrementable</i></tt> could be defined in a more
general way not restricted to iterators (similar to the concepts <tt>HasDereference</tt> and 
<tt>HasPreincrement</tt> from working draft N2914). But on the other hand, all current usages of 
<tt><i>dereferencable</i></tt> and <tt><i>incrementable</i></tt> are involved with types that satisfy 
iterator requirements. Thus, I believe that it is sufficient for C++0x to add corresponding definitions to 
24.2.1 [iterator.requirements.general] and to let all previous usages of these terms refer to this 
sub-clause. Since the same problem occurs with the past-the-end iterator, this proposal suggest providing 
similar references to usages that precede its definition as well.
</p></li>
<li><p>We also need to ensure that all iterator expressions get either an operational semantics in
terms of others or we need to add missing pre- and post-conditions. E.g. we have the following
ones without semantics:
</p><blockquote><pre>
*r++ = o // output iterator
*r--     // bidirectional iterator
</pre></blockquote><p>
According to the <a href="http://www.sgi.com/tech/stl/OutputIterator.html">SGI specification</a>
these correspond to
</p><blockquote><pre>
{ *r = o; ++r; }                         // output iterator
{ reference tmp = *r; --r; return tmp; } // bidirectional iterator
</pre></blockquote><p>
respectively. Please note especially the latter expression for bidirectional iterator. It fixes a problem
that we have for forward iterator as well: Both these iterator categories provide stronger guarantees
than input iterator, because the result of the dereference operation is <tt>reference</tt>, and <strong>not</strong>
only convertible to the value type (The exact form from the SGI documentation does not correctly refer to
<tt>reference</tt>).
</p></li>
</ol>

<p><i>[2011-03-14: Daniel comments and updates the suggested wording]</i></p>


<p>In addition to the before mentioned necessary changes there is another one need, which
became obvious due to issue <a href="lwg-defects.html#2042">2042</a>: <tt>forward_list&lt;&gt;::before_begin()</tt> returns
an iterator value which is not dereferencable, but obviously the intention is that it should
be incrementable. This leads to the conclusion that imposing dereferencable as a requirement
for the expressions <tt>++r</tt> is wrong: We only need the iterator to be incrementable. A
similar conclusion applies to the expression <tt>--r</tt> of bidirectional iterators.</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
Consensus this is the correct direction, but there are (potentially) missing <i>incrementable</i>
preconditions on some table rows, and the Remarks on when an output iterator becomes dereferencable
are probably better handled outside the table, in a manner similar to the way we word for input
iterators.
</p>

<p>
There was some concern about redundant pre-conditions when the operational semantic is defined in
terms of operations that have preconditions, and a similar level of concern over dropping such
redundancies vs. applying a consistent level of redundant specification in all the iterator tables.
Wording clean-up in either direction would be welcome.
</p>

<p><i>[2011-08-18: Daniel adapts the proposed resolution to honor the Bloomington request]</i></p>


<p>
There is only a small number of further changes suggested to get rid of superfluous 
requirements and essentially non-normative assertions. Operations should not have extra 
pre-conditions, if defined by "in-terms-of" semantics, see e.g. <tt>a != b</tt> or <tt>a-&gt;m</tt> 
for Table 107. Further, some remarks, that do not impose anything or say nothing new have been removed, 
because I could not find anything helpful they provide.
E.g. consider the remarks for Table 108 for the operations dereference-assignment and
preincrement: They don't provide additional information say nothing surprising. With the
new pre-conditions <em>and</em> post-conditions it is implied what the remarks intend to say.
</p>

<p><i>[
2011-11-03: Some observations from Alexander Stepanov via c++std-lib-31405
]</i></p>


<p>
The following sentence is dropped from the standard section on OutputIterators:
<p/>
"In particular, the following two conditions should hold: first, any
iterator value should be assigned through before it is incremented
(this is, for an output iterator <tt>i, i++; i++;</tt> is not a valid code
sequence); second, any value of an output iterator may have at most
one active copy at any given time (for example, <tt>i = j; *++i = a; *j = b;</tt> 
is not a valid code sequence)."
</p>

<p><i>[
2011-11-04: Daniel comments and improves the wording
]</i></p>


<p>
In regard to the first part of the comment, the intention of the newly proposed wording 
was to make clear that for the expression
</p>
<blockquote><pre>
*r = o
</pre></blockquote>
<p>
we have the precondition dereferenceable and the post-condition
incrementable. And for the expression
</p>
<blockquote><pre>
++r
</pre></blockquote>
<p>
we have the precondition incrementable and the post-condition dereferenceable 
or past-the-end. This <em>should not</em>  allow for a sequence like <tt>i++; i++;</tt> 
but I agree that it doesn't exactly say that.
<p/>
In regard to the second point: To make this point clearer, I suggest to
add a similar additional wording as we already have for input iterator to the 
"Assertion&#47;note" column of the expression <tt>++r</tt>:
<p/>
"Post: any copies of the previous value of <tt>r</tt> are no longer 
required to be dereferenceable or incrementable."
<p/>
The proposed has been updated to honor the observations of Alexander Stepanov.
</p>



<p><b>Proposed resolution:</b></p>
<ol>
<li><p>Add a reference to 24.2.1 [iterator.requirements.general] to the following parts of the
library preceding Clause 24 Iterators library: (I stopped from 23.2.5 [unord.req] on, because
the remaining references are the concrete containers)</p>
<ol>
<li><p>17.6.3.2 [swappable.requirements] p5:</p>

<blockquote><p>
-5- A type <tt>X</tt> satisfying any of the iterator requirements (24.2) is <tt><i>ValueSwappable</i></tt> if, 
for any dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins> object <tt>x</tt> of type 
<tt>X</tt>, <tt>*x</tt> is swappable.
</p></blockquote>
</li>

<li><p>17.6.3.5 [allocator.requirements], Table 27 &mdash; &quot;Descriptive variable definitions&quot;, 
row with the expression <tt>c</tt>:</p>

<blockquote><p>
a dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins> pointer of type <tt>C*</tt>
</p></blockquote>

</li>

<li><p>20.7.3.2 [pointer.traits.functions]:</p>
<blockquote><p>
<i>Returns</i>: The first template function returns a dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins> 
pointer to <tt>r</tt> obtained by calling <tt>Ptr::pointer_to(r)</tt>;  [&hellip;]
</p></blockquote>
</li>

<li><p>21.4.3 [string.iterators] p. 2:</p>
<blockquote><p>
<i>Returns</i>: An iterator which is the past-the-end value <ins>(24.2.1 [iterator.requirements.general])</ins>.
</p></blockquote>
</li>

<li><p>22.4.5.1.2 [locale.time.get.virtuals] p. 11:</p>
<blockquote><pre>
iter_type do_get(iter_type s, iter_type end, ios_base&amp; f,
  ios_base::iostate&amp; err, tm *t, char format, char modifier) const;
</pre><blockquote><p>
<i>Requires</i>: <tt>t</tt> shall be dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins>.
</p></blockquote></blockquote>
</li>

<li><p>23.2.1 [container.requirements.general] p. 6:</p>

<blockquote><p>
[&hellip;]  <tt>end()</tt> returns an iterator which is the past-the-end <ins>(24.2.1 [iterator.requirements.general])</ins> 
value for the container.  [&hellip;]
</p></blockquote>
</li>

<li><p>23.2.3 [sequence.reqmts] p. 3:</p>

<blockquote><p>
[&hellip;]  <tt>q</tt> denotes a valid dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins> 
const iterator to <tt>a</tt>,  [&hellip;]
</p></blockquote>
</li>

<li><p>23.2.4 [associative.reqmts] p. 8 (I omit intentionally one further reference in the same sub-clause):</p>

<blockquote><p>
[&hellip;]  <tt>q</tt> denotes a valid dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins> 
const iterator to <tt>a</tt>,  [&hellip;]
</p></blockquote>
</li>

<li><p>23.2.5 [unord.req] p. 10 (I omit intentionally one further reference in the same sub-clause):</p>

<blockquote><p>
[&hellip;]  <tt>q</tt> and <tt>q1</tt> are valid dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins> 
const iterators to <tt>a</tt>,  [&hellip;]
</p></blockquote>
</li>
</ol>

</li>
<li><p>Edit 24.2.1 [iterator.requirements.general] p. 5 as indicated (The intent is to properly define
<i>incrementable</i> and to ensure some further library guarantee related to past-the-end iterator values):</p>

<blockquote><p>
-5- Just as a regular pointer to an array guarantees that there is a pointer value pointing past the last element
of the array, so for any iterator type there is an iterator value that points past the last element of a
corresponding sequence. These values are called <i>past-the-end values</i>. Values of an iterator <tt>i</tt> for which the
expression <tt>*i</tt> is defined are called <i>dereferenceable</i>. <ins>Values of an iterator <tt>i</tt> for which the
expression <tt>++i</tt> is defined are called <i>incrementable</i>. </ins> The library never assumes that 
past-the-end values are dereferenceable <ins>or incrementable</ins>. Iterators can also have singular values 
that are not associated with any sequence. [&hellip;]
</p></blockquote>
</li>

<li><p>Modify the column contents of Table 106 &mdash; &quot;Iterator requirements&quot;, 
24.2.2 [iterator.iterators], as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 106 &mdash; Iterator requirements</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr>

<tr>
<td><tt>*r</tt></td>
<td><tt>reference</tt></td>
<td><tt>&nbsp;</tt></td>
<td>pre: <tt>r</tt> is dereferenceable.</td>
</tr>

<tr>
<td><tt>++r</tt></td>
<td><tt>X&amp;</tt></td>
<td><tt>&nbsp;</tt></td>
<td><ins>pre: <tt>r</tt> is incrementable.</ins></td>
</tr>

</table>
</blockquote>
</li>

<li><p>Modify the column contents of Table 107 &mdash; &quot;Input iterator requirements&quot;, 
24.2.3 [input.iterators], as indicated [<i>Rationale</i>: The wording changes attempt
to define a minimal "independent" set of operations, namely <tt>*a</tt> and <tt>++r</tt>, and 
to specify the semantics of the remaining ones. This approach seems to be in agreement with the 
original <a href="http://www.sgi.com/tech/stl/InputIterator.html">SGI specification</a> 
&mdash; <i>end rationale</i>]:</p>

<blockquote>
<table border="1">
<caption>Table 107 &mdash; Input iterator requirements (in addition to Iterator)</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr>

<tr>
<td><tt>a != b</tt></td>
<td>contextually<br/>
convertible to <tt>bool</tt></td>
<td><tt>!(a == b)</tt></td>
<td><del>pre: <tt>(a, b)</tt> is in the domain<br/>
of <tt>==</tt>.</del>
</td>
</tr>

<tr>
<td><tt>*a</tt></td>
<td>convertible to <tt>T</tt></td>
<td><tt>&nbsp;</tt></td>
<td>pre: <tt>a</tt> is dereferenceable.<br/>
The expression<br/>
<tt>(void)*a, *a</tt> is equivalent<br/>
to <tt>*a</tt>.<br/>
If <tt>a == b</tt> and <tt>(a,b)</tt> is in<br/>
the domain of <tt>==</tt> then <tt>*a</tt> is<br/>
equivalent to <tt>*b</tt>.
</td>
</tr>

<tr>
<td><tt>a-&gt;m</tt></td>
<td><tt>&nbsp;</tt></td>
<td><tt>(*a).m</tt></td>
<td><del>pre: <tt>a</tt> is dereferenceable.</del></td>
</tr>

<tr>
<td><tt>++r</tt></td>
<td><tt>X&amp;</tt></td>
<td><tt>&nbsp;</tt></td>
<td>pre: <tt>r</tt> is <del>dereferenceable</del><ins>incrementable</ins>.<br/>
post: <tt>r</tt> is dereferenceable or<br/>
<tt>r</tt> is past-the-end.<br/>
post: any copies of the<br/>
previous value of <tt>r</tt> are no<br/>
longer required either to be<br/>
dereferenceable<ins>, incrementable,</ins><br/>
or to be in the domain of <tt>==</tt>.
</td>
</tr>

<tr>
<td><tt>(void)r++</tt></td>
<td><tt>&nbsp;</tt></td>
<td><ins><tt>(void)++r</tt></ins></td>
<td><del>equivalent to <tt>(void)++r</tt></del></td>
</tr>

<tr>
<td><tt>*r++</tt></td>
<td>convertible to <tt>T</tt></td>
<td><tt>{ T tmp = *r;<br/>
++r;<br/>
return tmp; }
</tt></td>
<td><tt>&nbsp;</tt></td>
</tr>

</table>
</blockquote>
</li>

<li>
<p>Modify the column contents of Table 108 &mdash; &quot;Output iterator requirements&quot;, 
24.2.4 [output.iterators], as indicated [<i>Rationale</i>: The wording changes attempt
to define a minimal "independent" set of operations, namely <tt>*r = o</tt> and <tt>++r</tt>,
and to specify the semantics of the remaining ones. This approach seems to be in agreement with
the original <a href="http://www.sgi.com/tech/stl/OutputIterator.html">SGI specification</a> 
&mdash; <i>end rationale</i>]:</p>

<blockquote>
<table border="1">
<caption>Table 108 &mdash; Output iterator requirements (in addition to Iterator)</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr>

<tr>
<td><tt>*r = o</tt></td>
<td>result is not used</td>
<td><tt>&nbsp;</tt></td>
<td><ins>pre: <tt>r</tt> is dereferenceable.</ins><br/>
<i>Remark</i>: After this operation<br/>
<tt>r</tt> is not required to be<br/>
dereferenceable <ins>and any copies of<br/>
the previous value of <tt>r</tt> are no<br/>
longer required to be dereferenceable<br/>
or incrementable.</ins><br/>
post: <tt>r</tt> is incrementable.
</td>
</tr>

<tr>
<td><tt>++r</tt></td>
<td><tt>X&amp;</tt></td>
<td><tt>&nbsp;</tt></td>
<td><ins>pre: <tt>r</tt> is incrementable.</ins><br/>
<tt>&amp;r == &amp;++r</tt>.<br/>
<del><i>Remark</i>: After this operation<br/>
<tt>r</tt> is not required to be<br/>
dereferenceable.<br/></del>
<ins><i>Remark</i>: After this operation<br/>
<tt>r</tt> is not required to be<br/>
incrementable and any copies of<br/>
the previous value of <tt>r</tt> are no<br/>
longer required to be dereferenceable<br/>
or incrementable.</ins><br/>
post: <tt>r</tt> is <ins>dereferenceable<br/>
or <tt>r</tt> is past-the-end</ins><del>incrementable</del>.<br/>
</td>
</tr>

<tr>
<td><tt>r++</tt></td>
<td>convertible to <tt>const X&amp;</tt></td>
<td><tt>{ X tmp = r;<br/>
  ++r;<br/>
  return tmp; }</tt>
</td>
<td><del><i>Remark</i>: After this operation<br/>
<tt>r</tt> is not required to be<br/>
dereferenceable.<br/>
post: <tt>r</tt> is incrementable.</del>
</td>
</tr>

<tr>
<td><tt>*r++ = o</tt></td>
<td>result is not used</td>
<td><ins><tt>{ *r = o; ++r; }</tt></ins></td>
<td><del><i>Remark</i>: After this operation<br/>
<tt>r</tt> is not required to be<br/>
dereferenceable.<br/>
post: <tt>r</tt> is incrementable.</del>
</td>
</tr>
</table>
</blockquote>
</li>

<li><p>Modify the column contents of Table 109 &mdash; &quot;Forward iterator requirements&quot;, 
24.2.5 [forward.iterators], as indicated [<i>Rationale</i>: Since the return type of the
expression <tt>*r++</tt> is now guaranteed to be type <tt>reference</tt>, the implied operational
semantics from input iterator based on value copies is wrong &mdash; <i>end rationale</i>]</p>

<blockquote>
<table border="1">
<caption>Table 109 &mdash; Forward iterator requirements (in addition to input iterator)</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr>

<tr>
<td><tt>r++</tt></td>
<td>convertible to <tt>const X&amp;</tt></td>
<td><tt>{ X tmp = r;<br/>
  ++r;<br/>
  return tmp; }</tt>
</td>
<td><tt>&nbsp;</tt></td>
</tr>

<tr>
<td><tt>*r++</tt></td>
<td>reference</td>
<td><ins><tt>{ reference tmp = *r;<br/>
 ++r;<br/> 
 return tmp; }</tt></ins></td>
<td><tt>&nbsp;</tt></td>
</tr>
</table>
</blockquote>

</li>

<li><p>Modify the column contents of Table 110 &mdash; &quot;Bidirectional iterator requirements&quot;, 
24.2.6 [bidirectional.iterators], as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 110 &mdash; Bidirectional iterator requirements (in addition to forward iterator)</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr>

<tr>
<td><tt>--r</tt></td>
<td><tt>X&amp;</tt></td>
<td><tt>&nbsp;</tt></td>
<td>pre: there exists <tt>s</tt> such that<br/>
<tt>r == ++s</tt>.<br/>
post: <tt>r</tt> is <del>dereferenceable</del><ins>incrementable</ins>.<br/>
<tt>--(++r) == r</tt>.<br/>
<tt>--r == --s</tt> implies <tt>r == s</tt>.<br/>
<tt>&amp;r == &amp;--r</tt>.
</td>
</tr>

<tr>
<td><tt>r--</tt></td>
<td>convertible to <tt>const X&amp;</tt></td>
<td><tt>{ X tmp = r;<br/>
  --r;<br/>
  return tmp; }</tt>
</td>
<td><tt>&nbsp;</tt></td>
</tr>

<tr>
<td><tt>*r--</tt></td>
<td>reference</td>
<td><ins><tt>{ reference tmp = *r;<br/>
 --r;<br/> 
 return tmp; }</tt></ins></td>
<td><tt>&nbsp;</tt></td>
</tr>
</table>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2038"></a>2038. Missing definition for <tt>incrementable</tt> iterator</h3>
<p><b>Section:</b> 24.2.4 [output.iterators] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2011-02-27 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#output.iterators">active issues</a> in [output.iterators].</p>
<p><b>View all other</b> <a href="lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>In comp.lang.c++, Vicente Botet raises the following questions:</p>

<blockquote><p>
&quot;In "24.2.4 Output iterators" there are 3 uses of incrementable. I've
not found the definition. Could some one point me where it is defined?
<p/>
Something similar occurs with dereferenceable. While the definition is
given in "24.2.1 In general" it is used several times before.
<p/>
Shouldn't these definitions be moved to some previous section?&quot;
</p></blockquote>

<p>He's right: both terms are used without being properly defined.
<p/>
There is no definition of "incrementable".
<p/>
While there is a definition of "dereferenceable", it is, in fact, a definition of 
"dereferenceable iterator". "dereferenceable" is used throughout Clause 23 (Containers) 
before its definition in Clause 24. In almost all cases it's referring to iterators, 
but in 17.6.3.2 [swappable.requirements] there is a mention of "dereferenceable object"; in 
17.6.3.5 [allocator.requirements] the table of Descriptive variable definitions refers to a 
"dereferenceable pointer"; 20.7.3.2 [pointer.traits.functions] refers to a 
"dereferenceable pointer"; in 22.4.5.1.2 [locale.time.get.virtuals]&#47;11 (<tt>do_get</tt>) 
there is a requirement that a pointer "shall be dereferenceable". In those specific cases 
it is not defined.
</p>

<p><i>[2011-03-02: Daniel comments:]</i></p>


<p>I believe that the currently proposed resolution of issue <a href="lwg-active.html#2035">2035</a> solves this
issue as well.</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
Agree with Daniel, this will be handled by the resolution of <a href="lwg-active.html#2035">2035</a>.
</p>



<p><b>Proposed resolution:</b></p>
<p></p>





<hr>
<h3><a name="2051"></a>2051. Explicit <tt>tuple</tt> constructors for more than one parameter</h3>
<p><b>Section:</b> 20.4.2 [tuple.tuple], 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2011-05-01 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#tuple.tuple">issues</a> in [tuple.tuple].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
One of my constituents wrote the following:
<p/>
-------snip------------
<p/>
So far the only use I've found for <tt>std::tuple</tt> is as an ad-hoc type to emulate
multiple return values. If the tuple ctor was made non-explicit one could
almost think C++ supported multiple return values especially when combined
with <tt>std::tie()</tt>.
</p>
<blockquote><pre>
// assume types line_segment and point
// assume function double distance(point const&amp;, point const&amp;)

std::tuple&lt;point, point&gt;
closest_points(line_segment const&amp; a, line_segment const&amp; b) {
 point ax;
 point bx;
 /* some math */

 return {ax, bx};
}


double
distance(line_segment const&amp; a, line_segment const&amp; b) {
 point ax;
 point bx;
 std::tie(ax, bx) = closest_points(a, b);

 return distance(ax, bx);
}
</pre></blockquote>
<p>
-------snap----------
<p/>
See also the messages starting from lib-29330.
<p/>
Some notes:
</p>
<ol>
<li><tt>pair</tt> allows such a return</li>
<li>a lambda with a deduced return type doesn't allow it for any type</li>
<li><tt>decltype</tt> refuses <tt>{1, 2}</tt></li>
</ol>
<p>
I would recommend making non-unary <tt>tuple</tt> constructors non-explicit.
</p>

<p><i>[Bloomington, 2011]</i></p>

<p>
Move to NAD Future, this would be an extension to existing functionality.
</p>

<p><i>[Portland, 2012]</i></p>

<p>
Move to Open at the request of the Evolution Working Group.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2059"></a>2059. C++0x ambiguity problem with <tt>map::erase</tt></h3>
<p><b>Section:</b> 23.4.4 [map] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Christopher Jefferson <b>Opened:</b> 2011-05-18 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#map">issues</a> in [map].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>map::erase</tt> (and several related methods) took an iterator in C++03, but take a <tt>const_iterator</tt> 
in C++0x. This breaks code where the map's <tt>key_type</tt> has a constructor which accepts an iterator 
(for example a template constructor), as the compiler cannot choose between <tt>erase(const key_type&amp;)</tt> 
and <tt>erase(const_iterator)</tt>.</p>
<blockquote><pre>
#include &lt;map&gt;

struct X
{
  template&lt;typename T&gt;
  X(T&amp;) {}
};

bool operator&lt;(const X&amp;, const X&amp;) { return false; }

void erasor(std::map&lt;X,int&gt;&amp; s, X x)
{
  std::map&lt;X,int&gt;::iterator it = s.find(x);
  if (it != s.end())
    s.erase(it);
}
</pre></blockquote>

<p><i>[
2011 Bloomington
]</i></p>


<p>
This issue affects only associative container <tt>erase</tt> calls, and is not more general, as these are the
only functions that are also overloaded on another single arguement that might cause confusion - the <tt>erase</tt>
by key method.  The complete resolution should simply restore the <tt>iterator</tt> overload in addition to the
<tt>const_iterator</tt> overload for all eight associative containers. 
</p>

<p>
Proposed wording supplied by Alan Talbot, and moved to Review.
</p>


<p><i>[2012, Kona]</i></p>

<p>
Moved back to Open by post-meeting issues processing group.
</p>
<p>
Pablo very unhappy about case of breaking code with ambiguous conversion between both iterator types.
</p>
<p>
Alisdair strongly in favor of proposed resolution, this change from C++11 bit Chris in real code,
and it took a while to track down the cause.
</p>
<p>
Move to open, bring in front of a larger group
</p>
<p>
Proposed wording from Jeremiah:

<tt>erase(key)</tt> shall not participate in overload resolution if <tt>iterator</tt> is
convertible to <tt>key</tt>.

Note that this means making <tt>erase(key)</tt> a template-method
</p>
<p>
Poll Chris to find out if he already fixed his code, or fixed his library
</p>
<p>
Jeremiah - allow both overloads, but <tt>enable_if</tt> the <tt>const_iterator</tt> form as
a template, requiring <tt>is_same</tt> to match only <tt>const_iterator</tt>.
</p>
<p>
Poll PJ to see if he has already applied this fix?
</p>


<p><b>Proposed resolution:</b></p>
<p>
Editorial note: The following things are different between 23.2.4 [associative.reqmts] p.8 and
23.2.5 [unord.req] p.10. These should probably be reconciled.
</p>
<blockquote>
<ol>
<li>First uses the convention "denotes";  second uses the convention "is".</li>
<li>First redundantly says: "If no such element exists, returns a.end()." in erase table entry, second does not.</li>
</ol>
</blockquote>

<p>
23.2.4 [associative.reqmts] Associative containers
</p>
<p>
8 In Table 102, <tt>X</tt> denotes an associative container class, <tt>a</tt> denotes a value of <tt>X</tt>, <tt>a_uniq</tt>
denotes a value of <tt>X</tt> when <tt>X</tt> supports unique keys, <tt>a_eq</tt> denotes a value of <tt>X</tt> when
<tt>X</tt> supports multiple keys, <tt>u</tt> denotes an identifier, <tt>i</tt> and <tt>j</tt> satisfy input iterator
requirements and refer to elements implicitly convertible to <tt>value_type</tt>, <tt>[i,j)</tt> denotes a valid range,
<tt>p</tt> denotes a valid const iterator to <tt>a</tt>, <tt>q</tt> denotes a valid dereferenceable const iterator to <tt>a</tt>,
<ins><tt>r</tt> denotes a valid dereferenceable iterator to a,</ins> <tt>[q1, q2)</tt> denotes a valid range of const iterators
in <tt>a</tt>, <tt>il</tt> designates an object of type <tt>initializer_list&lt;value_type></tt>, <tt>t</tt> denotes a value of
<tt>X::value_type</tt>, <tt>k</tt> denotes a value of <tt>X::key_type</tt> and <tt>c</tt> denotes a value of type
<tt>X::key_compare</tt>. <tt>A</tt> denotes the storage allocator used by <tt>X</tt>, if any, or
<tt>std::allocator&lt;X::value_type></tt> otherwise, and <tt>m</tt> denotes an allocator of a type convertible to <tt>A</tt>.
</p>

<p>
23.2.4 [associative.reqmts] Associative containers Table 102
</p>
<p>
Add row:
</p>
<ins>
<table border="1">
<tr>
<td><tt>a.erase(r)</tt></td>
<td><tt>iterator</tt></td>
<td>
erases the element pointed to by <tt>r</tt>. Returns an iterator pointing to the element immediately following <tt>r</tt>
prior to the element being erased. If no such element exists, returns <tt>a.end()</tt>.
</td>
<td>amortized constant</td>
</tr>
</table>
</ins>

<p>
23.2.5 [unord.req] Unordered associative containers</p>
<p>
10 In table 103: <tt>X</tt> is an unordered associative container class, <tt>a</tt> is an object of type <tt>X</tt>,
<tt>b</tt> is a possibly const object of type <tt>X</tt>, <tt>a_uniq</tt> is an object of type <tt>X</tt> when
<tt>X</tt> supports unique keys, <tt>a_eq</tt> is an object of type <tt>X</tt> when <tt>X</tt> supports equivalent keys,
<tt>i</tt> and <tt>j</tt> are input iterators that refer to <tt>value_type</tt>, <tt>[i, j)</tt> is a valid range,
<tt>p</tt> and <tt>q2</tt> are valid const iterators to <tt>a</tt>, <tt>q</tt> and <tt>q1</tt> are valid dereferenceable
const iterators to <tt>a</tt>, <ins><tt>r</tt> is a valid dereferenceable iterator to a,</ins> <tt>[q1,q2)</tt> is a
valid range in <tt>a</tt>, <tt>il</tt> designates an object of type <tt>initializer_list&lt;value_type></tt>,
<tt>t</tt> is a value of type <tt>X::value_type</tt>, <tt>k</tt> is a value of type <tt>key_type</tt>, <tt>hf</tt> is a
possibly const value of type <tt>hasher</tt>, <tt>eq</tt> is a possibly const value of type <tt>key_equal</tt>,
<tt>n</tt> is a value of type <tt>size_type</tt>, and <tt>z</tt> is a value of type <tt>float</tt>.
</p>

<p>
23.2.5 [unord.req] Unordered associative containers Table 103
</p>
<p>
Add row:
</p>
<ins>
<table border="1">
<tr>
<td><tt>a.erase(r)</tt></td>
<td><tt>iterator</tt></td>
<td>
Erases the element pointed to by <tt>r</tt>. Returns the iterator immediately following <tt>r</tt> prior to the erasure.
</td>
<td>Average case O(1), worst case O(<tt>a.size()</tt>).</td>
</tr>
</table>
</ins>

<p>
23.4.4.1 [map.overview] Class template map overview p. 2
</p>
<pre>
<ins>iterator erase(iterator position);</ins>
iterator erase(const_iterator position);
size_type erase(const key_type&amp; x);
iterator erase(const_iterator first, const_iterator last);
</pre>

<p>
23.4.5.1 [multimap.overview] Class template multimap overview p. 2
</p>
<pre>
<ins>iterator erase(iterator position);</ins>
iterator erase(const_iterator position);
size_type erase(const key_type&amp; x);
iterator erase(const_iterator first, const_iterator last);
</pre>

<p>
23.4.6.1 [set.overview] Class template set overview p. 2
</p>
<pre>
<ins>iterator erase(iterator position);</ins>
iterator erase(const_iterator position);
size_type erase(const key_type&amp; x);
iterator erase(const_iterator first, const_iterator last);
</pre>

<p>
23.4.7.1 [multiset.overview] Class template multiset overview 
</p>
<pre>
<ins>iterator erase(iterator position);</ins>
iterator erase(const_iterator position);
size_type erase(const key_type&amp; x);
iterator erase(const_iterator first, const_iterator last);
</pre>

<p>
23.5.4.1 [unord.map.overview] Class template unordered_map overview p. 3
</p>
<pre>
<ins>iterator erase(iterator position);</ins>
iterator erase(const_iterator position);
size_type erase(const key_type&amp; x);
iterator erase(const_iterator first, const_iterator last);
</pre>

<p>
23.5.5.1 [unord.multimap.overview] Class template unordered_multimap overview p. 3
</p>
<pre>
<ins>iterator erase(iterator position);</ins>
iterator erase(const_iterator position);
size_type erase(const key_type&amp; x);
iterator erase(const_iterator first, const_iterator last);
</pre>

<p>
23.5.6.1 [unord.set.overview] Class template unordered_set overview p. 3
</p>
<pre>
<ins>iterator erase(iterator position);</ins>
iterator erase(const_iterator position);
size_type erase(const key_type&amp; x);
iterator erase(const_iterator first, const_iterator last);
</pre>


<p>
23.5.7.1 [unord.multiset.overview] Class template unordered_multiset overview p. 3
</p>
<pre>
<ins>iterator erase(iterator position);</ins>
iterator erase(const_iterator position);
size_type erase(const key_type&amp; x);
iterator erase(const_iterator first, const_iterator last);
</pre>

<p>
C.2.13 [diff.cpp03.containers] C.2.12 Clause 23: containers library 
</p>
<p>
23.2.3, 23.2.4
</p>
<p>
Change: Signature changes: from iterator to const_iterator parameters
</p>
<p>
Rationale: Overspecification. Effects: The signatures of the following member functions changed from
taking an iterator to taking a const_iterator:
</p>
<ul>
<li>insert(iter, val) for vector, deque, list, set, multiset, map, multimap</li>
<li>insert(pos, beg, end) for vector, deque, list, forward_list</li>
<li><del>erase(iter) for set, multiset, map, multimap</del></li>
<li>erase(begin, end) for set, multiset, map, multimap</li>
<li>all forms of list::splice</li>
<li>all forms of list::merge</li>
</ul>
<p>
Valid C++ 2003 code that uses these functions may fail to compile with this International Standard.
</p>





<hr>
<h3><a name="2062"></a>2062. Effect contradictions w&#47;o no-throw guarantee of <tt>std::function</tt> swaps</h3>
<p><b>Section:</b> 20.9.11.2 [func.wrap.func], 20.9.11.2.2 [func.wrap.func.mod] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-05-28 <b>Last modified:</b> 2014-05-02</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Howard Hinnant observed in reflector message c++std-lib-30841 that 20.9.11.2 [func.wrap.func] 
makes the member swap <tt>noexcept</tt>, even though the non-member swap is not <tt>noexcept</tt>. 
<p/>
The latter was an outcome of the discussions during the Batavia meeting and the Madrid meeting 
involving LWG <a href="lwg-defects.html#1349">1349</a>, which seems to indicate that the remaining <tt>noexcept</tt> 
specifier at the member swap is incorrect and should be removed.
<p/>
But if we allow for a potentially throwing member swap of <tt>std::function</tt>, this causes 
another conflict with the exception specification for the following member function:
</p>
<blockquote><pre>
template&lt;class F&gt; function&amp; operator=(reference_wrapper&lt;F&gt; f) <span style="color:#C80000;font-weight:bolder">noexcept</span>;
</pre><blockquote><p>
<i>Effects</i>: <tt>function(f).<span style="color:#C80000;font-weight:bolder">swap</span>(*this);</tt>
</p>
</blockquote></blockquote>
<p>
Note that in this example the sub-expression <tt>function(f)</tt> does not cause any problems,
because of the nothrow-guarantee given in 20.9.11.2.1 [func.wrap.func.con] p. 10. The problem
is located in the usage of the swap which could potentially throw given the general latitude. 
<p/>
So, either the Madrid meeting decision need to be revised (and both member and free swap of 
<tt>std::function</tt> should be noexcept), or this function needs to be adapted as well,
e.g. by taking the exception-specification away or by changing the semantics.
<p/>
One argument for "swap-may-throw" would be to allow for small-object optimization techniques
where the copy of the target may throw. But given the fact that the swap function has been guaranteed 
to be "Throws: Nothing" from TR1 on, it seems to me that that there would still be opportunities to 
perform small-object optimizations just restricted to the set of target copies that cannot throw. 
<p/>
In my opinion member swap of <tt>std::function</tt> has always been intended to be no-throw, because
otherwise there would be no good technical reason to specify the effects of several member 
functions in terms of the "construct-swap" idiom (There are three functions that are defined
this way), which provides the strong exception safety in this case. I suggest to enforce that both 
member swap and non-member swap of <tt>std::function</tt> are nothrow functions as it had been guaranteed 
since TR1 on.
</p>

<p><i>[
2011 Bloomington
]</i></p>

<p>
Dietmar: May not be swappable in the first place.
</p>
<p>
Alisdair: This is wide contact. Then we should be taking noexcept off instead of putting it on. This is preferred resolution.
</p>
<p>
Pablo: This is bigger issue. Specification of assignment in terms of swap is suspect to begin with. It is over specification.
How this was applied to string is a better example to work from.
</p>
<p>
Pablo: Two problems: inconsistency that should be fixed (neither should have noexcept), the other issues is that assignment
should not be specified in terms of swap. There are cases where assignment should succeed where swap would fail. This is easier
with string as it should follow container rules.
</p>
<p>
<b>Action Item</b> (Alisdair): There are a few more issues found to file.
</p>
<p>
Dave: This is because of allocators? The allocator makes this not work.
</p>
<p>
Howard: There is a type erased allocator in shared_ptr. There is a noexcept allocator in shared_ptr.
</p>
<p>
Pablo: shared_ptr is a different case. There are shared semantics and the allocator does move around.
A function does not have shared semantics.
</p>
<p>
Alisdair: Function objects think they have unique ownership.
</p>
<p>
Howard: In function we specify semantics with copy construction and swap.
</p>
<p>
<b>Action Item</b> (Pablo): Write this up better (why assignment should not be defined in terms of swap)
</p>
<p>
Howard: Not having trouble making function constructor no throw.
</p>
<p>
Dietmar: Function must allocate memory.
</p>
<p>
Howard: Does not put stuff that will throw on copy or swap in small object optimization. Put those on heap.
Storing allocator, but has to be no throw copy constructable.
</p>
<p>
Pablo: Are you allowed to or required to swap or move allocators in case or swap or move.
</p>
<p>
Dave: An allocator that is type erased should be different...
</p>
<p>
Pablo: it is
</p>
<p>
Dave: Do you need to know something about allocator types? But only at construction time.
</p>
<p>
Pablo: You could have allocators that are different types.
</p>
<p>
Dave: Swap is two ended operation.
</p>
<p>
Pablo: Opinion is that both have to say propagate on swap for them to swap.
</p>
<p>
John: It is not arbitrary. If one person says no. No is no.
</p>
<p>
Howard: Find noexcept swap to be very useful. Would like to move in that direction and bring container design along.
</p>
<p>
Dave: If you have something were allocator must not propagate you can detect that at construction time.
</p>
<p>
...
</p>
<p>
Pablo: Need to leave this open and discuss in smaller group.
</p>
<p>
Alisdair: Tried to add boost::any as TR2 proposal and ran into this issue. Only the first place where we run into
issues with type erased allocators. Suggest we move it to open.
</p>
<p>
<b>Action Item</b>: Move to open.
</p>
<p>
<b>Action Item</b> (Pablo works with Howard and Daniel): Address the more fundamental issue
(which may be multiple issues) and write up findings.
</p>

<p><i>[
<b>Original resolution</b>:
]</i></p>

<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>Modify the header <tt>&lt;functional&gt;</tt> synopsis in 20.9 [function.objects] as indicated:</p>
<blockquote><pre>
namespace std {
  [&hellip;]

  template&lt;class R, class... ArgTypes&gt;
  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;) <ins>noexcept</ins>;

  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Modify the class template <tt>function</tt> synopsis in 20.9.11.2 [func.wrap.func] as indicated:</p>
<blockquote><pre>
namespace std {
  [&hellip;]

  <i>// [func.wrap.func.alg], specialized algorithms:</i>
  template&lt;class R, class... ArgTypes&gt;
  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;) <ins>noexcept</ins>;

  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Modify 20.9.11.2.7 [func.wrap.func.alg] as indicated:</p>
<blockquote><pre>
template&lt;class R, class... ArgTypes&gt;
void swap(function&lt;R(ArgTypes...)&gt;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp; f2) <ins>noexcept</ins>;
</pre><blockquote><p>
-1- <i>Effects</i>: <tt>f1.swap(f2);</tt>
</p></blockquote></blockquote>
</li>

</ol>

<p><i>[2014-02-28 (Post Issaquah), Pablo provides more information]</i></p>


<p>
For cross-referencing purposes: The resolution of this issue should be
harmonized with any resolution to LWG <a href="lwg-active.html#2370">2370</a>, which addresses
inappropriate <tt>noexcept</tt>s in some function constructors.
</p>

<p>We have the following choices:</p>

<ol>
<li>
<p><tt>swap()</tt> does not throw</p>

<blockquote><p>
<i>Discussion</i>: This definition is desirable, and allows assignment
   to be implemented with the strong exception guarantee, but it does have
   consequences: The implementation cannot use the small-object optimization
   for a function-object <tt>F</tt> unless <tt>F</tt> is <tt>NothrowMovable</tt> 
   (nothrow-swappable is unimportant because <tt>F</tt> is not swapped with another <tt>F</tt>). 
   Note that many functors written before C++11 will not have move constructors decorated
   with <tt>noexcept</tt>, so this limitation could affect a lot of code.
</p>
<p>
It is not clear what other implementation restrictions might be
   needed. Allocators are required not to throw on move or copy. Is that
   sufficient?
</p>
</blockquote>
</li>

<li>
<p><tt>swap()</tt> can throw</p>

<blockquote>
<p>
<i>Discussion</i>: This definition gives maximum latitude to implementation to
   use small-object optimization. However, the strong guarantee on assignment
   is difficult to achieve.  Should we consider giving up on the strong
   guarantee? How much are we willing to pessimize code for exceptions?
</p>
</blockquote>
</li>
<li>
<p><tt>swap()</tt> will not throw if both functions have <tt>NoThrowMoveable</tt> functors</p>

<blockquote>
<p>
<i>Discussion</i>: This definition is similar to option 2, but gives slightly
  stronger guarantees.  Here, <tt>swap()</tt> can throw, but the programmer can
  theoretically prevent that from happening. This should be straight-forward
  to implement and gives the implementation a lot of latitude for
  optimization. However, because this is a dynamic decision, the program is
  not as easy to reason about. Also, the strong guarantee for assignment is
  compromized as in option 2.
</p>
</blockquote>
</li>
</ol>




<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2063"></a>2063. Contradictory requirements for string move assignment</h3>
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2011-05-29 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
<p><b>View all other</b> <a href="lwg-index.html#basic.string">issues</a> in [basic.string].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
21.4.1 [string.require]&#47;p4 says that <tt>basic_string</tt> is an "allocator-aware" 
container and behaves as described in 23.2.1 [container.requirements.general].
<p/>
23.2.1 [container.requirements.general] describes move assignment in p7 and Table 99.
<p/>
If <tt>allocator_traits&lt;allocator_type&gt;::propagate_on_container_move_assignment::value</tt> 
is false, and if the allocators stored in the lhs and rhs sides are not equal, then move 
assigning a string has the same semantics as copy assigning a string as far as resources are 
concerned (resources can not be transferred). And in this event, the lhs may have to acquire 
resources to gain sufficient capacity to store a copy of the rhs.
<p/>
However 21.4.2 [string.cons]&#47;p22 says:
</p><blockquote><pre>
basic_string&lt;charT,traits,Allocator&gt;&amp;
operator=(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; str) noexcept;
</pre><blockquote><p>
<i>Effects</i>: If <tt>*this</tt> and <tt>str</tt> are not the same object, modifies <tt>*this</tt> 
as shown in Table 71. [<i>Note</i>: A valid implementation is <tt>swap(str)</tt>. &mdash; <i>end note</i> ]
</p></blockquote></blockquote><p>
These two specifications for <tt>basic_string::operator=(basic_string&amp;&amp;)</tt> are in conflict with 
each other. It is not possible to implement a <tt>basic_string</tt> which satisfies both requirements.
<p/>
Additionally assign from an rvalue <tt>basic_string</tt> is defined as:
</p><blockquote><pre>
basic_string&amp; assign(basic_string&amp;&amp; str) noexcept;
</pre><blockquote><p>
<i>Effects</i>: The function replaces the string controlled by <tt>*this</tt> with a string of length 
<tt>str.size()</tt> whose elements are a copy of the string controlled by <tt>str</tt>. [ <i>Note</i>: A valid 
implementation is <tt>swap(str)</tt>. &mdash; <i>end note</i> ]
</p></blockquote></blockquote><p>
It seems contradictory that this member can be sensitive to <tt>propagate_on_container_swap</tt> instead 
of <tt>propagate_on_container_move_assignment</tt>.  Indeed, there is a very subtle chance for undefined 
behavior here:  If the implementation implements this in terms of <tt>swap</tt>, and if 
<tt>propagate_on_container_swap</tt> is false, and if the two allocators are unequal, the behavior 
is undefined, and will likely lead to memory corruption.  That's a lot to go wrong under a member 
named "assign".
</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
Alisdair: Can this be conditional noexcept?
</p>
<p>
Pablo: We said we were not going to put in many conditional noexcepts. Problem is not allocator, but non-normative definition. It says swap is a valid operation which it is not.
</p>
<p>
Dave: Move assignment is not a critical method.
</p>
<p>
Alisdair: Was confusing assignment and construction.
</p>
<p>
Dave: Move construction is critical for efficiency.
</p>
<p>
Kyle: Is it possible to test for noexcept.
</p>
<p>
Alisdair: Yes, query the noexcept operator.
</p>
<p>
Alisdair: Agreed there is a problem that we cannot unconditionally mark these operations as noexcept.
</p>
<p>
Pablo: How come swap is not defined in alloc
</p>
<p>
Alisdair: It is in utility.
</p>
<p>
Pablo: Swap has a conditional noexcept. Is no throw move constructable, is no throw move assignable.
</p>
<p>
Pablo: Not critical for strings or containers.
</p>
<p>
Kyle: Why?
</p>
<p>
Pablo: They do not use the default swap.
</p>
<p>
Dave: Important for deduction in other types.
</p>
<p>
Alisdair: Would change the policy we adopted during FDIS mode.
</p>
<p>
Pablo: Keep it simple and get some vendor experience.
</p>
<p>
Alisdair: Is this wording correct? Concerned with bullet 2.
</p>
<p>
Pablo: Where does it reference containers section.
</p>
<p>
Alisdair: String is a container.
</p>
<p>
Alisdair: We should not remove redundancy piecemeal.
</p>
<p>
Pablo: I agree. This is a deviation from rest of string. Missing forward reference to containers section.
</p>
<p>
Pablo: To fix section 2. Only the note needs to be removed. The rest needs to be a forward reference to containers.
</p>
<p>
Alisdair: That is a new issue.
</p>
<p>
Pablo: Not really. Talking about adding one sentence, saying that basic string is a container.
</p>
<p>
Dave: That is not just a forward reference, it is a semantic change.
</p>
<p>
PJ: We intended to make it look like a container, but it did not satisfy all the requirements.
</p>
<p>
Pablo: Clause 1 is correct. Clause 2 is removing note and noexcept (do not remove the rest). Clause 3 is correct.
</p>
<p>
Alisdair: Not sure data() is correct (in clause 2).
</p>
<p>
Conclusion: Move to open, Alisdair and Pablo volunteered to provide wording
</p>

<p><i>[
originally proposed wording:
]</i></p>


<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>Modify the class template <tt>basic_string</tt> synopsis in 21.4 [basic.string]:</p>
<blockquote><pre>
namespace std {
  template&lt;class charT, class traits = char_traits&lt;charT&gt;,
    class Allocator = allocator&lt;charT&gt; &gt;
  class basic_string {
  public:
    [&hellip;]
    basic_string&amp; operator=(basic_string&amp;&amp; str) <del>noexcept</del>;
    [&hellip;]
    basic_string&amp; assign(basic_string&amp;&amp; str) <del>noexcept</del>;
    [&hellip;]
  };
}
</pre></blockquote>
</li>

<li><p>Remove the definition of the <tt>basic_string</tt> move assignment operator from 21.4.2 [string.cons] 
entirely, including Table 71 &mdash; <tt>operator=(const basic_string&lt;charT, traits, Allocator&gt;&amp;&amp;)</tt>.
This is consistent with how we define move assignment for the containers in Clause 23:</p>
<blockquote><pre>
<del>basic_string&lt;charT,traits,Allocator&gt;&amp;
operator=(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; str) noexcept;</del>
</pre><blockquote><p>
<del>-22- <i>Effects</i>: If <tt>*this</tt> and <tt>str</tt> are not the same object, modifies <tt>*this</tt> as shown 
in Table 71. [ <i>Note</i>: A valid implementation is <tt>swap(str)</tt>. &mdash; <i>end note</i> ]</del>
<p/>
<del>-23- If <tt>*this</tt> and <tt>str</tt> are the same object, the member has no effect.</del>
<p/>
<del>-24- <i>Returns</i>: <tt>*this</tt></del>
</p></blockquote></blockquote>
<blockquote>
<table border="1">
<caption><del>Table 71 &mdash; <tt>operator=(const basic_string&lt;charT, traits, Allocator&gt;&amp;&amp;)</tt></del></caption>

<tr>
<th><del>Element</del></th>
<th><del>Value</del></th>
</tr>

<tr>
<td><del><tt>data()</tt></del></td>
<td><del>points at the array whose first element was pointed
at by <tt>str.data()</tt></del></td>
</tr>

<tr>
<td><del><tt>size()</tt></del></td>
<td><del>previous value of <tt>str.size()</tt></del></td>
</tr>

<tr>
<td><del><tt>capacity()</tt></del></td>
<td><del>a value at least as large as <tt>size()</tt></del></td>
</tr>

</table> 
</blockquote>
</li>

<li><p>Modify the paragraphs prior to 21.4.6.3 [string::assign] p.3 as indicated (The
first insertion recommends a separate paragraph number for the indicated paragraph):</p>
<blockquote><pre>
basic_string&amp; assign(basic_string&amp;&amp; str) <del>noexcept</del>;
</pre><blockquote><p>
<ins>-?-</ins> <i>Effects</i>: <ins>Equivalent to <tt>*this = std::move(str)</tt>.</ins>
<del>The function replaces the string controlled by <tt>*this</tt> with a string of length 
<tt>str.size()</tt> whose elements are a copy of the string controlled by <tt>str</tt>. 
[ <i>Note</i>: A valid implementation is <tt>swap(str)</tt>. &mdash; <i>end note</i> ]</del>
<p/>
-3- <i>Returns</i>: <tt>*this</tt>
</p></blockquote></blockquote>

</li>
</ol>

<p><i>[
2012-08-11 Joe Gottman observes:
]</i></p>


<blockquote>
<p>
One of the effects of <tt>basic_string</tt>'s move-assignment operator (21.4.2 [string.cons], Table 71) is
</p>
<blockquote>

<table border="1">

<tr>
<th>Element</th>
<th>Value</th>
</tr>

<tr>
<td><tt>data()</tt></td>
<td>points at the array whose first element was pointed at by <tt>str.data()</tt></td>
</tr>

</table> 

</blockquote>
<p>
If a string implementation uses the small-string optimization and the input string <tt>str</tt> is small enough 
to make use of it, this effect is impossible to achieve. To use the small string optimization, a string has to 
be implemented using something like
</p>
<blockquote><pre>
union
{
   char buffer[SMALL_STRING_SIZE];
   char *pdata;
};
</pre></blockquote>
<p>
When the string is small enough to fit inside <tt>buffer</tt>, the <tt>data()</tt> member function returns 
<tt>static_cast&lt;const char *&gt;(buffer)</tt>, and since <tt>buffer</tt> is an array variable, there 
is no way to implement move so that the moved-to string's <tt>buffer</tt> member variable is equal to 
<tt>this->buffer</tt>.
<p/>
Resolution proposal:
<p/>
Change Table 71 to read:
</p>
<blockquote>

<table border="1">

<tr>
<th>Element</th>
<th>Value</th>
</tr>

<tr>
<td><tt>data()</tt></td>
<td>points at the array <del>whose first element was pointed at by <tt>str.data()</tt></del>
<ins>that contains the same characters in the same order as <tt>str.data()</tt> contained before 
<tt>operator=()</tt> was called</ins></td>
</tr>

</table> 

</blockquote>
<blockquote>
</blockquote>
</blockquote>




<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2070"></a>2070. <tt>allocate_shared</tt> should use <tt>allocator_traits&lt;A&gt;::construct</tt></h3>
<p><b>Section:</b> 20.8.2.2.6 [util.smartptr.shared.create] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-07-11 <b>Last modified:</b> 2014-05-02</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.8.2.2.6 [util.smartptr.shared.create] says:
</p>
<blockquote><p>
-2- <i>Effects</i>: Allocates memory suitable for an object of type <tt>T</tt> and constructs an object in that memory
via the placement new expression <tt>::new (pv) T(std::forward&lt;Args&gt;(args)...)</tt>. The template
<tt>allocate_shared</tt> uses a copy of a to allocate memory. If an exception is thrown, the functions have
no effect.
</p></blockquote>
<p>
This explicitly requires placement new rather than using
<tt>allocator_traits&lt;A&gt;::construct(a, (T*)pv, std::forward&lt;Args&gt;(args)...)</tt>
In most cases that would result in the same placement new expression,
but would allow more control over how the object is constructed e.g.
using <tt>scoped_allocator_adaptor</tt> to do uses-allocator construction, or
using an allocator declared as a friend to construct objects with no
public constructors.
</p>

<p><i>[
2011-08-16 Bloomington:
]</i></p>

<p>
Agreed to fix in principle, but believe that <tt>make_shared</tt> and
<tt>allocate_shared</tt> have now diverged enough that their descriptions
should be separated.  Pablo and Stefanus to provide revised wording.
</p>

<p><strong>Daniel's (old) proposed resolution:</strong></p>
<blockquote class="note">
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Change the following paragraphs of 20.8.2.2.6 [util.smartptr.shared.create] as indicated (The suggested
removal of the last sentence of p1 is not strictly required to resolve this issue, but is still recommended,
because it does not say anything new but may give the impression that it says something new):
</p><blockquote><pre>
template&lt;class T, class... Args&gt; shared_ptr&lt;T&gt; make_shared(Args&amp;&amp;... args);
template&lt;class T, class A, class... Args&gt;
  shared_ptr&lt;T&gt; allocate_shared(const A&amp; a, Args&amp;&amp;... args);
</pre><blockquote>
<p>
-1- <i>Requires</i>: <ins>For the template <tt>make_shared</tt>, t</ins><del>T</del>he expression 
<tt>::new (pv) T(std::forward&lt;Args&gt;(args)...)</tt>, where <tt>pv</tt> 
has type <tt>void*</tt> and points to storage suitable to hold an object of type <tt>T</tt>, shall be well 
formed. <ins>For the template <tt>allocate_shared</tt>, the expression 
<tt>allocator_traits&lt;A&gt;::construct(a, pt, std::forward&lt;Args&gt;(args)...)</tt>,
where <tt>pt</tt> has type <tt>T*</tt> and points to storage suitable to hold an object
of type <tt>T</tt>, shall be well formed.</ins> <tt>A</tt> shall be an allocator ([allocator.requirements]). 
<del>The copy constructor and destructor of  <tt>A</tt> shall not throw exceptions.</del>
<p/>
-2- <i>Effects</i>: Allocates memory suitable for an object of type <tt>T</tt> and constructs an object in 
that memory<ins>. The template <tt>make_shared</tt> constructs the object</ins> via the placement new expression 
<tt>::new (pv) T(std::forward&lt;Args&gt;(args)...)</tt>. The template <tt>allocate_shared</tt> uses a copy 
of <tt>a</tt> to allocate memory<ins> and constructs the object by calling <tt>allocator_traits&lt;A&gt;::construct(a, pt,
std::forward&lt;Args&gt;(args)...)</tt></ins>. If an exception is thrown, the functions have no effect.
<p/>
-3- <i>Returns</i>: A <tt>shared_ptr</tt> instance that stores and owns the address of the newly constructed 
object of type <tt>T</tt>.
<p/>
-4- <i>Postconditions</i>: <tt>get() != 0 &amp;&amp; use_count() == 1</tt>
<p/>
-5- <i>Throws</i>: <tt>bad_alloc</tt>, or<ins>, for the template <tt>make_shared</tt>, an exception thrown from
the constructor of <tt>T</tt>, or, for the template <tt>allocate_shared</tt>,</ins> an exception thrown from 
<tt>A::allocate</tt> or <ins>from <tt>allocator_traits&lt;A&gt;::construct</tt></ins><del>from the constructor of 
<tt>T</tt></del>.
<p/>
-6- <i>Remarks</i>: Implementations are encouraged, but not required, to perform no more than one memory
allocation. [ <i>Note</i>: This provides efficiency equivalent to an intrusive smart pointer. &mdash; <i>end note</i> ]
<p/>
-7- [ <i>Note</i>: These functions will typically allocate more memory than <tt>sizeof(T)</tt> to allow for internal
bookkeeping structures such as the reference counts. &mdash; <i>end note</i> ]
</p>
</blockquote></blockquote>
</li>
</ol>
</blockquote>

<p><i>[2011-12-04: Jonathan and Daniel improve wording]</i></p>


<p>See also c++std-lib-31796</p>




<p><i>[2013-10-13, Ville]</i></p>

<p>
This issue is related to <a href="lwg-active.html#2089">2089</a>.
</p>


<p><i>[2014-02-15 post-Issaquah session : move to Tentatively NAD]</i></p>

<p>
STL: This takes an allocator, but then ignores its construct. That's squirrely.
</p>
<p>
Alisdair: The convention is when you take an allocator, you use its construct.
</p>
<p>
STL: 23.2.1 [container.requirements.general]/3, argh! This fills me with despair, but I understand it now.
</p>
<p>
STL: Ok, this is some cleanup.
</p>
<p>
STL: You're requiring <tt>b</tt> to be of type <tt>A</tt> and not being rebound, is that an overspecification?
</p>
<p>
Pablo: Good point. Hmm, that's only a requirement on what must be well-formed.
</p>
<p>
STL: If it's just a well-formed requirement, then why not just use a directly?
</p>
<p>
Pablo: Yeah, the well-formed requirement is overly complex. It's not a real call, we could just use a directly. It makes it harder to read.
</p>
<p>
Alisdair: <tt>b</tt> should be an allocator in the same family as <tt>a</tt>.
</p>
<p>
Pablo: This is a well-formed requirement, I wonder if it's the capital A that's the problem here. It doesn't matter here, this is way too much wording.
</p>
<p>
Alisdair: It's trying to tie the constructor arguments into the allocator requirements.
</p>
<p>
Pablo: <tt>b</tt> could be struck, that's a runtime quality. The construct will work with anything that's in the family of <tt>A</tt>.
</p>
<p>
Alisdair: The important part is the <tt>forward</tt> of <tt>Args</tt>.
</p>
<p>
Pablo: <tt>A</tt> must be an allocator, and <tt>forward</tt> <tt>Args</tt> must work with that.
</p>
<p>
Alisdair: First let's nail down <tt>A</tt>.
</p>
<p>
Pablo: Then replace <tt>b</tt> with <tt>a</tt>, and strike the rest.
</p>
<p>
STL: You need <tt>pt</tt>'s type, at least.
</p>
<p>
Pablo: There's nothing to be said about runtime constraints here, this function doesn't even take a <tt>pt</tt>.
</p>
<p>
STL: Looking at the Effects, I believe <tt>b</tt> is similarly messed up, we can use <tt>a2</tt> to construct an object.
</p>
<p>
Alisdair: Or any allocator in the family of <tt>a</tt>.
</p>
<p>
STL: We say this stuff for the deallocate too, it should be lifted up.
</p>
<p>
STL: "owns the address" is weird.
</p>
<p>
Alisdair: shared_ptr owns pointers, although it does sound funky.
</p>
<p>
Walter: "to destruct" is ungrammatical.
</p>
<p>
STL: "When ownership is given up" is not what we usually say.
</p>
<p>
Alisdair: I think the Returns clause is the right place to say this.
</p>
<p>
STL: The right place to say this is <tt>shared_ptr</tt>'s dtor, we don't want to use Core's "come from" convention.
</p>
<p>
Alisdair: I'm on the hook to draft cleaner wording.
</p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Change the following paragraphs of 20.8.2.2.6 [util.smartptr.shared.create] as indicated:
</p>
<blockquote><pre>
template&lt;class T, class... Args&gt; shared_ptr&lt;T&gt; make_shared(Args&amp;&amp;... args);
<del>template&lt;class T, class A, class... Args&gt;
  shared_ptr&lt;T&gt; allocate_shared(const A&amp; a, Args&amp;&amp;... args);</del>
</pre></blockquote>
<p>
<del>-1- <i>Requires</i>: The expression <tt>::new (pv) T(std::forward&lt;Args&gt;(args)...)</tt>, where <tt>pv</tt> 
has type <tt>void*</tt> and points to storage suitable to hold an object of type <tt>T</tt>, shall be well 
formed. <tt>A</tt> shall be an allocator (17.6.3.5 [allocator.requirements]). The copy constructor 
and destructor of <tt>A</tt> shall not throw exceptions.</del>
<p/>
-2- <i>Effects</i>: <ins>Equivalent to</ins>
</p>
<blockquote><pre> 
<ins>return allocate_shared&lt;T&gt;(allocator&lt;T&gt;(), std::forward&lt;Args&gt;(args)...);</ins>
</pre></blockquote>
<p>
<del>Allocates memory suitable for an object of type <tt>T</tt> 
and constructs an object in that memory via the placement new expression 
<tt>::new (pv) T(std::forward&lt;Args&gt;(args)...)</tt>. The template <tt>allocate_shared</tt> uses a copy 
of <tt>a</tt> to allocate memory. If an exception is thrown, the functions have no effect.</del>
<p/>
<ins>-?- <i>Remarks</i>: An implementation may meet the effects (and the implied guarantees) without 
creating the allocator object [<i>Note</i>: That is, user-provided specializations of <tt>std::allocator</tt>
may not be instantiated, the expressions <tt>::new (pv) T(std::forward&lt;Args&gt;(args)...)</tt> and 
<tt>pv-&gt;~T()</tt> may be evaluated directly &mdash; <i>end note</i>].</ins>
<p/>
<del>-3- <i>Returns</i>: A <tt>shared_ptr</tt> instance that stores and owns the address of the newly constructed 
object of type <tt>T</tt>.</del>
<p/>
<del>-4- <i>Postconditions</i>: <tt>get() != 0 &amp;&amp; use_count() == 1</tt></del>
<p/>
<del>-5- <i>Throws</i>: <tt>bad_alloc</tt>, or an exception thrown from <tt>A::allocate</tt> or from the 
constructor of <tt>T</tt>.</del>
<p/>
<del>-6- <i>Remarks</i>: Implementations are encouraged, but not required, to perform no more than one memory
allocation. [<i>Note</i>: This provides efficiency equivalent to an intrusive smart pointer. &mdash; <i>end note</i>]</del>
<p/>
<del>-7- [<i>Note</i>: These functions will typically allocate more memory than <tt>sizeof(T)</tt> to allow 
for internal bookkeeping structures such as the reference counts. &mdash; <i>end note</i>]</del>
</p>
</li>
<li><p>
Add the following set of <ins>new paragraphs</ins> immediately following the previous paragraph 7 of
20.8.2.2.6 [util.smartptr.shared.create]:
</p>
<blockquote><pre>
template&lt;class T, class A, class... Args&gt;
  shared_ptr&lt;T&gt; allocate_shared(const A&amp; a, Args&amp;&amp;... args);
</pre></blockquote>
<p>
-?- <i>Requires</i>: The expressions 
<tt>allocator_traits&lt;A&gt;::construct(b, pt, std::forward&lt;Args&gt;(args)...)</tt> and
<tt>allocator_traits&lt;A&gt;::destroy(b, pt)</tt> shall be well-formed and well-defined, 
where <tt>b</tt> has type <tt>A</tt> and is a copy of <tt>a</tt> and where <tt>pt</tt> 
has type <tt>T*</tt> and points to storage suitable to hold an object of type <tt>T</tt>. 
<tt>A</tt> shall meet the allocator requirements (17.6.3.5 [allocator.requirements]). 
<p/>
-?- <i>Effects</i>: Uses an object <tt>a2</tt> 
of type <tt>allocator_traits&lt;A&gt;::rebind_alloc&lt;<i>unspecified</i>&gt;</tt> that compares equal to 
<tt>a</tt> to allocate memory suitable for an object of type <tt>T</tt>. 
Uses a copy <tt>b</tt> of type <tt>A</tt> from <tt>a</tt> to construct an object of type <tt>T</tt> in 
that memory by calling <tt>allocator_traits&lt;A&gt;::construct(b, pt, std::forward&lt;Args&gt;(args)...)</tt>. 
If an exception is thrown, the function has no effect.
<p/>
-?- <i>Returns</i>: A <tt>shared_ptr</tt> instance that stores and owns the address of the newly constructed 
object of type <tt>T</tt>. When ownership is given up, the effects are as follows: Uses a copy <tt>b2</tt> 
of type <tt>A</tt> from <tt>a</tt> to destruct an object of type <tt>T</tt> by calling 
<tt>allocator_traits&lt;A&gt;::destroy(b2, pt2)</tt> where <tt>pt2</tt> has type <tt>T*</tt> 
and refers to the newly constructed object. Then uses an object of type
<tt>allocator_traits&lt;A&gt;::rebind_alloc&lt;<i>unspecified</i>&gt;</tt> that compares equal to 
<tt>a</tt> to deallocate the allocated memory.
<p/>
-?- <i>Postconditions</i>: <tt>get() != 0 &amp;&amp; use_count() == 1</tt>
<p/>
-?- <i>Throws</i>: Nothing unless memory allocation or <tt>allocator_traits&lt;A&gt;::construct</tt> 
throws an exception.
<p/>
-?- <i>Remarks</i>: Implementations are encouraged, but not required, to perform no more than one memory 
allocation. [<i>Note</i>: Such an implementation provides efficiency equivalent to an intrusive smart 
pointer. &mdash; <i>end note</i>]
<p/>
-?- [<i>Note</i>: This function will typically allocate more memory than <tt>sizeof(T)</tt> to allow for internal
bookkeeping structures such as the reference counts. &mdash; <i>end note</i>]
</p>
</li>
</ol>





<hr>
<h3><a name="2072"></a>2072. Unclear wording about capacity of temporary buffers</h3>
<p><b>Section:</b> 20.7.11 [temporary.buffer] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Kazutoshi Satoda <b>Opened:</b> 2011-08-10 <b>Last modified:</b> 2014-05-23</p>
<p><b>View all other</b> <a href="lwg-index.html#temporary.buffer">issues</a> in [temporary.buffer].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
According to 20.7.11 [temporary.buffer] p1+2:

</p><blockquote><pre>
template &lt;class T&gt;
pair&lt;T*, ptrdiff_t&gt; get_temporary_buffer(ptrdiff_t n) noexcept;
</pre><blockquote><p>
-1- <i>Effects</i>: Obtains a pointer to storage sufficient to store up to <tt>n</tt> adjacent <tt>T</tt> 
objects. It is implementation-defined whether over-aligned types are supported (3.11).
<p/>
-2- <i>Returns</i>: A pair containing the buffer's address and capacity (in the units of <tt>sizeof(T)</tt>), 
or a pair of 0 values if no storage can be obtained or if <tt>n &lt;= 0</tt>.
</p></blockquote></blockquote>
<p>
I read this as prohibiting to return a buffer of which capacity is less than <tt>n</tt>, because 
such a buffer is not sufficient to store <tt>n</tt> objects.
<p/>
The corresponding description in <a href="http://www.sgi.com/tech/stl/get_temporary_buffer.html">SGI STL</a> 
is clear on this point, but I think it is a bit too verbose:
</p>

<blockquote class="note"><p>
(for the return value, a pair <tt>P</tt>) [...] the buffer pointed to by <tt>P.first</tt> is large enough 
to hold <tt>P.second</tt> objects of type <tt>T</tt>. <tt>P.second</tt> is greater than or equal to 0, 
and less than or equal to <tt>len</tt>.
</p></blockquote>

<p>
There seems to be two different targets of the "up to n" modification:
The capacity of obtained buffer, and the actual number that the caller
will store into the buffer.
<p/>
First I read as the latter, and got surprised seeing that libstdc++
implementation can return a smaller buffer. I started searching about
<tt>get_temporary_buffer()</tt>. After reading a quote from TC++PL at
<a href="http://stackoverflow.com/questions/3264299/why-do-i-need-stdget-temporary-buffer">stackoverflow</a>, 
I realized that the former is intended.
<p/>
Such misinterpretation seems common:
</p>
<ul>
<li>The above question is likely started from same misinterpretation.</li>
<li><p>JIS standard (Japanese translation of ISO&#47;IEC standard) says nothing
    like "up to". I think the editor misinterpreted the original wording,
    and omitted words for "up to" as it is redundant. (If a buffer is
    sufficient to store <tt>n</tt> objects, it is also sufficient to store
    up to <tt>n</tt> objects.)</p></li>
<li><p>Rogue Wave implementation doesn't return smaller buffer, instead, it
    can return larger buffer on some circumstances. Apache 
	<a href="http://stdcxx.apache.org/">STDCXX</a> is a derived version of that
    implementation, and <a href="https://stdcxx.apache.org/doc/stdlibref/get-temporary-buffer.html">publicly accessible</a>:
</p>
<blockquote class="note"><p>
Specializations of the <tt>get_temporary_buffer()</tt> function template
attempt to allocate a region of storage sufficiently large to store at
least <tt>n</tt> adjacent objects of type <tt>T</tt>.
</p></blockquote>
<p>
I know one commercial compiler package based on Rogue Wave implementation, 
and its implementation is essentially same as the above.
</p>
</li>
</ul>

<p><i>[2014-05-18, Daniel comments and suggests concrete wording]</i></p>


<p>
The provided wording attempts to clarify the discussed capacity freedom, but it also makes it clearer that the returned
memory is just "raw memory", which is currently not really clear. In addition the wording clarifies that the deallocating
<tt>return_temporary_buffer</tt> function does not throw exceptions, which I believe is the intention when the preconditions
of the functions are satisfied. Then, my understanding is that we can provide to <tt>return_temporary_buffer</tt> a
null pointer value if that was the value, <tt>get_temporary_buffer()</tt> had returned. Furthermore, as STL noticed, the current 
wording seemingly allows multiple invocations of <tt>return_temporary_buffer</tt> with the same value returned by 
<tt>get_temporary_buffer</tt>; this should be constrained similar to the wording we have for <tt>operator delete</tt> (unfortunately
we miss such wording for allocators).
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol><li><p>Change 20.7.11 [temporary.buffer] as indicated:</p>

<blockquote>
<pre>
template &lt;class T&gt;
  pair&lt;T*, ptrdiff_t&gt; get_temporary_buffer(ptrdiff_t n) noexcept;
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: <ins>Obtains a pointer to uninitialized, contiguous storage for <tt><i>N</i></tt> adjacent objects of type 
<tt>T</tt>, for some non-negative number <tt><i>N</i></tt>.</ins><del>Obtains a pointer to storage sufficient 
to store up to <tt>n</tt> adjacent <tt>T</tt> objects.</del> It is implementation-defined whether over-aligned types are supported (3.11).
<p/>
<ins>-?- <i>Remarks</i>: Calling <tt>get_temporary_buffer</tt> with a positive number <tt>n</tt> is a non-binding request to return 
storage for <tt>n</tt> objects of type <tt>T</tt>. In this case, an implementation is permitted to return instead storage for a 
non-negative number <tt><i>N</i></tt> of such objects, where <tt><i>N</i> != n</tt> (including <tt><i>N</i> == 0</tt>). [<i>Note</i>: The 
request is non-binding to allow latitude for implementation-specific optimizations of its memory management. &mdash; <i>end note</i>].</ins>
<p/>
-2- <i>Returns</i>: <ins>If <tt>n &lt;= 0</tt> or if no storage could be obtained, returns a pair <tt>P</tt> such that <tt>P.first</tt>
is a null pointer value and <tt>P.second == 0</tt>; otherwise returns a pair <tt>P</tt> such that <tt>P.first</tt> refers to the 
address of the uninitialized storage and <tt>P.second</tt> refers to its capacity <tt><i>N</i></tt> (in the units of 
<tt>sizeof(T)</tt>).</ins><del>A <tt>pair</tt> containing the buffer's address and capacity (in the units of <tt>sizeof(T)</tt>), or a 
pair of 0 values if no storage can be obtained or if <tt>n &lt;= 0</tt>.</del>
</p>
</blockquote>

<pre>
template &lt;class T&gt; void return_temporary_buffer(T* p);
</pre>
<blockquote>
<p>
-3- <i>Effects</i>: Deallocates the <del>buffer to which <tt>p</tt> points</del><ins>storage referenced by <tt>p</tt></ins>.
<p/>
-4- <i>Requires</i>: <del>The buffer shall have been previously allocated by</del><ins><tt>p</tt> shall be a pointer value 
returned by an earlier call to</ins> <tt>get_temporary_buffer</tt> <ins>which has not been invalidated by an intervening call to
<tt>return_temporary_buffer(T*)</tt></ins>.
<p/>
<ins>-?- <i>Throws</i>: Nothing.</ins>
</p>
</blockquote>

</blockquote>
</li>
</ol>






<hr>
<h3><a name="2076"></a>2076. Bad <tt>CopyConstructible</tt> requirement in set constructors</h3>
<p><b>Section:</b> 23.4.6.2 [set.cons] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2011-08-20 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
23.4.6.2 [set.cons] paragraph 4 says: 
</p>

<blockquote><p>
<i>Requires</i>: If the iterator's dereference operator returns an lvalue or a non-const rvalue, 
then <tt>Key</tt> shall be <tt>CopyConstructible</tt>.
</p></blockquote>

<p>
I'm confused why a "non-const rvalue" for the return value of the iterator
would require <tt>CopyConstructible</tt>; isn't that exactly the situation 
when you'd want to apply the move constructor?
<p/>
The corresponding requirement for <tt>multimap</tt> seems better in that regard
([multimap.cons] paragraph 3):
</p>
<blockquote><p>
Requires: If the iterator's dereference operator returns an lvalue or a const rvalue 
<tt>pair&lt;key_type, mapped_type&gt;</tt>, then both <tt>key_type</tt> and mapped_type 
shall be <tt>CopyConstructible</tt>.
</p></blockquote>
<p>
Obviously, if I have a const rvalue, I can't apply the move constructor (which will 
likely attempt modify its argument).
<p/>
Dave Abrahams:
<p/>
I think you are right.
Proposed resolution: drop "non-" from 23.4.6.2 [set.cons] paragraph 3.
</p>

<p><i>[2012, Kona]</i></p>

<p>
The wording is in this area will be affected by Pablo's paper being adopted at this meeting.
Wait for that paper to be applied before visiting this issue - deliberately leave in New
status until the next meeting.
</p>

<p><strong>Proposed resolution from Kona 2012:</strong></p>
<blockquote class="note">
<p>This wording is relative to the FDIS.</p>

<p>
Change 23.4.6.2 [set.cons] p3 as follows:
</p> 
<blockquote><pre>
template &lt;class InputIterator&gt;
  set(InputIterator first, InputIterator last,
    const Compare&amp; comp = Compare(), const Allocator&amp; = Allocator());
</pre><blockquote><p>
-3- Effects: Constructs an empty set using the specified comparison object and allocator, and inserts
elements from the range [<tt>first,last</tt>).
<p/>
-4- <i>Requires</i>: If the iterator's dereference operator returns an lvalue or a <del>non-</del>const rvalue, 
then <tt>Key</tt> shall be <tt>CopyConstructible</tt>.
<p/>
-5- <i>Complexity</i>: Linear in <tt>N</tt> if the range [<tt>first,last</tt>) is already sorted using 
<tt>comp</tt> and otherwise <tt>N logN</tt>, where <tt>N</tt> is <tt>last - first</tt>.
</p></blockquote></blockquote>
</blockquote>

<p><i>[2014-05-18, Daniel comments]</i></p>

<p>
According to Pablo, the current P/R correctly incorporates the changes from his paper (which was adopted in Kona)
</p>

<p><i>[2014-06-10, STL comments and suggests better wording]</i></p>

<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html">N1858</a> was voted into WP 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a> but was 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2283.html">"(reworded)"</a>, introducing the "non-const" damage.
<p/>
N1858 wanted to add this for map:
</p>
<blockquote><p>
<i>Requires</i>: Does not require <tt>CopyConstructible</tt> of either <tt>key_type</tt> or <tt>mapped_type</tt> if the dereferenced 
<tt>InputIterator</tt> returns a non-const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>. Otherwise <tt>CopyConstructible</tt> 
is required for both <tt>key_type</tt> and <tt>mapped_type</tt>.
</p></blockquote>
<p>
And this for set:
</p>
<blockquote><p>
<i>Requires</i>: <tt>Key</tt> must be <tt>CopyConstructible</tt> only if the dereferenced <tt>InputIterator</tt> returns an lvalue 
or const rvalue.
</p></blockquote>
<p>
(And similarly for multi.)
<p/>
This was reworded to N2284 23.3.1.1 [map.cons]/3 and N2284 23.3.3.1 [set.cons]/4, and it slightly changed over the years into 
N3936 23.4.4.2 [map.cons]/3 and N3936 23.4.6.2 [set.cons]/4.
<p/>
In 2005/2007, this was the best known way to say "hey, we should try to move this stuff", as the fine-grained element requirements 
were taking shape.
<p/>
Then in 2010, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3173.pdf">N3173</a> was 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3226.html">voted</a> into WP 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3225.pdf">N3225</a>, adding the definition of 
<tt>EmplaceConstructible</tt> and modifying the container requirements tables to make the range constructors require 
<tt>EmplaceConstructible</tt>.
<p/>
After looking at this history and double-checking our implementation (where <tt>map</tt>/<tt>set</tt> range construction goes through 
emplacement, with absolutely no special-casing for <tt>map</tt>'s pairs), I am convinced that N3173 superseded N1858 here. 
(Range-<tt>insert()</tt> and the unordered containers are unaffected.)
</p>

<p>
<strong>Previous resolution [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to the N3936.</p>

<p>
Change 23.4.6.2 [set.cons] p4 as follows:
</p> 
<blockquote><pre>
template &lt;class InputIterator&gt;
  set(InputIterator first, InputIterator last,
    const Compare&amp; comp = Compare(), const Allocator&amp; = Allocator());
</pre><blockquote><p>
-3- Effects: Constructs an empty <tt>set</tt> using the specified comparison object and allocator, and inserts
elements from the range [<tt>first,last</tt>).
<p/>
-4- <i>Requires</i>: If the iterator's indirection operator returns an lvalue or a <del>non-</del>const rvalue, 
then <tt>Key</tt> shall be <tt>CopyInsertible</tt> into <tt>*this</tt>.
<p/>
-5- <i>Complexity</i>: Linear in <tt>N</tt> if the range [<tt>first,last</tt>) is already sorted using 
<tt>comp</tt> and otherwise <tt>N logN</tt>, where <tt>N</tt> is <tt>last - first</tt>.
</p></blockquote></blockquote>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the N3936.</p>

<ol>
<li><p>
Remove 23.4.4.2 [map.cons] p3:
</p> 
<blockquote><pre>
template &lt;class InputIterator&gt;
  map(InputIterator first, InputIterator last,
      const Compare&amp; comp = Compare(), const Allocator&amp; = Allocator());
</pre><blockquote>
<p>
<del>-3- <i>Requires</i>: If the iterator's indirection operator returns an lvalue or a <tt>const</tt> rvalue
<tt>pair&lt;key_type, mapped_type&gt;</tt>, then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be 
<tt>CopyInsertible</tt> into <tt>*this</tt>.</del>
<p/>
[&hellip;]
</p></blockquote></blockquote>
</li>

<li><p>
Remove 23.4.5.2 [multimap.cons] p3:
</p> 
<blockquote><pre>
template &lt;class InputIterator&gt;
  multimap(InputIterator first, InputIterator last,
           const Compare&amp; comp = Compare(), 
           const Allocator&amp; = Allocator());
</pre><blockquote>
<p>
<del>-3- <i>Requires</i>: If the iterator's indirection operator returns an lvalue or a <tt>const</tt> rvalue
<tt>pair&lt;key_type, mapped_type&gt;</tt>, then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be 
<tt>CopyInsertible</tt> into <tt>*this</tt>.</del>
<p/>
[&hellip;]
</p>
</blockquote></blockquote>
</li>

<li><p>
Remove 23.4.6.2 [set.cons] p4:
</p> 
<blockquote><pre>
template &lt;class InputIterator&gt;
  set(InputIterator first, InputIterator last,
      const Compare&amp; comp = Compare(), const Allocator&amp; = Allocator());
</pre><blockquote>
<p>
[&hellip;]
<p/>
<del>-4- <i>Requires</i>: If the iterator's indirection operator returns an lvalue or a non-<tt>const</tt> rvalue, then 
<tt>Key</tt> shall be <tt>CopyInsertible</tt> into <tt>*this</tt>.</del>
</p></blockquote></blockquote>
</li>

<li><p>
Remove 23.4.7.2 [multiset.cons] p3:
</p> 
<blockquote><pre>
template &lt;class InputIterator&gt;
  multiset(InputIterator first, InputIterator last,
           const Compare&amp; comp = Compare(), 
           const Allocator&amp; = Allocator());
</pre><blockquote>
<p>
<del>-3- <i>Requires</i>: If the iterator's indirection operator returns an lvalue or a <tt>const</tt> rvalue, then 
<tt>Key</tt> shall be <tt>CopyInsertible</tt> into <tt>*this</tt>.</del>
<p/>
[&hellip;]
</p></blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="2077"></a>2077. Further incomplete constraints for type traits</h3>
<p><b>Section:</b> 20.10.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-08-20 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The currently agreed on proposed wording for <a href="lwg-defects.html#2015">2015</a> using 
<tt>remove_all_extents&lt;T&gt;::type</tt> instead of the "an array of 
unknown bound" terminology in the precondition should be extended to 
some further entries especially in Table 49, notably the 
<tt>is_*constructible</tt>, <tt>is_*assignable</tt>, and 
<tt>is_*destructible</tt> entries. To prevent ODR violations, incomplete
element types of arrays must be excluded for value-initialization and
destruction for example. Construction and assignment has to be honored, 
when we have array-to-pointer conversions or pointer conversions of
incomplete pointees in effect.
</p>

<p><i>[2012, Kona]</i></p>

<p>
The issue is that in three type traits, we are accidentally saying that in certain
circumstances the type must give a specified answer when given an incomplete type.
(Specifically: an array of unknown bound of incomplete type.)  The issue asserts
that there's an ODR violation, since the trait returns false in that case but might
return a different version when the trait is completed.
</p>
<p>
Howard argues: no, there is no risk of an ODR violation.
<tt>is_constructible&lt;A[]></tt> must return <tt>false</tt> regardless of whether
<tt>A</tt> is complete, so there's no reason to forbid an array of unknown bound of
incomplete types. Same argument applies to <tt>is_assignable</tt>. General agreement
with Howard's reasoning.
</p>
<p>
There may be a real issue for <tt>is_destructible</tt>. None of us are sure what
<tt>is_destructible</tt> is supposed to mean for an array of unknown bound
(regardless of whether its type is complete), and the standard doesn't make it clear.
The middle column doesn't say what it's supposed to do for incomplete types.
</p>
<p>
In at least one implementation, <tt>is_destructible&lt;A[]></tt> does return <tt>true</tt>
if <tt>A</tt> is complete, which would result in ODR violation unless we forbid it for
incomplete types.
</p>
<p>
Move to open. We believe there is no issue for <tt>is_constructible</tt> or
<tt>is_assignable</tt>, but that there is a real issue for <tt>is_destructible</tt>.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2079"></a>2079. Required <tt>pow()</tt> overloads</h3>
<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2011-08-29 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
<p><b>View all other</b> <a href="lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
LWG issue <a href="lwg-defects.html#550">550</a> removed the functions:
</p>
<blockquote><pre>
float       pow(float, int);
double      pow(double, int);
long double pow(long double, int);
</pre></blockquote>
<p>
from header <tt>&lt;cmath&gt;</tt>. This change does not seem to be mentioned in Annex C, C.2.14.
<p/>
Howard:
</p>
<blockquote><p>
N3290 26.8 [c.math]&#47;p11 says:
</p><blockquote>
<p>
Moreover, there shall be additional overloads sufficient to ensure:
</p>
<ol>
<li>If any argument corresponding to a <tt>double</tt> parameter has type <tt>long double</tt>, 
then all arguments corresponding to <tt>double</tt> parameters are effectively cast to 
<tt>long double</tt>.
</li>
<li>Otherwise, if any argument corresponding to a <tt>double</tt> parameter has type <tt>double</tt> 
or an integer type, then all arguments corresponding to <tt>double</tt> parameters are effectively 
cast to <tt>double</tt>.
</li>
<li>Otherwise, all arguments corresponding to <tt>double</tt> parameters are effectively cast to 
<tt>float</tt>.
</li>
</ol>
</blockquote>
<p>
From C99 7.12.7.4 we have:
</p>
<blockquote><pre>
double pow(double, double);
</pre></blockquote>
<p>
26.8 [c.math]&#47;p11&#47;b2 says that if the client calls <tt>pow(2.0f, 2)</tt>, then the 
<tt>int</tt> for second argument causes the following effective call to be made:
</p>
<blockquote><pre>
pow(static_cast&lt;double&gt;(2.0f), static_cast&lt;double&gt;(2)) -&gt; double
</pre></blockquote>
<p>
The first sentence of p11 implies that this is done by supplying the following additional overload:
</p>
<blockquote><pre>
double pow(float, int);
</pre></blockquote>
<p>
If the client calls <tt>pow(2.0, 2)</tt>, then the same reasoning (b2 again) implies the following 
additional overload:
</p>
<blockquote><pre>
double pow(double, int);
</pre></blockquote>
<p>
If the client calls <tt>pow(2.0l, 2)</tt>, then b1 implies the following additional overload:
</p>
<blockquote><pre>
long double pow(long double, int);
</pre></blockquote>
<p>
In all, p11 implies hundreds (perhaps thousands?) of extra overloads.  All but one of which is a superset 
of the overloads required by C++98&#47;03 (that one being <tt>pow(float, int)</tt> which had its return 
type changed from <tt>float</tt> to <tt>double</tt>).
<p/>
In practice, at least some vendors implement p11 by using templated overloads as opposed to ordinary overloads.
</p></blockquote>

<p>
Steve Clamage:
</p>
<blockquote><p>
Thanks. I didn't see that those extra overloads were actually implied by p11, despite the first sentence. 
Without examples, the point is a bit subtle (at least for me).
</p></blockquote>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2088"></a>2088. <tt>std::terminate</tt> problem</h3>
<p><b>Section:</b> 18.8.3 [exception.terminate] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-09-25 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Andrzej Krzemienski reported the following on comp.std.c++:
</p>
<blockquote>
<p>
In N3290, which is to become the official standard, in 18.8.3.4 [terminate],
paragraph 1 reads
</p>
<blockquote><p>
<i>Remarks</i>: Called by the implementation when exception handling must
be abandoned for any of several reasons (15.5.1), in effect immediately after 
evaluating the <em>throw-expression</em> (18.8.3.1). May also be called directly by the 
program.
</p></blockquote>
<p>It is not clear what is "in effect". It was clear in previous drafts where paragraphs 
1 and 2 read:
</p>
<blockquote><p>
Called by the implementation when exception handling must be
abandoned for any of several reasons (15.5.1). May also be called directly
by the program.
<p/>
<i>Effects</i>: Calls the <tt>terminate_handler</tt> function in effect
immediately after evaluating the <em>throw-expression</em> (18.8.3.1), if called by the
implementation, or calls the current <tt>terminate_handler</tt> function,
if called by the program.
</p>
</blockquote>
<p>
It was changed by N3189. The same applies to function unexpected (D. 11.4, paragraph 1).
<p/>
Assuming the previous wording is still intended, the wording can be read
"unless <tt>std::terminate</tt> is called by the program, we will use the handler
that was in effect immediately after evaluating the throw-expression".
<p/>
  This assumes that there is some throw-expression connected to every
  situation that triggers the call to <tt>std::terminate</tt>. But this is not
  the case:
</p>
<ul>
<li>
  In case <tt>std::thread</tt> is assigned to or destroyed while being joinable
  there is no throw-expression involved.
</li>
<li>
  In case <tt>std::unexpected</tt> is called by the program, <tt>std::terminate</tt> is
  triggered by the implementation - no throw-expression involved.
</li>
<li>
  In case a destructor throws during stack unwinding we have two throw-expressions 
  involved.
 </li>
 </ul>
<p>
Which one is referred to?
<p/>
In case <tt>std::nested_exception::rethrow_nested</tt> is called for an object that has 
captured no exception, there is no throw-expression involved directly (and may no throw 
be involved even indirectly).
<p/>
Next, 18.8.3.1 [terminate.handler], paragraph 2 says 
</p>
<blockquote><p>
<i>Required behavior</i>: A <tt>terminate_handler</tt> shall terminate execution
of the program without returning to the caller.
</p></blockquote>
<p>
This seems to allow that the function may exit by throwing an
exception (because word "return" implies a normal return).
<p/>
One could argue that words "terminate execution of the program" are sufficient,
but then why "without returning to the caller" would be mentioned. In
case such handler throws, noexcept specification in function <tt>std::terminate</tt> 
is violated, and <tt>std::terminate</tt> would be called recursively - should 
<tt>std::abort</tt> not be called in case of recursive <tt>std::terminate</tt> 
call? On the other hand some controlled recursion could be useful, like in the 
<a href="http://cplusplus.co.il/2010/03/21/catching-uncaught-exceptions-within-terminate/">following technique</a>.
</p>
</blockquote>

<p>
The here mentioned wording changes by N3189 in regard to 18.8.3.4 [terminate] p1 
were done for a better separation of effects (Effects element) and additional normative 
wording explanations (Remarks element), there was no meaning change intended. Further,
there was already a defect existing in the previous wording, which was not updated when 
further situations where defined, when <tt>std::terminate</tt> where supposed to be 
called by the implementation. 
<p/>
The part
<p/>
"in effect immediately after evaluating the throw-expression"
<p/>
should be removed and the quoted reference to 18.8.3.1 [terminate.handler] 
need to be part of the effects element where it refers to the current <tt>terminate_handler</tt> 
function, so should be moved just after
<p/>
"Effects: Calls the current <tt>terminate_handler</tt> function."
<p/>
It seems ok to allow a termination handler to exit via an exception, but the 
suggested idiom should better be replaced by a more simpler one based on
evaluating the current exception pointer in the terminate handler, e.g.
</p>
<blockquote><pre>
void our_terminate (void) {
  std::exception_ptr p = std::current_exception();
  if (p) {
    ... // OK to rethrow and to determine it's nature
  } else {
    ... // Do something else
  }
}
</pre></blockquote>

<p><i>[2011-12-09: Daniel comments]</i></p>


<p>
A related issue is <a href="lwg-active.html#2111">2111</a>.
</p>


<p><i>[2012, Kona]</i></p>

<p>
Move to Open.
</p>
<p>
There is an interaction with Core issues in this area that Jens is already supplying wording
for.  Review this issue again once Jens wording is available.
</p>
<p>
Alisdair to review clause 15.5 (per Jens suggestion) and recommend any changes, then integrate
Jens wording into this issue.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2089"></a>2089. <tt>std::allocator::construct</tt> should use uniform initialization</h3>
<p><b>Section:</b> 20.7.9.1 [allocator.members] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> David Krauss <b>Opened:</b> 2011-10-07 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
When the <tt>EmplaceConstructible</tt> (23.2.1 [container.requirements.general]&#47;13) requirement is used 
to initialize an object, direct-initialization occurs. Initializing an aggregate or using a <tt>std::initializer_list</tt> 
constructor with emplace requires naming the initialized type and moving a temporary. This is a result of 
<tt>std::allocator::construct</tt> using direct-initialization, not list-initialization (sometimes called "uniform 
initialization") syntax.
<p/>
Altering <tt>std::allocator&lt;T&gt;::construct</tt> to use list-initialization would, among other things, give 
preference to <tt>std::initializer_list</tt> constructor overloads, breaking valid code in an unintuitive and 
unfixable way &mdash; there would be no way for <tt>emplace_back</tt> to access a constructor preempted by 
<tt>std::initializer_list</tt> without essentially reimplementing <tt>push_back</tt>.
</p>
<blockquote><pre>
std::vector&lt;std::vector&lt;int&gt;&gt; v;
v.emplace_back(3, 4); // v[0] == {4, 4, 4}, not {3, 4} as in list-initialization
</pre></blockquote>
<p>
The proposed compromise is to use SFINAE with <tt>std::is_constructible</tt>, which tests whether direct-initialization 
is well formed. If <tt>is_constructible</tt> is false, then an alternative <tt>std::allocator::construct</tt> overload 
is chosen which uses list-initialization. Since list-initialization always falls back on direct-initialization, the 
user will see diagnostic messages as if list-initialization (uniform-initialization) were always being used, because 
the direct-initialization overload cannot fail.
<p/>
I can see two corner cases that expose gaps in this scheme. One occurs when arguments intended for 
<tt>std::initializer_list</tt> satisfy a constructor, such as trying to emplace-insert a value of <tt>{3, 4}</tt> in 
the above example. The workaround is to explicitly specify the <tt>std::initializer_list</tt> type, as in 
<tt>v.emplace_back(std::initializer_list&lt;int&gt;(3, 4))</tt>. Since this matches the semantics as if 
<tt>std::initializer_list</tt> were deduced, there seems to be no real problem here.
<p/>
The other case is when arguments intended for aggregate initialization satisfy a constructor. Since aggregates cannot 
have user-defined constructors, this requires that the first nonstatic data member of the aggregate be implicitly 
convertible from the aggregate type, and that the initializer list have one element. The workaround is to supply an 
initializer for the second member. It remains impossible to in-place construct an aggregate with only one nonstatic 
data member by conversion from a type convertible to the aggregate's own type. This seems like an acceptably small 
hole.
<p/>
The change is quite small because <tt>EmplaceConstructible</tt> is defined in terms of whatever allocator is specified, 
and there is no need to explicitly mention SFINAE in the normative text.
</p>


<p><i>[2012, Kona]</i></p>

<p>
Move to Open.
</p>
<p>
There appears to be a real concern with initializing aggregates, that can be performed only
using brace-initialization.  There is little interest in the rest of the issue, given the existence
of 'emplace' methods in C++11.
</p>
<p>
Move to Open, to find an acceptable solution for intializing aggregates.  There is the potential
that EWG may have an interest in this area of language consistency as well.
</p>

<p><i>[2013-10-13, Ville]</i></p>

<p>
This issue is related to <a href="lwg-active.html#2070">2070</a>.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<p>Change 20.7.9.1 [allocator.members] p12 as indicated:</p>

<blockquote><pre>
template &lt;class U, class... Args&gt;
  void construct(U* p, Args&amp;&amp;... args);
</pre><blockquote>
<p>
12 <i>Effects</i>: <tt>::new((void *)p) U(std::forward&lt;Args&gt;(args)...)</tt> <ins>if <tt>is_constructible&lt;U, Args...&gt;::value</tt> 
is <tt>true</tt>, else <tt>::new((void *)p) U{std::forward&lt;Args&gt;(args)...}</tt></ins>
</p>
</blockquote></blockquote>






<hr>
<h3><a name="2095"></a>2095. <tt>promise</tt> and <tt>packaged_task</tt> missing constructors needed for uses-allocator construction</h3>
<p><b>Section:</b> 30.6.5 [futures.promise], 30.6.9 [futures.task] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-11-01 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
This example is ill-formed according to C++11 because <tt>uses_allocator&lt;promise&lt;R&gt;, A&gt;::value</tt> is true, but
<tt>is_constructible&lt;promise&lt;R&gt;, A, promise&lt;R&gt;&amp;&amp;&gt;::value</tt> is false. Similarly for <tt>packaged_task</tt>.
</p>
<blockquote><pre>
#include &lt;future&gt;
#include &lt;memory&gt;
#include &lt;tuple&gt;

using namespace std;

typedef packaged_task&lt;void()&gt; task;
typedef promise&lt;void&gt; prom;
allocator&lt;task&gt; a;

tuple&lt;task, prom&gt; t1{ allocator_arg, a };
tuple&lt;task, prom&gt; t2{ allocator_arg, a, task{}, prom{} };
</pre></blockquote>

<p><i>[2012, Portland]</i></p>

<p>
This is an allocator issue, and should be dealt with directly by LWG.
</p>

<p><i>[2013-03-06]</i></p>


<p>
Jonathan suggests to make the new constructors non-explicit and makes some representational improvements.
</p>


<p><i>[2013-09 Chicago]</i></p>

<p>
Move to deferred.
</p>
<p>
This issue has much in common with similar problems with <tt>std::function</tt> that are being addressed
by the polymorphic allocators proposal currently under evaluation in LEWG.  Defer further discussion on
this topic until the final outcome of that paper and its proposed resolution is known.
</p>

<p><i>[2014-02-20 Re-open Deferred issues as Priority 4]</i></p>




<p><b>Proposed resolution:</b></p>
<p><i>[This wording is relative to the FDIS.]</i></p>


<ol>
<li><p>Add to 30.6.5 [futures.promise], class template <tt>promise</tt> synopsis, 
as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class R&gt;
  class promise {
  public:
    promise();
    template &lt;class Allocator&gt;
    promise(allocator_arg_t, const Allocator&amp; a);
    <ins>template &lt;class Allocator&gt;
    promise(allocator_arg_t, const Allocator&amp; a, promise&amp;&amp; rhs) noexcept;</ins>
    promise(promise&amp;&amp; rhs) noexcept;
    promise(const promise&amp; rhs) = delete;
    ~promise();	
    [&hellip;]
  };
  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Change 30.6.5 [futures.promise] as indicated:</p>

<blockquote><pre>
promise(promise&amp;&amp; rhs) noexcept;
<ins>template &lt;class Allocator&gt;
promise(allocator_arg_t, const Allocator&amp; a, promise&amp;&amp; rhs) noexcept;</ins>
</pre><blockquote>
<p>
-5- <i>Effects</i>: constructs a new <tt>promise</tt> object and transfers ownership of 
the shared state of <tt>rhs</tt> (if any) to the newly-constructed object.
<p/>
-6- <i>Postcondition</i>: <tt>rhs</tt> has no shared state.
<p/>
<ins>-?- [<i>Note</i>: <tt>a</tt> is not used &mdash; <i>end note</i>]</ins>
</p>
</blockquote></blockquote>

</li>

<li><p>Add to 30.6.9 [futures.task], class template <tt>packaged_task</tt> synopsis, 
as indicated:</p>

<blockquote><pre>
namespace std {
  template&lt;class&gt; class packaged_task; // <i>undefined</i>

  template&lt;class R, class... ArgTypes&gt;
  class packaged_task&lt;R(ArgTypes...)&gt; {
  public:
    // construction and destruction
    packaged_task() noexcept;
    <ins>template &lt;class Allocator&gt;
      packaged_task(allocator_arg_t, const Allocator&amp; a) noexcept;</ins>
    template &lt;class F&gt;
      explicit packaged_task(F&amp;&amp; f);
    template &lt;class F, class Allocator&gt;
      explicit packaged_task(allocator_arg_t, const Allocator&amp; a, F&amp;&amp; f);
    ~packaged_task();
	
    // no copy
    packaged_task(const packaged_task&amp;) = delete;
    <ins>template&lt;class Allocator&gt;
      packaged_task(allocator_arg_t, const Allocator&amp; a, const packaged_task&amp;) = delete;</ins>
    packaged_task&amp; operator=(const packaged_task&amp;) = delete;
    
    // move support
    packaged_task(packaged_task&amp;&amp; rhs) noexcept;
    <ins>template &lt;class Allocator&gt;
      packaged_task(allocator_arg_t, const Allocator&amp; a, packaged_task&amp;&amp; rhs) noexcept;</ins>
    packaged_task&amp; operator=(packaged_task&amp;&amp; rhs) noexcept;
    void swap(packaged_task&amp; other) noexcept;
    [&hellip;]
  };
  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Change 30.6.9.1 [futures.task.members] as indicated:</p>

<blockquote><pre>
packaged_task() noexcept;
<ins>template &lt;class Allocator&gt;
  packaged_task(allocator_arg_t, const Allocator&amp; a) noexcept;</ins>
</pre><blockquote>
<p>
-1- <i>Effects</i>: constructs a <tt>packaged_task</tt> object with no shared state and no stored task.
<p/>
<ins>-?- [<i>Note</i>: <tt>a</tt> is not used &mdash; <i>end note</i>]</ins>
</p>
</blockquote></blockquote>
<p>[&hellip;]</p>
<blockquote><pre>
packaged_task(packaged_task&amp;&amp; rhs) noexcept;
<ins>template &lt;class Allocator&gt;
  packaged_task(allocator_arg_t, const Allocator&amp; a, packaged_task&amp;&amp; rhs) noexcept;</ins>
</pre><blockquote>
<p>
-5- <i>Effects</i>: constructs a new <tt>packaged_task</tt> object and transfers ownership of <tt>rhs</tt>'s 
shared state to <tt>*this</tt>, leaving <tt>rhs</tt> with no shared state. Moves the stored task from <tt>rhs</tt> 
to <tt>*this</tt>.
<p/>
-6- <i>Postcondition</i>: <tt>rhs</tt> has no shared state.
<p/>
<ins>-?- [<i>Note</i>: <tt>a</tt> is not used &mdash; <i>end note</i>]</ins>
</p>
</blockquote></blockquote>

</li>
</ol>

<blockquote><pre>
</pre><blockquote>
<p>
</p></blockquote></blockquote>






<hr>
<h3><a name="2101"></a>2101. Some transformation types can produce impossible types</h3>
<p><b>Section:</b> 20.10.7 [meta.trans] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-11-18 <b>Last modified:</b> 2014-05-23</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Table 53 &mdash; "Reference modifications" says in regard to the type trait 
<tt>add_lvalue_reference</tt> (emphasize mine)
</p>

<blockquote>
<p>
If <tt>T</tt> names an object or <strong>function</strong> type then the member typedef type
shall name <tt>T&amp;</tt>;
</p>
</blockquote>

<p>
The problem with this specification is that function types with <i>cv</i>-qualifier or <i>ref</i>-qualifier, 
like
</p>
<blockquote><pre>
void() const
void() &amp;
</pre></blockquote>
<p>
are also affected by the first part of the rule, but this would essentially mean, that
instantiating <tt>add_lvalue_reference</tt> with such a type would attempt to form
a type that is not defined in the C++ type system, namely
</p>
<blockquote><pre>
void(&amp;)() const
void(&amp;)() &amp;
</pre></blockquote>
<p>
The general policy for <i>TransformationTrait</i>s is to define always some meaningful 
mapping type, but this does not hold for <tt>add_lvalue_reference</tt>, <tt>add_rvalue_reference</tt>,
and in addition to these two for <tt>add_pointer</tt> as well. The latter one would 
attempt to form the invalid types
</p>
<blockquote><pre>
void(*)() const
void(*)() &amp;
</pre></blockquote>
<p>
A possible reason why those traits were specified in this way is that in C++03 (and that means
for TR1), <i>cv</i>-qualifier were underspecified in the core language and several compilers
just ignored them during template instantiations. This situation became fixed by adopting
CWG issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#295">295</a> and 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#547">547</a>.
<p/>
While there is possibly some core language clarification needed (see reflector messages
starting from c++std-core-20740), it seems also clear that the library should fix the
specification. The suggested resolution follows the style of the specification of the
support concepts <tt>PointeeType</tt> and <tt>ReferentType</tt> defined in 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>.
</p>


<p><i>[2012-02-10, Kona]</i></p>

<p>
Move to NAD.
</p>
<p>
These cv- and ref-qualified function types are aberrations in the type system, and do
not represent any actual entity defined by the language.  The notion of cv- and ref-
qualification applies only to the implicit <tt>*this</tt> reference in a member function.
</p>
<p>
However, these types can be produced by quirks of template metaprogramming, the question
remains what the library should do about it.  For example, <tt>add_reference</tt> returns
the original type if passed a reference type, or a <tt>void</tt> type.  Conversely,
<tt>add_pointer</tt> will return a pointer to the referenced type when passed a reference.
</p>
<p>
It is most likely that the 'right' answer in any case will depend on the context that the
question is being asked, in terms of forming these obscure types.  The best the LWG can
do is allow an error to propagate back to the user, so they can provide their own meaningful
answer in their context - with additional metaprogramming on their part.  The consensus is
that if anyone is dangerous enough with templates to get themselves into this problem, they
will also have the skills to resolve the problem themselves.  This is not going to trip up
the non-expert developer.
</p>
<p>
Lastly, it was noted that this problem arises only because the language is inconsistent in
providing us these nonsense types that do no really represent anything in the language.
There may be some way Core or Evolution could give us a more consistent type system so that
the LWG does not need to invent an answer at all, should this question need resolving.  This
is another reason to not specify anything at the LWG trait level at this time, leaving the
other working groups free to produce the 'right' answer that we can then follow without
changing the meaning of existing, well-defined programs.
</p>

<p><i>[2012-02-10, post-Kona]</i></p>

<p>
Move back to Open. Daniel is concerned that this is not an issue we can simply ignore,
further details to follow.
</p>

<p><i>[2012-10-06, Daniel comments]</i></p>

<p>
This issue really should be resolved as a defect: First, the argument that "forming these obscure types"
should "allow an error to propagate" is inconsistent with the exact same "obscure type" that would be formed
when <tt>std::add_lvalue_reference&lt;void&gt;</tt> wouldn't have an extra rules for <tt>void</tt> types, which
also cannot form references. The originally proposed resolution attempts to apply the same solution for the same 
common property of <tt>void</tt> types and function types with <em>cv</em>-qualifiers or <em>ref</em>-qualifier.
These functions had the property of <tt>ReferentType</tt> during concept time (see 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#749">CWG 749</a> bullet three for the final 
wording).
<p/>
Core issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1417">CWG 1417</a> has clarified
that any attempt to form a reference of a pointer to a function type with <em>cv</em>-qualifiers or 
<em>ref</em>-qualifier is ill-formed. Unfortunately, many compilers don't implement this yet.
<p/>
I also would like to warn about so-called "obscure" types: The problem is that these can occur as the side effect
of finding a best match overload of function templates, where this type is exactly correct for one of these
overloads, but causes a deep (not-sfinae-friendly) error for others where one of these traits are part of the 
signature.
<p/>
Existing experience with <tt>void</tt> types shows, that this extra rule is not so unexpected. Further, any usage 
of the result types of these traits as argument types or return types of functions would make these ill-formed 
(and in a template context would be sfinaed away), so the expected effects are rarely unnoticed. Checking
all existing explicit usages of the traits <tt>add_rvalue_reference</tt>, <tt>add_lvalue_reference</tt>, and
<tt>add_pointer</tt> didn't show any example where the error would be silent: <tt>add_rvalue_reference</tt>
is used to specify the return value of <tt>declval()</tt> and the instantiation of <tt>declval&lt;void() const&gt;()</tt>
would be invalid, because of the attempt to return a function type. Similarly, <tt>add_lvalue_reference</tt>
is used to specify the return type of <tt>unique_ptr&lt;T&gt;::operator*()</tt>. Again, any instantiation with 
<tt>void() const</tt> wouldn't remain unnoticed. The trait <tt>add_pointer</tt> is used to specify the trait
<tt>std::decay</tt> and this is an interesting example, because it is well-formed when instantiated with <tt>void</tt> 
types, too, and is heavily used throughout the library specification. All use-cases would not be negatively affected 
by the suggested acceptance of function types with <em>cv</em>-qualifiers or <em>ref</em>-qualifier, because they involve 
types that are either function arguments, function parameters or types were references are formed from.
<p/>
The alternative would be to add an additional extra rule that doesn't define a type member 'type' when
we have a function type with <em>cv</em>-qualifiers or <em>ref</em>-qualifier. This is better than the
current state but it is not superior than the proposal to specify the result as the original type, because
both variants are sfinae-friendly. A further disadvantage of the "non-type" approach here would be that any
usage of <tt>std::decay</tt> would require special protection against these function types, because 
instantiating <tt>std::decay&lt;void() const&gt;</tt> again would lead to a deep, sfinae-unfriendly error.
<p/>
The following example demonstrates the problem: Even though the second <tt>f</tt> template is the best final
match here, the first one will be instantiated. During that process <tt>std::decay&lt;T&gt;::type</tt>
becomes instantiated as well and will raise a deep error, because as part of the implementation the trait
<tt>std::add_pointer&lt;void() const&gt;</tt> becomes instantiated:
</p>
<blockquote><pre>
#include &lt;type_traits&gt;

template&lt;class T&gt;
typename std::decay&lt;T&gt;::type f(T&amp;&amp; t);

template&lt;class T, class U&gt;
U f(U u);

int main() {
  f&lt;void() const&gt;(0);
}
</pre></blockquote>
<p>
When the here proposed resolution would be applied this program would be well-formed and selects the expected function.
</p>

<p>
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<ol>
<li><p>Change Table 53 &mdash; "Reference modifications" in 20.10.7.2 [meta.trans.ref] as indicated:</p>

<table border="1">
<caption>Table 53 &mdash; Reference modifications</caption>
<tr>
<th>Template</th>
<th>Comments</th>
</tr> 

<tr>
<td colspan="2" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct<br/>
add_lvalue_reference;</tt>
</td>
<td>
If <tt>T</tt> names an object <tt>type</tt> or <ins>if <tt>T</tt> names a</ins> function type <ins>that does not have<br/>
<i>cv</i>-qualifiers or a <i>ref</i>-qualifier</ins> then the member typedef <tt>type</tt><br/>
shall name <tt>T&amp;</tt>; otherwise, if <tt>T</tt> names a type "rvalue reference to <tt>T1</tt>" then<br/>
the member typedef <tt>type</tt> shall name <tt>T1&amp;</tt>; otherwise, <tt>type</tt> shall name <tt>T</tt>.
</td>
</tr>

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct<br/>
add_rvalue_reference;</tt>
</td>
<td>
If <tt>T</tt> names an object <tt>type</tt> or <ins>if <tt>T</tt> names a</ins> function type <ins>that does not have<br/>
<i>cv</i>-qualifiers or a <i>ref</i>-qualifier</ins> then the member typedef <tt>type</tt><br/>
shall name <tt>T&amp;&amp;</tt>; otherwise, <tt>type</tt> shall name <tt>T</tt>. [<i>Note</i>: This rule reflects<br/>
the semantics of reference collapsing (8.3.2 [dcl.ref]). For example, when a type <tt>T</tt><br/>
names a type <tt>T1&amp;</tt>, the type <tt>add_rvalue_reference&lt;T&gt;::type</tt> is not an<br/>
rvalue reference. &mdash; <i>end note</i>]
</td>
</tr>
</table>

</li>

<li><p>Change Table 56 &mdash; "Pointer modifications" in 20.10.7.5 [meta.trans.ptr] as indicated:</p>

<table border="1">
<caption>Table 56 &mdash; Pointer modifications</caption>
<tr>
<th>Template</th>
<th>Comments</th>
</tr> 

<tr>
<td colspan="2" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct add_pointer;</tt>
</td>
<td>
<del>The member typedef <tt>type</tt> shall name the same type as</del><br/>
<ins>If <tt>T</tt> names a function type that has <i>cv</i>-qualifiers or a <i>ref</i>-qualifier<br/>
then the member typedef <tt>type</tt> shall name <tt>T</tt>; otherwise, it<br/> 
shall name the same type as</ins> <tt>remove_reference&lt;T&gt;::type*</tt>.
</td>
</tr>

</table>

</li>
</ol>
</blockquote>

<p>
The following revised proposed resolution defines - in the absence of a proper core language definition - a new
term <em>referenceable type</em> as also suggested by the resolution for LWG <a href="lwg-defects.html#2196">2196</a> as an
umbrella of the negation of <tt>void</tt> types and function types with <em>cv</em>-qualifiers or <em>ref</em>-qualifier. 
This simplifies and minimizes the requires wording changes.
</p>

<p><i>[
2013-09-26, Daniel synchronizes wording with recent draft
]</i></p>


<p><i>[
2014-05-18, Daniel synchronizes wording with recent draft and comments
]</i></p>


<p>
My impression is that this urgency of action this issue attempts to point out is partly caused by the fact that even for
the most recent C++14 compilers the implementations have just recently changed to adopt the core wording. Examples for these
are bug reports to <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182">gcc</a> or 
<a href="http://llvm.org/bugs/show_bug.cgi?id=19742">clang</a>.
<p/>
Occasionally the argument has been presented to me that the suggested changes to the traits affected by this issue would
lead to irregularities compared to other traits, especially the lack of guarantee that <tt>add_pointer</tt> might not return
a pointer or that <tt>add_(l/r)value_reference</tt> might not return a reference type. I would like to point out that this
kind of divergence is actually already present in most <tt>add/remove</tt> traits: For example, we have no guarantee that
<tt>add_const</tt> returns a const type (Reference types or function types get special treatments), or that <tt>add_rvalue_reference</tt>
returns an rvalue-reference (e.g. when applied to an lvalue-reference type).
<p/>
Zhihao Yuan brought to my attention, that the originally proposing paper 
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2002/n1345.html">N1345</a> carefully discussed these design choices.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change Table 53 &mdash; "Reference modifications" in 20.10.7.2 [meta.trans.ref] as indicated:</p>

<table border="1">
<caption>Table 53 &mdash; Reference modifications</caption>
<tr>
<th>Template</th>
<th>Comments</th>
</tr> 

<tr>
<td colspan="2" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct<br/>
add_lvalue_reference;</tt>
</td>
<td>
If <tt>T</tt> names <del>an object or function type</del><ins>a referenceable type</ins><br/>
then the member typedef <tt>type</tt><br/>
shall name <tt>T&amp;</tt>; otherwise, <del>if <tt>T</tt> names a type "rvalue reference to <tt>T1</tt>" then<br/>
the member typedef <tt>type</tt> shall name <tt>T1&amp;</tt>; otherwise,</del> <tt>type</tt> shall name <tt>T</tt>.<br/>
<ins>[<i>Note</i>: This rule reflects the semantics of reference collapsing (8.3.2 [dcl.ref]). &mdash; <i>end note</i>]</ins>
</td>
</tr>

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct<br/>
add_rvalue_reference;</tt>
</td>
<td>
If <tt>T</tt> names <del>an object or function type</del><ins>a referenceable type</ins><br/>
then the member typedef <tt>type</tt><br/>
shall name <tt>T&amp;&amp;</tt>; otherwise, <tt>type</tt> shall name <tt>T</tt>. [<i>Note</i>: This rule reflects<br/>
the semantics of reference collapsing (8.3.2 [dcl.ref]). For example, when a type <tt>T</tt><br/>
names a type <tt>T1&amp;</tt>, the type <tt>add_rvalue_reference_t&lt;T&gt;</tt> is not an<br/>
rvalue reference. &mdash; <i>end note</i>]
</td>
</tr>
</table>

</li>

<li><p>Change Table 56 &mdash; "Pointer modifications" in 20.10.7.5 [meta.trans.ptr] as indicated:</p>

<table border="1">
<caption>Table 56 &mdash; Pointer modifications</caption>
<tr>
<th>Template</th>
<th>Comments</th>
</tr> 

<tr>
<td colspan="2" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct add_pointer;</tt>
</td>
<td>
<ins>If <tt>T</tt> names a referenceable type or a (possibly <i>cv</i>-qualified) <tt>void</tt> type then<br/></ins>
<del>T</del><ins>t</ins>he member typedef <tt>type</tt> shall name the same type as<br/>
<tt>remove_reference_t&lt;T&gt;*</tt><ins>; otherwise, <tt>type</tt> shall name <tt>T</tt></ins>.
</td>
</tr>

</table>

</li>
</ol>





<hr>
<h3><a name="2106"></a>2106. <tt>move_iterator</tt> wrapping iterators returning prvalues</h3>
<p><b>Section:</b> 24.5.3 [move.iterators] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2011-11-30 <b>Last modified:</b> 2014-05-23</p>
<p><b>View all other</b> <a href="lwg-index.html#move.iterators">issues</a> in [move.iterators].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Shouldn't <tt>move_iterator</tt> be specialized so that if the iterator it wraps
returns a prvalue when dereferenced, the <tt>move_iterator</tt> also returns by
value? Otherwise, it creates a dangling reference.
<p/>
Howard: I believe just changing <tt>move_iterator&lt;I&gt;::reference</tt> would do.
A direction might be testing on <tt>is_reference&lt;iterator_traits&lt;I&gt;::reference&gt;</tt>, 
or <tt>is_reference&lt;decltype(*declval&lt;I&gt;())&gt;</tt>.
<p/>
Daniel: I would prefer to use a consistent style among the iterator adaptors, so I
suggest to keep with the <tt>iterator_traits</tt> typedefs if possible. 
</p>
<blockquote><pre>
using reference = typename conditional&lt;
  is_reference&lt;typename iterator_traits&lt;Iterator&gt;::reference&gt;::value,
  value_type&amp;&amp;,
  value_type
&gt;::type;
</pre></blockquote>
<p>
We might also want to ensure that if <tt>Iterator</tt>'s <tt>reference</tt> type <em>is</em>
a reference, the referent is equal to <tt>value_type</tt> (after removal of <i>cv</i>-qualifiers). 
In <em>general</em> we have no such guarantee.
<p/>
Marc: In the default case where we don't return <tt>value_type&amp;&amp;</tt>, should we use 
<tt>value_type</tt> or should we keep the <tt>reference</tt> type of the wrapped iterator?
<p/>
Daniel: This suggestion looks appealing at first, but the problem here is that using this typedef
can make it impossible for <tt>move_iterator</tt> to satisfy its contract, which means returning
an rvalue of the value type (Currently it says rvalue-reference, but this must be fixed as of
this issue anyway). I think that user-code can reasonably expect that when it has constructed
an object <tt>m</tt> of <tt>move_iterator&lt;It&gt;</tt>, where <tt>It</tt> is a valid 
mutable iterator type, the expression
</p>
<blockquote><pre>
<span style="color:#C80000;font-weight:bold">It::value_type&amp;&amp; rv = *m;</span>
</pre></blockquote>
<p>
is well-formed.
<p/>
Let's set <tt>R</tt> equal to <tt>iterator_traits&lt;Iterator&gt;::reference</tt>
in the following. We can discuss the following situations:
</p>
<ol><li><tt>R</tt> is a reference type: We can only return the corresponding xvalue of <tt>R</tt>,
if <tt>value_type</tt> is reference-related to the referent type, else this is presumably no
forward iterator and we cannot say much about it, except that it must be convertible to
<tt>value_type</tt>, so it better should return a prvalue.</li>
<li><tt>R</tt> is not a reference type: In this case we can rely on a conversion to
<tt>value_type</tt> again, but not much more. Assume we would return <tt>R</tt> directly,
this might turn out to have a conversion to an lvalue-reference type of the value type (for
example). If that is the case, this would indirectly violate the contract of 
<tt>move_iterator</tt>.</li>
</ol>
<p>
In regard to the first scenario I suggest that implementations are simply required to
check that <tt>V2 = remove_cv&lt;remove_reference&lt;R&gt;::type&gt;::type</tt> is equal
to the value type <tt>V1</tt> as a criterion to return this reference as an xvalue, in all other
cases it should return the value type directly as prvalue.
<p/>
The additional advantage of this strategy is, that we always ensure that <tt>reference</tt> has 
the correct <i>cv</i>-qualification, if <tt>R</tt> is a real reference.
<p/>
It is possible to improve this a bit by indeed supporting reference-related types,
this would require to test <tt>is_same&lt;V1, V2&gt;::value || is_base_of&lt;V1, V2&gt;::value</tt> 
instead. I'm unsure whether (a) this additional effort is worth it and (b) a strict reading of
the forward iterator requirements seems not to allow to return a reference-related type (Whether 
this is a defect or not is another question).
</p>

<p><i>[2011-12-05: Marc Glisse comments and splits into two resolution alternatives]</i></p>


<p>
I guess I am looking at the speed of:
</p>
<blockquote><pre>
value_type x;
x = *m;
</pre></blockquote>
<p>
(copy construction would likely trigger copy elision and thus be neutral)

instead of the validity of:
</p>
<blockquote><pre>
value_type&amp;&amp; x = *m;
</pre></blockquote>
<p>
In this sense, Daniels earlier proposition that ignored <tt>value_type</tt> and just did 
<tt>switch_lvalue_ref_to_rvalue_ref&lt;reference&gt;</tt> was easier to understand (and it didn't 
require thinking about reference related types).
<p/>
The currently proposed resolution has been split into two alternatives.
</p>


<p><i>[2012, Kona]</i></p>

<p>
Move to Review.
</p>
<p>
Alisdair: This only applies to input iterators, so keep that in mind when thinking about this.
</p>
<p>
STL: I see what B is doing, but not A.
</p>
<p>
Howard: I agree.
</p>
<p>
Alisdair: Should we use <tt>add_rvalue_reference</tt>?
</p>
<p>
STL: No, we do not want reference collapsing.
</p>
<p>
STL: Re A, messing with the CV qualification scares me.
</p>
<p>
Alisdair: Agree. That would break my intent.
</p>
<p>
STL: Actually I don't think it's actually wrong, but I still don't see what it's doing.
</p>
<p>
Alisdair: A is picking the value type, B is picking the proxy type.
</p>
<p>
Howard: I like returning the proxy type.
</p>
<p>
STL: Returning a reference (B) seems right, because the requirements say "reference".
I suspect that B works correctly if you have a move iterator wrapping a move iterator
wrapping a thing.  I think that A would mess up the type in the middle.
</p>
<p>
Considerable discussion about which version is correct, checking various examples.
</p>
<p>
STL: Still think B is right. Still don't understand A. In A we are losing the proxyness.
</p>
<p>
Howard: Agree 100%. We don't want to lose the proxy. If it's const, so be it.
</p>
<p>
STL: B is also understandable by mortals.
</p>
<p>
Howard: Remove to review, keep A but move it out of the proposed resolution area
(but keep it for rational).
</p>
<p>
Alisdair: Adding an explanatory note might be a good idea, if someone wants to write one.
</p>
<p>
Walter: Concerned about losing the word "reference" in p.1.
</p>
<p>
Howard: <tt>move_iterator</tt> will return an xvalue or a prvalue, both of which are rvalues.
</p>

<p><i>[Proposed resolution A, rejected in preference to the currently proposed resolution (B)

<ol>
<li><p>Change 24.5.3 [move.iterators] p1 as indicated:</p>

<blockquote><p>
Class template <tt>move_iterator</tt> is an iterator adaptor with the same behavior as the underlying iterator
except that its dereference operator implicitly converts the value returned by the underlying iterator's
dereference operator to an rvalue <del>reference</del><ins>of the value type</ins>. Some generic algorithms 
can be called with move iterators to replace copying with moving.
</p></blockquote>
</li>

<li><p>Change 24.5.3.1 [move.iterator], class template <tt>move_iterator</tt> synopsis, as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class Iterator&gt;
  class move_iterator {
  public:
    typedef Iterator iterator_type;
    typedef typename iterator_traits&lt;Iterator&gt;::difference_type difference_type;
    typedef Iterator pointer;
    typedef typename iterator_traits&lt;Iterator&gt;::value_type value_type;
    typedef typename iterator_traits&lt;Iterator&gt;::iterator_category iterator_category;
    typedef <del>value_type&amp;&amp;</del><ins><i>see below</i></ins> reference;
    [&hellip;]
  };
}
</pre></blockquote>

</li>

<li><p>Immediately following the class template <tt>move_iterator</tt> synopsis in 
24.5.3.1 [move.iterator] insert a new paragraph as indicated:</p>

<blockquote><p>
<ins>-?- Let <tt><i>R</i></tt> be <tt>iterator_traits&lt;Iterator&gt;::reference</tt> and
let <tt><i>V</i></tt> be <tt>iterator_traits&lt;Iterator&gt;::value_type</tt>. If 
<tt>is_reference&lt;<i>R</i>&gt;::value</tt> is <tt>true</tt> and if 
<tt>remove_cv&lt;remove_reference&lt;<i>R</i>&gt;::type&gt;::type</tt> is the same type as <tt><i>V</i></tt>, 
the template instantiation <tt>move_iterator&lt;Iterator&gt;</tt> shall define the nested type 
named <tt>reference</tt> as a synonym for <tt>remove_reference&lt;<i>R</i>&gt;::type&amp;&amp;</tt>, 
otherwise as a synonym for <tt><i>V</i></tt>.</ins>
</p></blockquote>
</li>
</ol>

]</i></p>


<p><i>[2012, Portland: Move to Tentatively Ready]</i></p>

<p>
AJM wonders if the implied trait might be useful elsewhere, and worth adding to type traits as a
transformation type trait.
</p>

<p>
Suspicion that the Range SG might find such a trait useful, but wait until there is clear additional
use of such a trait before standardizing.
</p>

<p>
Minor wording tweak to use <tt>add_rvalue_reference</tt> rather than manually adding the <tt>&amp;&amp;</tt>,
then move to Tentatively Ready.
</p>

<p><i>[2013-01-09 Howard Hinnant comments]</i></p>


<p>
I believe the P/R for LWG 2106 is incorrect (item 3).  The way it currently reads, <tt>move_iterator&lt;I&gt;::reference</tt> 
is <em>always</em> an lvalue reference.  I.e. if <tt>R</tt> is an lvalue reference type, then reference becomes 
<tt>add_rvalue_reference&lt;R&gt;::type</tt> which is just <tt>R</tt>. And if <tt>R</tt> is not a reference type, 
then reference becomes <tt>R</tt> (which is also just <tt>R</tt> ;-)).
</p>

<p>
I believe the correct wording is what was there previously:
</p>

<p>
-?- Let <tt>R</tt> be <tt>iterator_traits&lt;Iterator&gt;::reference</tt>. If <tt>is_reference&lt;R&gt;::value</tt> 
is true, the template instantiation <tt>move_iterator&lt;Iterator&gt;</tt> shall define the nested type named 
<tt>reference</tt> as a synonym for <tt>remove_reference&lt;R&gt;::type&amp;&amp;</tt>, otherwise as a synonym for 
<tt>R</tt>.
</p>

<p>
Additionally Marc Glisse points out that <tt>move_iterator&lt;I&gt;::operator*()</tt> should return 
<tt>static_cast&lt;reference&gt;(*current)</tt>, not <tt>std::move(*current)</tt>.
</p>

<p>
Previous resolution:
</p>
<blockquote class="note">
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Change 24.5.3 [move.iterators] p1 as indicated:</p>

<blockquote><p>
Class template <tt>move_iterator</tt> is an iterator adaptor with the same behavior as the underlying iterator
except that its dereference operator implicitly converts the value returned by the underlying iterator's
dereference operator to an rvalue <del>reference</del>. Some generic algorithms 
can be called with move iterators to replace copying with moving.
</p></blockquote>
</li>

<li><p>Change 24.5.3.1 [move.iterator], class template <tt>move_iterator</tt> synopsis, as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class Iterator&gt;
  class move_iterator {
  public:
    typedef Iterator iterator_type;
    typedef typename iterator_traits&lt;Iterator&gt;::difference_type difference_type;
    typedef Iterator pointer;
    typedef typename iterator_traits&lt;Iterator&gt;::value_type value_type;
    typedef typename iterator_traits&lt;Iterator&gt;::iterator_category iterator_category;
    typedef <del>value_type&amp;&amp;</del><ins><i>see below</i></ins> reference;
    [&hellip;]
  };
}
</pre></blockquote>

</li>

<li><p>Immediately following the class template <tt>move_iterator</tt> synopsis in 
24.5.3.1 [move.iterator] insert a new paragraph as indicated:</p>

<blockquote><p>
<ins>-?- Let <tt><i>R</i></tt> be <tt>iterator_traits&lt;Iterator&gt;::reference</tt>. If 
<tt>is_reference&lt;<i>R</i>&gt;::value</tt> is <tt>true</tt>, the template instantiation 
<tt>move_iterator&lt;Iterator&gt;</tt> shall define the nested type named <tt>reference</tt> 
as a synonym for <tt>add_rvalue_reference&lt;<i>R</i>&gt;::type</tt>, otherwise as a synonym
for <tt><i>R</i></tt>.</ins>
</p></blockquote>
</li>
</ol>
</blockquote>

<p><i>[2014-05-19, Daniel comments]</i></p>

<p>
The term <em>instantiation</em> has been changed to <em>specialization</em> in the newly added paragraph as
suggested by STL and much preferred by myself.
</p>

<p><i>[2014-05-19 Library reflector vote]</i></p>

<p>
The issue has been identified as Tentatively Ready based on five votes in favour.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 24.5.3 [move.iterators] p1 as indicated:</p>

<blockquote><p>
Class template <tt>move_iterator</tt> is an iterator adaptor with the same behavior as the underlying iterator
except that its indirection operator implicitly converts the value returned by the underlying iterator's
indirection operator to an rvalue <del>reference</del>. Some generic algorithms 
can be called with move iterators to replace copying with moving.
</p></blockquote>
</li>

<li><p>Change 24.5.3.1 [move.iterator], class template <tt>move_iterator</tt> synopsis, as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class Iterator&gt;
  class move_iterator {
  public:
    typedef Iterator iterator_type;
    typedef typename iterator_traits&lt;Iterator&gt;::difference_type difference_type;
    typedef Iterator pointer;
    typedef typename iterator_traits&lt;Iterator&gt;::value_type value_type;
    typedef typename iterator_traits&lt;Iterator&gt;::iterator_category iterator_category;
    typedef <del>value_type&amp;&amp;</del><ins><i>see below</i></ins> reference;
    [&hellip;]
  };
}
</pre></blockquote>

</li>

<li><p>Immediately following the class template <tt>move_iterator</tt> synopsis in 
24.5.3.1 [move.iterator] insert a new paragraph as indicated:</p>

<blockquote><p>
<ins>-?- Let <tt><i>R</i></tt> be <tt>iterator_traits&lt;Iterator&gt;::reference</tt>. If 
<tt>is_reference&lt;<i>R</i>&gt;::value</tt> is <tt>true</tt>, the template specialization 
<tt>move_iterator&lt;Iterator&gt;</tt> shall define the nested type named <tt>reference</tt> 
as a synonym for <tt>remove_reference&lt;<i>R</i>&gt;::type&amp;&amp;</tt>, otherwise as a synonym
for <tt><i>R</i></tt>.</ins>
</p></blockquote>
</li>

<li><p>Edit 24.5.3.3.4 [move.iter.op.star] p1 as indicated:</p>
<blockquote><pre>
reference operator*() const;
</pre><blockquote>
<p>
-1- <i>Returns</i>: <tt><del>std::move</del><ins>static_cast&lt;reference&gt;</ins>(*current)</tt>.
</p>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2108"></a>2108. No way to identify allocator types that always compare equal</h3>
<p><b>Section:</b> 17.6.3.5 [allocator.requirements] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-12-01 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Whether two allocator objects compare equal affects the complexity of
container copy and move assignments and also the possibility of an
exception being thrown by container move assignments. The latter point
means container move assignment cannot be <tt>noexcept</tt> when
<tt>propagate_on_container_move_assignment</tt> (POCMA) is false for the
allocator because there is no way to detect at compile-time if two
allocators will compare equal. LWG <a href="lwg-defects.html#2013">2013</a> means this affects all
containers using <tt>std::allocator</tt>, but even if that is resolved, this
affects all stateless allocators which do not explicitly define POCMA
to <tt>true_type</tt>.
<p/>
One solution would be to add an "always_compare_equal" trait to
<tt>allocator_traits</tt>, but that would be duplicating information that is
already defined by the type's equality operator if that operator
always returns true. Requiring users to write <tt>operator==</tt> that simply
returns true and also explicitly override a trait to repeat the same
information would be unfortunate and risk user errors that allow the
trait and actual <tt>operator==</tt> to disagree.
<p/>
Dave Abrahams suggested a better solution in message c++std-lib-31532,
namely to allow <tt>operator==</tt> to return <tt>true_type</tt>, which is convertible
to <tt>bool</tt> but also detectable at compile-time. Adopting this as the
recommended way to identify allocator types that always compare equal
only requires a slight relaxation of the allocator requirements so
that <tt>operator==</tt> is not required to return <tt>bool</tt> exactly.
<p/>
The allocator requirements do not make it clear that it is well-defined 
to compare non-const values, that should be corrected too.
<p/>
In message c++std-lib-31615 Pablo Halpern suggested an <tt>always_compare_equal</tt> 
trait that could still be defined, but with a sensible default value rather 
than requiring users to override it, and using that to set sensible values for 
other allocator traits:
</p>
<blockquote><p>
Do we still need <tt>always_compare_equal</tt> if we can have an <tt>operator==</tt>
that returns <tt>true_type</tt>?  What would its default value be? <tt>is_empty&lt;A&gt;
|| is_convertible&lt;decltype(a == a), true_type&gt;::value</tt>, perhaps?  One
benefit I see to such a definition is that stateless C++03 allocators
that don't use the <tt>true_type</tt> idiom will still benefit from the new
trait.
<p/>
[&hellip;]
<p/>
One point that I want to ensure doesn't get lost is that if we adopt some sort of 
<tt>always_compare_equal</tt>-like trait, then <tt>propagate_on_container_swap</tt> 
and <tt>propagate_on_container_move_assignment</tt> should default to 
<tt>always_compare_equal</tt>. Doing this will eliminate unnecessary requirements 
on the container element type, as per [LWG <a href="lwg-defects.html#2103">2103</a>].
</p></blockquote>
<p>
Optionally, <tt>operator==</tt> for <tt>std::allocator</tt> could be made to return 
<tt>true_type</tt>, however if LWG <a href="lwg-defects.html#2103">2103</a> is adopted that is less important.
<p/>
Alberto Ganesh Barbati: Suggest either <tt>always_compare_equal</tt>,
<tt>all_objects_(are_)equivalent</tt>, or <tt>all_objects_compare_equal</tt>.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Change Table 27 &mdash; "Descriptive variable definitions" in 17.6.3.5 [allocator.requirements]:</p>

<table border="1">
<caption>Table 27 &mdash; Descriptive variable definitions</caption>
<tr>
<th>Variable</th>
<th>Definition</th>
</tr> 

<tr>
<td>
<tt>a3<ins>, a4</ins></tt>
</td>
<td>
<del>an rvalue of</del><ins>values of (possibly <tt>const</tt>)</ins> type <tt>X</tt>
</td>
</tr>

<tr>
<td>
<tt>b</tt>
</td>
<td>
a value of <ins>(possibly <tt>const</tt>)</ins> type <tt>Y</tt>
</td>
</tr>

</table>

</li>

<li><p>Change Table 28 &mdash; "Allocator requirements" in 17.6.3.5 [allocator.requirements]:</p>

<table border="1">
<caption>Table 28 &mdash; Allocator requirements</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Default</th>
</tr> 

<tr>
<td>
<tt><del>a1 == a2</del><ins>a3 == a4</ins></tt>
</td>
<td>
<ins>convertible to</ins> <tt>bool</tt>
</td>
<td>
returns true only if storage<br/>
allocated from each can be<br/>
deallocated via the other.<br/>
<tt>operator==</tt> shall be reflexive,<br/>
symmetric, and transitive, and<br/>
shall not exit via an exception.
</td>
<td>
</td>
</tr>

<tr>
<td>
<tt><del>a1 != a2</del><ins>a3 != a4</ins></tt>
</td>
<td>
<ins>convertible to</ins> <tt>bool</tt>
</td>
<td>
same as <tt><del>!(a1 == a2)</del><ins>!(a3 == a4)</ins></tt>
</td>
<td>
</td>
</tr>

<tr>
<td>
<tt>a<ins>3</ins> == b</tt>
</td>
<td>
<ins>convertible to</ins> <tt>bool</tt>
</td>
<td>
same as <tt>a<ins>3</ins> ==<br/>
Y::rebind&lt;T&gt;::other(b)</tt>
</td>
<td>
</td>
</tr>

<tr>
<td>
<tt>a<ins>3</ins> != b</tt>
</td>
<td>
<ins>convertible to</ins> <tt>bool</tt>
</td>
<td>
same as <tt>!(a<ins>3</ins> == b)</tt>
</td>
<td>
</td>
</tr>

<tr>
<td colspan="4" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

<tr>
<td>
<tt>a.select_on_-<br/>
container_copy_-<br/>
construction()</tt>
</td>
<td>
<tt>X</tt>
</td>
<td>
Typically returns either <tt>a</tt> or<br/>
<tt>X()</tt>
</td>
<td>
<tt>return a;</tt>
</td>
</tr>

<tr>
<td>
<ins><tt>X::always_compares_equal</tt></ins>
</td>
<td>
<ins>Identical to or derived<br/>
from <tt>true_type</tt> or<br/>
<tt>false_type</tt></ins>
</td>
<td>
<ins><tt>true_type</tt> if the expression <tt>x1 == x2</tt> is<br/>
guaranteed to be <tt>true</tt> for any two (possibly<br/>
<tt>const</tt>) values <tt>x1, x2</tt> of type <tt>X</tt>, when<br/>
implicitly converted to <tt>bool</tt>. See Note B, below.</ins>
</td>
<td>
<ins><tt>true_type</tt>, if <tt>is_empty&lt;X&gt;::value</tt> is <tt>true</tt> or if<br/>
<tt>decltype(declval&lt;const X&amp;&gt;() == declval&lt;const X&amp;&gt;())</tt><br/> 
is convertible to <tt>true_type</tt>, otherwise <tt>false_type</tt>.</ins>
</td>
</tr>

<tr>
<td colspan="4" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

</table>
<p>
Note A: [&hellip;]
<p/>
<ins>Note B: If <tt>X::always_compares_equal::value</tt> or <tt>XX::always_compares_equal::value</tt> evaluate 
to <tt>true</tt> and an expression equivalent to <tt>x1 == x2</tt> or <tt>x1 != x2</tt> for any two values 
<tt>x1, x2</tt> of type <tt>X</tt> evaluates to <tt>false</tt> or <tt>true</tt>, respectively, the behaviour 
is undefined.</ins>
</p>

</li>

<li><p>Change class template <tt>allocator_traits</tt> synopsis, 20.7.8 [allocator.traits] as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class Alloc&gt; struct allocator_traits {
    typedef Alloc allocator_type;
    [&hellip;]
    <ins>typedef <i>see below</i> always_compares_equal;</ins>
    typedef <i>see below</i> propagate_on_container_copy_assignment;
    [&hellip;]
  };
}
</pre></blockquote>
</li>

<li><p>Insert the following between 20.7.8.1 [allocator.traits.types] p6 and p7 as indicated:</p>

<blockquote><pre>
<ins>typedef <i>see below</i> always_compares_equal;</ins>
</pre><blockquote>
<p>
<ins>-?- <i>Type</i>: <tt>Alloc::always_compares_equal</tt> if such a type exists; otherwise, 
<tt>true_type</tt> if <tt>is_empty&lt;Alloc&gt;::value</tt> is <tt>true</tt> or if 
<tt>decltype(declval&lt;const Alloc&amp;&gt;() == declval&lt;const Alloc&amp;&gt;())</tt> 
is convertible to <tt>true_type</tt>; otherwise, <tt>false_type</tt>
.</ins>
</p>
</blockquote></blockquote>
<blockquote><pre>
typedef <i>see below</i> propagate_on_container_copy_assignment;
</pre><blockquote>
<p>
-7- <i>Type</i>: <tt>Alloc::propagate_on_container_copy_assignment</tt> if such a type exits, 
otherwise <tt>false_type</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Change class template <tt>allocator</tt> synopsis, 20.7.9 [default.allocator] as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class T&gt; class allocator;

  <i>// specialize for <tt>void</tt>:</i>
  template &lt;&gt; class allocator&lt;void&gt; {
  public:
    typedef void* pointer;
    typedef const void* const_pointer;
    <i>// reference-to-<tt>void</tt> members are impossible.</i>
    typedef void value_type;
    template &lt;class U&gt; struct rebind { typedef allocator&lt;U&gt; other; };
  };

  template &lt;class T&gt; class allocator {
  public:
    typedef size_t size_type;
    typedef ptrdiff_t difference_type;
    typedef T* pointer;
    typedef const T* const_pointer;
    typedef T&amp; reference;
    typedef const T&amp; const_reference;
    typedef T value_type;
    template &lt;class U&gt; struct rebind { typedef allocator&lt;U&gt; other; };
    <ins>typedef true_type always_compares_equal;</ins>

    [&hellip;]
  };
}
</pre></blockquote>
</li>

</ol>






<hr>
<h3><a name="2111"></a>2111. Which <tt>unexpected</tt>&#47;<tt>terminate</tt> handler is called from the exception handling runtime?</h3>
<p><b>Section:</b> 18.8.3.4 [terminate], D.11.4 [unexpected] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2011-12-06 <b>Last modified:</b> 2014-03-02</p>
<p><b>View all other</b> <a href="lwg-index.html#terminate">issues</a> in [terminate].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Prior to N3242, modified by N3189, we said this about <tt>unexpected()</tt>:
</p>

<blockquote><p>
<i>Effects</i>: Calls the <tt>unexpected_handler</tt> function in effect immediately after evaluating the throw-expression 
(D.13.1), if called by the implementation, or calls the current <tt>unexpected_handler</tt>, if called by the program.
</p></blockquote>

<p>
and this about <tt>terminate()</tt>:
</p>

<blockquote><p>
<i>Effects</i>: Calls the <tt>terminate_handler</tt> function in effect immediately after evaluating the throw-expression (18.8.3.1), 
if called by the implementation, or calls the current <tt>terminate_handler</tt> function, if called by the program.
</p></blockquote>

<p>
But now in both places we say:
</p>

<blockquote><p>
Calls the current <tt>unexpected_handler</tt> function.
</p></blockquote>

<p>
and:
</p>

<blockquote><p>
Calls the current <tt>terminate</tt> function.
</p></blockquote>

<p>
The difference is that in C++98&#47;03 if a destructor reset a handler during stack unwinding, that new handler was 
not called if the unwinding later led to <tt>unexpected()</tt> or <tt>terminate()</tt> being called.  But these new 
words say that this new handler <em>is</em> called. This is an ABI-breaking change in the way exceptions are handled.  
Was this change intentional?
<p/>
N3189 was mainly about introducing exception safety and getters for the handlers. I don't recall the issue of 
<em>which</em> handler gets called being part of the discussion.
<p/>
I propose that we revert to the C++98&#47;03 behavior in this regard, lest ABI's such as the Itanium ABI are invalidated.  
A mechanical way to do this is to revert bullets 9 and 12 of N3189.
</p>

<p><i>[2011-12-09: Daniel comments]</i></p>


<p>
There was no such semantic change intended. It was an unfortunate side effect when trying to better separate different
responsibilities in the previous wording.
<p/>
A related issue is <a href="lwg-active.html#2088">2088</a>.
</p>

<p><i>[2012-01-30: Howard comments]</i></p>


<p>
The C++98&#47;03 wording is somewhat ambiguous:
</p>
<blockquote><p>
Calls the terminate_handler function in effect immediately after evaluating the throw-expression...
</p></blockquote>
<p>
There are potentially two throw-expressions being referred to here, and it is not clear if this sentence is referring to just the first or both:
</p>
<ol>
<li><tt>throw <i>assignment-expression</i>;</tt></li>
<li><tt>throw;</tt></li>
</ol>
<p>
There is ample evidence in current implementations that it is understood that <i>only</i> 
1. was meant. But clearly both 1 and 2 could have been meant. We need a clarification. Does an execution 
of a rethrow (throw;) update which handlers can potentially be called?
</p>
<ol>
<li value="2"><tt>throw;</tt> // update handlers to get_xxx()?</li>
</ol>
<p>
My opinion: Go with existing practice, and clarify what that practice is, if surveys find that everyone 
does the same thing. Gcc 4.2 and Apple do 1. only, and do not reset the handlers to the current handlers 
on throw;.
<p/>
If current practice is not unanimously one way or the other, I have no strong opinion. I have not found 
a motivating use case for the use of any particular handler. Most applications set the handlers once at 
the beginning of the program and then do not change them, and so will not be impacted by whatever decision 
is made here.
</p>

<p><i>[2014-02-15 Issaquah: Move to Review]</i></p>


<p>
STL: Original change in N3242 came from trying to make set/get exception handler thread safe.
The issue requests we revert to 98/03, which Howard notes was already ambiguous.
</p>

<p>
Alisdair: Issue author thinks we made this change in C++11 without taking into account Itanium ABI,
which cannot implement the new semantic (without breaking compatibility).
</p>

<p>
Alisdair: original change in N3242 was trying to solve the problem of which handler is called when
the handler is changing in another thread, but this turns out to be an issue in even the
single-threaded case.
</p>

<p>
Pablo: despite wanting to make it thread safe, you are still changing a global
</p>

<p>
STL and Marshall confirm that there is real implementation divergance on the question, so
we cannot pick just one behavior if we want to avoid breaking exisitng practice.
</p>

<p>
Alisdair: not sure who to talk to across all library vendors to fix, need more information
for progress (IBM and Sun)
</p>

<p>
STL: Howard did identify a problem with the wording as well: <tt>throw;</tt> is a throw expression,
but we typically want to re-activate the in-flight exception, not throw a new copy.
</p>

<p>
Pablo: wondering why all of this wording is here (N3189)? It looks like we were trying to handle another thread
changing handler between a <tt>throw</tt> and <tt>terminate</tt> in current thread.
</p>

<p>
Alisdair: Anything working with exception handling should have used only thread-local resources, but that ship has sailed.
We must account for the same exception object being re-thrown in multiple threads simultaneously, with no happens-before
relationships.
</p>

<p>
Room: Why on earth would we care about exactly which way the program dies when the terminate calls are racing?!
</p>

<p>
Pablo: Reasonable to set the handler once (in <tt>main</tt>) and never change it.
</p>

<p>
Pablo: If willing to put lots of work into this, you could say at point of a <tt>throw</tt> these handlers become
thread local but that is overkill.  We want destructors to be able to change these handlers (if only for backwards
compatibility).
</p>

<p>
Alisdair: the <i>&quot;do it right&quot;</i> is to do something per thread, but that is more work than vendors will want to do.
Want to say setting handler while running multiple threads is unspecified.
</p>

<p>
Pablo: possible all we need to do is say it is always the current handler
</p>

<p>
STL: That prevents an implementation or single threaded program from calling a new handler after a <tt>throw</tt>,
probably should say if <tt>terminate</tt> is called <i>by the implementation</i> (during EH), any handler that was
current can be called.  Leaves it up in the air as to when the handler is captured, supporting the diverging
existing practices.
</p>

<p>
Jeffrey: use <i>happens before</i> terminology to avoid introducing races
</p>

<p>
STL: Give this to concurrency?
</p>

<p>
Jeffrey: It is in clause 18, generally LWG and not SG1 territory.
</p>

<p>
Alisdair: Concerned about introducing <i>happens before</i> into fundamental exception handling since it would affect
single threaded performance as well.  Want to give to concurrency or LEWG/EWG, we are into language design here.
</p>

<p>
Jeffrey: suspect LEWG won't have a strong opinion.  I don't want it to be ours!!!
</p>

<p>
Pablo: Might be a case for core>
</p>

<p>
Alisdair: Would be happier if at least one core person were in the discussion.
</p>

<p>
STL: No sympathy for code that tries to guard the terminate handler.
</p>

<p>
Alisdair: We are back to set it once, globally.  Want to be clear that if <tt>set_terminate</tt> is called just once,
when EH is not active, and never changed again, then the user should get the handler from that specific call.
</p>

<p>
AlisdairM: "unspecified which handler is called if an exception is active when <tt>set_terminate</tt> is called."
This supports existing behaviors, and guarantees which handler is called in non-conentious situations.  Implicit
assumption that a funtion becomes a handler only after a successful call to <tt>set_handler</tt>, so we are not
leaving a door open to the implementation inventing entirely new handlers of its own.
</p>

<p>
<i>Consensus.</i>
</p>

<p>
Poll to confirm status as P1: new consensus is P3
</p>

<p>
<i>Action:</i> Alisdair provides new wording.  Drop from P1 to P3, and move to Review.
</p>



<p><b>Proposed resolution:</b></p>

<p>
Amend 18.8.3.4 [terminate] as indicated:
</p>

<tt>[[noreturn]] void terminate() noexcept;</tt>
<blockquote><p>
<i>Remarks:</i> Called by the implementation when exception handling must be abandoned for any of several reasons (15.5.1)
<del>, in effect immediately after throwing the exception</del>. May also be called directly by the program.
</p></blockquote>

<blockquote><p>
<i>Effects:</i> <ins>Calls a <tt>terminate_handler</tt> function. It is unspecified which <tt>terminate_handler</tt> function will
be called if an exception is active during a call to <tt>set_terminate</tt>. Otherwise c</ins><del>C</del>alls the current
<tt>terminate_handler</tt> function. [<i>Note:</i> A default <tt>terminate_handler</tt> is always considered a callable handler in
this context. &mdash; <i>end note</i>]
</p></blockquote>

<p>
Amend D.11.4 [unexpected] as indicated:
</p>

<tt>[[noreturn]] void unexpected();</tt>
<blockquote><p>
Remarks: Called by the implementation when a function exits via an exception not allowed by its <i>exception-specification</i>
(15.5.2)<del>, in effect after evaluating the throw-expression (D.11.1)</del>. May also be called directly by the program.
</p></blockquote>

<blockquote><p>
<i>Effects:</i> <ins>Calls an <tt>unexpected_handler</tt> function. It is unspecified which <tt>unexpected_handler</tt>
function will be called if an exception is active during a call to <tt>set_unexpected</tt>. Otherwise c</ins><del>C</del>alls the current 
<tt>unexpected_handler</tt> function. [<i>Note:</i> A default <tt>unexpected_handler</tt> is always considered a callable handler in 
this context. &mdash; <i>end note</i>] 
</p></blockquote>






<hr>
<h3><a name="2114"></a>2114. Incorrect "<em>contextually</em> convertible to <tt>bool</tt>" requirements</h3>
<p><b>Section:</b> 17.6.3.3 [nullablepointer.requirements], 24.2.3 [input.iterators], 24.2.7 [random.access.iterators], 25.1 [algorithms.general], 25.4 [alg.sorting], 30.2.1 [thread.req.paramname] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-12-09 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
As of 17.6.3.1 [utility.arg.requirements] Table 17&#47;18, the return types of the expressions
</p>
<blockquote><pre>
a == b
</pre></blockquote>
<p>
or
</p>
<blockquote><pre>
a &lt; b
</pre></blockquote>
<p>
for types satisfying the <tt>EqualityComparable</tt> or <tt>LessThanComparable</tt>
types, respectively, are required to be "convertible to <tt>bool</tt>" which corresponds to
a copy-initialization context. But several newer parts of the library that refer to 
such contexts have lowered the requirements taking  advantage of the new terminology of 
"<em>contextually</em> convertible to <tt>bool</tt>" instead, which corresponds to a 
direct-initialization context (In addition to "normal" direct-initialization constructions, 
operands of logical operations as well as <tt>if</tt> or <tt>switch</tt> conditions also 
belong to this special context).
<p/>
One example for these new requirements are input iterators which satisfy <tt>EqualityComparable</tt> 
but also specify that the expression
</p>
<blockquote><pre>
a != b
</pre></blockquote>
<p>
shall be just "<strong>contextually</strong> convertible to <tt>bool</tt>". The same discrepancy 
exists for requirement set <tt>NullablePointer</tt> in regard to several equality-related expressions.
<p/>
For random access iterators we have
</p>
<blockquote><p>
<tt>a &lt; b</tt>      contextually convertible to <tt>bool</tt>
</p></blockquote>
<p>
as well as for all derived comparison functions, so strictly speaking we could have a random access 
iterator that does not satisfy the <tt>LessThanComparable</tt> requirements, which looks like an
artifact to me.
<p/>
Even if we keep with the existing requirements based on <tt>LessThanComparable</tt> or
<tt>EqualityComparable</tt> we still would have the problem that some current specifications 
are actually  based on the assumption of implicit convertibility instead of "explicit convertibility", e.g. 
20.8.1.5 [unique.ptr.special] p3:
</p>
<blockquote><pre>
template &lt;class T1, class D1, class T2, class D2&gt;
bool operator!=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
</pre>
<blockquote>
<p>
-3- <i>Returns</i>: <tt>x.get() != y.get()</tt>.
</p>
</blockquote></blockquote>
<p>
Similar examples exist in 20.8.1.2.2 [unique.ptr.single.dtor] p2, 20.8.1.2.3 [unique.ptr.single.asgn] p9,
20.8.1.2.4 [unique.ptr.single.observers] p1+3+8, etc.
<p/>
In all these places the expressions involving comparison functions (but <em>not</em> those of the conversion 
of a <tt>NullablePointer</tt> to <tt>bool</tt>!) assume to be "convertible to <tt>bool</tt>". I think this
is a very natural assumption and all delegations of the comparison functions of some type <tt>X</tt> to some
other API type <tt>Y</tt> in third-party code does so assuming that copy-initialization semantics will
just work.
<p/>
The actual reason for using the newer terminology can be rooted back to LWG <a href="lwg-defects.html#556">556</a>. My hypotheses 
is that the resolution of that issue also needs a slight correction. Why so?
<p/>
The reason for opening that issue were worries based on the previous "convertible to <tt>bool</tt>"
wording. An expressions like "<tt>!pred(a, b)</tt>" might not be well-formed in those situations, because
<tt>operator!</tt> might not be accessible or might have an unusual semantics (and similarly for other logical
operations). This can indeed happen with unusual proxy return types, so the idea was that the evaluation of 
<tt>Predicate</tt>, <tt>BinaryPredicate</tt> (25.1 [algorithms.general] p8+9), and <tt>Compare</tt> 
(25.4 [alg.sorting] p2) should be defined based on contextual conversion to <tt>bool</tt>. 
Unfortunately this <em>alone</em> is not sufficient: In addition, I think, we <em>also</em> want the predicates 
to be (implicitly) convertible to <tt>bool</tt>! Without this wording, several conditions are plain wrong, 
e.g. 25.2.5 [alg.find] p2, which talks about "<tt>pred(*i) != false</tt>" (<tt>find_if</tt>) and 
"<tt>pred(*i) == false</tt>" (<tt>find_if_not</tt>). These expressions are not within a boolean context! 
<p/>
While we could simply fix all these places by proper wording to be considered in a "contextual conversion to
<tt>bool</tt>", I think that this is not the correct solution: Many third-party libraries already refer to
the previous C++03 <tt>Predicate</tt> definition &mdash; it actually predates C++98 and is as old as the 
<a href="http://www.sgi.com/tech/stl/Predicate.html">SGI specification</a>. It seems to be a high price to
pay to switch to direct initialization here instead of fixing a completely different specification problem.
<p/>
A final observation is that we have another definition for a <tt>Predicate</tt> in 30.2.1 [thread.req.paramname] p2:
</p>
<blockquote><p>
If a parameter is <tt>Predicate</tt>, <tt>operator()</tt> applied to the actual template argument shall return a value that
is convertible to <tt>bool</tt>.
</p></blockquote>
<p>
The problem here is not that we have two different definitions of <tt>Predicate</tt> in the standard &mdash; this 
is confusing, but this fact alone is not a defect. The first (minor) problem is that this definition does not properly 
apply to function objects that are function pointers, because <tt>operator()</tt> is not defined in a strict sense. 
But the actually worse second problem is that this wording has the very <tt>same</tt> problem that has originally lead to
LWG <a href="lwg-defects.html#556">556</a>! We only need to look at 30.5.1 [thread.condition.condvar] p15 to recognice this:
</p>
<blockquote><pre>
while (!pred())
  wait(lock);
</pre></blockquote>
<p>
The negation expression here looks very familiar to the example provided in LWG <a href="lwg-defects.html#556">556</a> and is sensitive
to the same "unusual proxy" problem. Changing the 30.2.1 [thread.req.paramname] wording to a corresponding
"contextual conversion to <tt>bool</tt>" wouldn't work either, because existing specifications rely on "convertible
to <tt>bool</tt>", e.g. 30.5.1 [thread.condition.condvar] p32+33+42 or 30.5.2 [thread.condition.condvarany] 
p25+26+32+33.
<p/>
To summarize: I believe that LWG <a href="lwg-defects.html#556">556</a> was not completely resolved. A pessimistic interpretation is,
that even with the current wording based on "contextually convertible to <tt>bool</tt>" the actual problem of that 
issue has <em>not</em> been fixed. What actually needs to be required here is some normative wording that basically
expresses something along the lines of:
</p>
<blockquote><p>
The semantics of <em>any</em> contextual conversion to <tt>bool</tt> shall be equivalent to the semantics of 
any implicit conversion to <tt>bool</tt>.
</p></blockquote>
<p>
This is still not complete without having concepts, but it seems to be a better approximation. Another way of solving
this issue would be to define a minimum requirements table with equivalent semantics. The proposed wording is a bit
simpler but attempts to express the same thing.
</p>

<p><i>[2012, Kona]</i></p>

<p>
Agree with Daniel that we potentially broke some C++03 user code, accept the changes striking
"contextually" from tables.  Stefan to provide revised wording for section 25, and figure out
changes to section 30.
</p>
<p>
Move to open, and then to Review when updated wording from Stefan is available.
</p>

<p><i>[2012-10-12, STL comments]</i></p>


<ol>
<li>
<p>
The current proposed resolution still isn't completely satisfying. It would certainly be possible for the Standard to 
require these various expressions to be implicitly and contextually convertible to <tt>bool</tt>, but that would have 
a subtle consequence (which, I will argue, is undesirable - regardless of the fact that it dates all the way back to 
C++98/03). It would allow users to provide really wacky types to the Standard Library, with one of two effects:
</p>
<ol style="list-style-type:upper-alpha">
<li>
<p>Standard Library implementations would have to go to great lengths to respect such wacky types, essentially using 
<tt>static_cast&lt;bool&gt;</tt> when invoking any predicates or comparators.
</p>
</li>

<li>
<p>
Otherwise, such wacky types would be de facto nonportable, because they would make Standard Library implementations 
explode.
</p>
</li>
</ol>

<p>
Effect B is the status quo we're living with today. What Standard Library implementations want to do with <tt>pred(args)</tt> 
goes beyond "<tt>if (pred(args))</tt>" (C++03), contextually converting <tt>pred(args)</tt> to <tt>bool</tt> (C++11), or 
implicitly and contextually converting <tt>pred(args)</tt> to <tt>bool</tt> (the current proposed resolution). 
Implementations want to say things like:
</p>

<blockquote><pre>
if (pred(args))
if (!pred(args))
if (cond &amp;&amp; pred(args))
if (cond &amp;&amp; !pred(args))
</pre></blockquote>

<p>
These are real examples taken from Dinkumware's implementation. There are others that would be realistic 
("<tt>pred(args) &amp;&amp; cond</tt>", "<tt>cond || pred(args)</tt>", etc.)
<p/>
Although negation was mentioned in this issue's Discussion section, and in LWG <a href="lwg-defects.html#556">556</a>'s, the current proposed 
resolution doesn't fix this problem. Requiring <tt>pred(args)</tt> to be implicitly and contextually convertible to <tt>bool</tt> 
doesn't prevent <tt>operator!()</tt> from being overloaded and returning <tt>std::string</tt> (as a wacky example). More 
ominously, it doesn't prevent <tt>operator&amp;&amp;()</tt> and <tt>operator||()</tt> from being overloaded and destroying 
short-circuiting.
</p>

</li>

<li>
<p>
I would like LWG input before working on Standardese for a new proposed resolution. Here's an outline of what I'd like to 
do:
</p>
<ol style="list-style-type:upper-alpha">
<li>
<p>
Introduce a new "concept" in 17.6.3 [utility.requirements], which I would call <tt>BooleanTestable</tt> in the 
absence of better ideas.
</p>
</li>

<li>
<p>
Centralize things and reduce verbosity by having everything simply refer to <tt>BooleanTestable</tt> when necessary. 
I believe that the tables could say "Return type: <tt>BooleanTestable</tt>", while Predicate/BinaryPredicate/Compare 
would need the incantation "shall satisfy the requirements of BooleanTestable".
</p>
</li>

<li>
<p>
Resolve the tug-of-war between users (who occasionally want to do weird things) and implementers (who don't want to have 
to contort their code) by requiring that:
</p>
<ol style="list-style-type:upper-roman">
<li>
<p>
Given a <tt>BooleanTestable x</tt>, <tt>x</tt> is both implicitly and contextually convertible to <tt>bool</tt>.
</p>
</li>

<li>
<p>
Given a <tt>BooleanTestable x</tt>, <tt>!x</tt> is <tt>BooleanTestable</tt>. (This is intentionally "recursive".)
</p>
</li>

<li>
<p>
Given a <tt>BooleanTestable x</tt>, <tt>bool t = x, t2(x), f = !x;</tt> has the postcondition <tt>t == t2 &amp;&amp; t != f</tt>.
</p>
</li>

<li>
<p>
Given a <tt>BooleanTestable x</tt> and a <tt>BooleanTestable y</tt> of possibly different types, "<tt>x &amp;&amp; y</tt>" 
and "<tt>x || y</tt>" invoke the built-in <tt>operator&amp;&amp;()</tt> and <tt>operator||()</tt>, triggering short-circuiting.
</p>
</li>

<li>
<p>
<tt>bool</tt> is <tt>BooleanTestable</tt>.
</p>
</li>
</ol>

</li>

</ol>

<p>
 I believe that this simultaneously gives users great latitude to use types other than <tt>bool</tt>, while allowing 
 implementers to write reasonable code in order to get their jobs done. (If I'm forgetting anything that implementers 
 would want to say, please let me know.)
</p>

</li>

<li>
<p>
About requirement (I): As Daniel patiently explained to me, we need to talk about both implicit conversions and 
contextual conversions, because it's possible for a devious type to have both "<tt>explicit operator bool()</tt>" 
and "<tt>operator int()</tt>", which might behave differently (or be deleted, etc.).
</p>
</li>

<li>
<p>
About requirement (IV): This is kind of tricky. What we'd like to say is, "<tt>BooleanTestable</tt> can't ever trigger 
an overloaded logical operator". However, given a perfectly reasonable type <tt>Nice</tt> - perhaps even <tt>bool</tt> itself! - 
other code (perhaps a third-party library) could overload <tt>operator&amp;&amp;(Nice, Evil)</tt>. Therefore, I believe 
that the requirement should be "no first use" - the Standard Library will ask for various <tt>BooleanTestable</tt> types 
from users (for example, the result of "<tt>first != last</tt>" and the result of "<tt>pred(args)</tt>"), and as long 
as they don't trigger overloaded logical operators with each other, everything is awesome.
</p>
</li>


<li>
<p>
About requirement (V): This is possibly redundant, but it's trivial to specify, makes it easier for users to understand 
what they need to do ("oh, I can always achieve this with <tt>bool</tt>"), and provides a "base case" for requirement 
(IV) that may or may not be necessary.  Since <tt>bool</tt> is <tt>BooleanTestable</tt>, overloading 
<tt>operator&amp;&amp;(bool, Other)</tt> (etc.) clearly makes the <tt>Other</tt> type non-<tt>BooleanTestable</tt>.
</p>
</li>
</ol>

<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
<p/>
<blockquote class="note">
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Change Table 25 &mdash; "<tt>NullablePointer</tt> requirements" in 17.6.3.3 [nullablepointer.requirements]
as indicated:</p>

<table border="1">
<caption>Table 25 &mdash; <tt>NullablePointer</tt> requirements</caption>
<tr align="center">
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
</tr> 

<tr>
<td colspan="3" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

<tr>
<td>
<tt>a != b</tt>
</td>
<td>
<del>contextually</del> convertible to <tt>bool</tt>
</td>
<td>
<tt>!(a == b)</tt>
</td>
</tr>

<tr>
<td>
<tt>a == np<br/>
np == a</tt>
</td>
<td>
<del>contextually</del> convertible to <tt>bool</tt>
</td>
<td>
<tt>a == P()</tt>
</td>
</tr>

<tr>
<td>
<tt>a != np<br/>
np != a</tt>
</td>
<td>
<del>contextually</del> convertible to <tt>bool</tt>
</td>
<td>
<tt>!(a == np)</tt>
</td>
</tr>

</table>
 
</li>

<li><p>Change Table 107 &mdash; "Input iterator requirements" in 24.2.3 [input.iterators]
as indicated:</p>

<table border="1">
<caption>Table 107 &mdash; Input iterator requirements (in addition to Iterator)</caption>
<tr align="center">
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr> 

<tr>
<td>
<tt>a != b</tt>
</td>
<td>
<del>contextually</del> convertible to <tt>bool</tt>
</td>
<td>
<tt>!(a == b)</tt>
</td>
<td>
pre: <tt>(a, b)</tt> is in the domain of <tt>==</tt>.
</td>
</tr>

<tr>
<td colspan="4" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

</table>
 
</li>

<li><p>Change Table 111 &mdash; "Random access iterator requirements" in 24.2.7 [random.access.iterators]
as indicated:</p>

<table border="1">
<caption>Table 111 &mdash; Random access iterator requirements (in addition to bidirectional iterator)</caption>
<tr align="center">
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr> 

<tr>
<td colspan="4" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

<tr>
<td>
<tt>a &lt; b</tt>
</td>
<td>
<del>contextually</del> convertible to <tt>bool</tt>
</td>
<td>
<tt>b - a &gt; 0</tt>
</td>
<td>
<tt>&lt;</tt> is a total ordering relation
</td>
</tr>

<tr>
<td>
<tt>a &gt; b</tt>
</td>
<td>
<del>contextually</del> convertible to <tt>bool</tt>
</td>
<td>
<tt>b &lt; a</tt>
</td>
<td>
<tt>&gt;</tt> is a total ordering relation opposite to <tt>&lt;</tt>.
</td>
</tr>

<tr>
<td>
<tt>a &gt;= b</tt>
</td>
<td>
<del>contextually</del> convertible to <tt>bool</tt>
</td>
<td>
<tt>!(a &lt; b)</tt>
</td>
<td>
</td>
</tr>

<tr>
<td>
<tt>a &lt;= b</tt>
</td>
<td>
<del>contextually</del> convertible to <tt>bool</tt>
</td>
<td>
<tt>!(a &gt; b)</tt>
</td>
<td>
</td>
</tr>

</table>
 
</li>

<li><p>Change 25.1 [algorithms.general] p8+9 as indicated:</p>

<blockquote>
<p>
-8- The <tt>Predicate</tt> parameter is used whenever an algorithm expects a function object 
(20.9 [function.objects]) that, when applied to the result of dereferencing the corresponding iterator, 
returns a value testable as <tt>true</tt>. In other words, if an algorithm takes <tt>Predicate pred</tt> 
as its argument and first as its iterator argument, it should work correctly in the construct 
<tt>pred(*first)</tt> <ins>implicitly or</ins> contextually converted to <tt>bool</tt> (Clause 4 [conv]). 
The function object <tt>pred</tt> shall not apply any non-constant function through the dereferenced iterator.
<p/>
-9- The <tt>BinaryPredicate</tt> parameter is used whenever an algorithm expects a function object that when applied
to the result of dereferencing two corresponding iterators or to dereferencing an iterator and type
<tt>T</tt> when <tt>T</tt> is part of the signature returns a value testable as <tt>true</tt>. In other words, if an algorithm takes
<tt>BinaryPredicate binary_pred</tt> as its argument and <tt>first1</tt> and <tt>first2</tt> as its iterator arguments, it should
work correctly in the construct <tt>binary_pred(*first1, *first2)</tt> <ins>implicitly or</ins> contextually converted to 
<tt>bool</tt> (Clause 4 [conv]).
<tt>BinaryPredicate</tt> always takes the first iterator's <tt>value_type</tt> as its first argument, that is, in those cases
when <tt>T</tt> value is part of the signature, it should work correctly in the construct <tt>binary_pred(*first1, value)</tt> 
<ins>implicitly or</ins> contextually converted to <tt>bool</tt> (Clause 4 [conv]). <tt>binary_pred</tt> shall 
not apply any non-constant function through the dereferenced iterators.
</p>
</blockquote>
</li>

<li><p>Change 25.4 [alg.sorting] p2 as indicated:</p>

<blockquote>
<p>
-2- <tt>Compare</tt> is a function object type (20.9 [function.objects]). The return value of the function 
call operation applied to an object of type <tt>Compare</tt>, when <ins>implicitly or</ins> contextually converted 
to <tt>bool</tt> (4 [conv]), yields <tt>true</tt> if the first argument of the call is less than the second, and 
<tt>false</tt> otherwise. <tt>Compare comp</tt> is used throughout for algorithms assuming an ordering relation. It is assumed 
that <tt>comp</tt> will not apply any non-constant function through the dereferenced iterator.
</p>
</blockquote>
</li>

<li><p>Change 30.2.1 [thread.req.paramname] p2 as indicated:</p>

<blockquote>
<p>
-2- <del>If a parameter is <tt>Predicate</tt>, operator() applied to the actual template argument shall return a value that
is convertible to <tt>bool</tt></del><ins><tt>Predicate</tt> is a function object type (20.9 [function.objects]).
The return value of the function call operation applied to an object of type <tt>Predicate</tt>, when implicitly or 
contextually converted to <tt>bool</tt> (4 [conv]), yields <tt>true</tt> if the corresponding test condition is
satisfied, and <tt>false</tt> otherwise</ins>.
</p>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2014-05-20, Daniel suggests concrete wording based on STL's proposal]</i></p>

<p>
The presented wording follows relatively closely STL's outline with the following notable exceptions:
</p>
<ol style="list-style-type:upper-alpha">
<li><p>
A reference to <tt>BooleanTestable</tt> in table "Return Type" specifications seemed very unusual to me and
I found no "prior art" for this in the Standard. Instead I decided to follow the usual style to add a symbol
with a specific meaning to a specific paragraph that specifies symbols and their meanings.
</p></li>
<li><p>
STL's requirement IV suggested to directly refer to built-in operators <tt>&amp;&amp;</tt> and <tt>||</tt>. In my
opinion this concrete requirement isn't needed if we simply require that two <tt>BooleanTestable</tt> operands behave 
equivalently to two those operands after conversion to <tt>bool</tt> (each of them).
</p></li>
<li><p>
I couldn't find a good reason to require normatively that type <tt>bool</tt> meets the requirements of <tt>BooleanTestable</tt>: My
assertion is that after having defined them, the result simply falls out of this. But to make this a bit clearer, I added
also a non-normative note to these effects.
</p></li>
</ol>

<p><i>[2014-06-10, STL comments]</i></p>

<p>
In the current wording I would like to see changed the suggested changes described by bullet #6:
</p>
<ol style="list-style-type:upper-alpha">
<li><p>In 23.2.1 [container.requirements.general] p4 undo the suggested change</p></li>
<li><p>Then change the 7 occurrences of "convertible to <tt>bool</tt>" in the denoted tables to "<tt>bool</tt>".</p></li>
</ol>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 17.6.3.1 [utility.arg.requirements] p1, Table 17 &mdash; "EqualityComparable requirements", and
Table 18 &mdash; "LessThanComparable requirements" as indicated:</p>

<blockquote>
<p>
-1- [&hellip;] In these tables, <tt>T</tt> is an object or reference type to be supplied by a C++ program
instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are values of type (possibly <tt>const</tt>) <tt>T</tt>; 
<tt>s</tt> and <tt>t</tt> are modifiable lvalues of type <tt>T</tt>; <tt>u</tt> denotes an identifier; <tt>rv</tt> 
is an rvalue of type <tt>T</tt>; <del>and</del> <tt>v</tt> is an lvalue of type (possibly <tt>const</tt>) <tt>T</tt> or an
rvalue of type <tt>const T</tt><ins>; and <tt>BT</tt> denotes a type that meets the <tt>BooleanTestable</tt> 
requirements ([booleantestable.requirements])</ins>.
<p/>
[&hellip;]
</p>
<blockquote>
<table border="1">
<caption>Table 17 &mdash; <tt>EqualityComparable</tt> requirements [equalitycomparable]</caption>
<tr>
<th align="center">Expression</th>
<th align="center">Return type</th>
<th align="center">Requirement</th>
</tr>

<tr>
<td>
<tt>a == b</tt>
</td>
<td>
<del>convertible to<br/>
<tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
<tt>==</tt> is an equivalence relation, that is, it has the
following properties: [&hellip;]
</td>
</tr>

</table>
</blockquote>
<p>
[&hellip;]
</p>
<blockquote>
<table border="1">
<caption>Table 18 &mdash; <tt>LessThanComparable</tt> requirements [lessthancomparable]</caption>
<tr>
<th align="center">Expression</th>
<th align="center">Return type</th>
<th align="center">Requirement</th>
</tr>

<tr>
<td>
<tt>a &lt; b</tt>
</td>
<td>
<del>convertible to<br/>
<tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
<tt>&lt;</tt> is a strict weak ordering relation (25.4 [alg.sorting])
</td>
</tr>

</table>
</blockquote>

</blockquote>

</li>

<li><p>Between 17.6.3.2 [swappable.requirements] and 17.6.3.3 [nullablepointer.requirements] insert a new sub-clause 
as indicated:</p>

<blockquote>
?.?.?.? <b><tt>BooleanTestable</tt> requirements [booleantestable.requirements]</b>  
<blockquote>
<p>
-?- A <tt>BooleanTestable</tt> type is a boolean-like type that also supports conversions to <tt>bool</tt>.
A type <tt>B</tt> meets the <tt>BooleanTestable</tt> requirements if the expressions described in Table ?? are valid 
and have the indicated semantics, and if <tt>B</tt> also satisfies all the other requirements of this sub-clause 
[booleantestable.requirements].
<p/>
An object <tt>b</tt> of type <tt>B</tt> can be implicitly converted to <tt>bool</tt> and can be contextually converted 
to <tt>bool</tt> (Clause 4). The result values of both kinds of conversions shall be equivalent. 
<p/>
[<i>Example</i>: The types <tt>bool</tt>, <tt>std::true_type</tt>, and <tt>std::bitset&lt;&gt;::reference</tt> are 
<tt>BooleanTestable</tt> types. &mdash; <i>end example</i>]
<p/>
In Table ??, <tt>B2</tt> and <tt>Bn</tt> denote types (possibly equal to <tt>B</tt> or to each other) that meet the 
<tt>BooleanTestable</tt> requirements, <tt>b1</tt> denotes a (possibly <tt>const</tt>) value of <tt>B</tt>, <tt>b2</tt> 
denotes a (possibly <tt>const</tt>) value of <tt>B2</tt>, and <tt>t1</tt> denotes a value of type <tt>bool</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Somewhere within the new sub-clause [booleantestable.requirements] insert the following new Table (?? denotes
the assigned table number):</p>

<blockquote>
<table border="1">
<caption>Table ?? &mdash; <tt>BooleanTestable</tt> requirements [booleantestable]</caption>
<tr>
<th align="center">Expression</th>
<th align="center">Return type</th>
<th align="center">Operational semantics</th>
</tr>

<tr>
<td>
<tt>bool(b1)</tt>
</td>
<td>
<tt>bool</tt>
</td>
<td>
<i>Remarks</i>: <tt>bool(b1) == t1</tt> for every value<br/>
<tt>b1</tt> implicitly converted to <tt>t1</tt>.
</td>
</tr>

<tr>
<td>
<tt>!b1</tt>
</td>
<td>
<tt>Bn</tt>
</td>
<td>
<i>Remarks</i>: <tt>bool(b1) == !bool(!b1)</tt> for<br/>
every value <tt>b1</tt>.
</td>
</tr>

<tr>
<td>
<tt>b1 &amp;&amp; b2</tt>
</td>
<td>
<tt>bool</tt>
</td>
<td>
<tt>bool(b1) &amp;&amp; bool(b2)</tt>
</td>
</tr>

<tr>
<td>
<tt>b1 || b2</tt>
</td>
<td>
<tt>bool</tt>
</td>
<td>
<tt>bool(b1) || bool(b2)</tt>
</td>
</tr>

</table>
</blockquote>

</li>

<li><p>Change 17.6.3.3 [nullablepointer.requirements] p5 and Table 25 &mdash; "NullablePointer requirements" as indicated:</p>

<blockquote>
<p>
[&hellip;]
<p/>
-5- In Table 25, <tt>u</tt> denotes an identifier, <tt>t</tt> denotes a non-<tt>const</tt> lvalue of type <tt>P</tt>, <tt>a</tt> 
and <tt>b</tt> denote values of type (possibly <tt>const</tt>) <tt>P</tt>, <del>and</del> <tt>np</tt> denotes a value of type 
(possibly <tt>const</tt>) <tt>std::nullptr_t</tt><ins>, and <tt>BT</tt> denotes a type that meets the <tt>BooleanTestable</tt> 
requirements ([booleantestable.requirements])</ins>.
<p/>
[&hellip;]
</p>
<blockquote>
<table border="1">
<caption>Table 25 &mdash; <tt>NullablePointer</tt> requirements [nullablepointer]</caption>
<tr>
<th align="center">Expression</th>
<th align="center">Return type</th>
<th align="center">Operational semantics</th>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>a != b</tt>
</td>
<td>
<del>contextually convertible to <tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>

<tr>
<td>
<tt>a == np</tt><br/>
<tt>np == a</tt>
</td>
<td>
<del>contextually convertible to <tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>

<tr>
<td>
<tt>a != np</tt><br/>
<tt>np != a</tt>
</td>
<td>
<del>contextually convertible to <tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>

</table>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.4.2.7 [tuple.rel] as indicated;</p>

<blockquote>
<pre>
template&lt;class... TTypes, class... UTypes&gt;
constexpr bool operator==(const tuple&lt;TTypes...&gt;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);
</pre>
<blockquote>
<p>
-1- <i>Requires</i>: For all <tt>i</tt>, where <tt>0 &lt;= i</tt> and <tt>i &lt; sizeof...(TTypes)</tt>, 
<tt>get&lt;i&gt;(t) == get&lt;i&gt;(u)</tt> is a valid expression returning a type that <del>is convertible to 
<tt>bool</tt></del><ins>meets the <tt>BooleanTestable</tt> requirements ([booleantestable.requirements])</ins>. 
<tt>sizeof...(TTypes) == sizeof...(UTypes)</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;class... TTypes, class... UTypes&gt;
constexpr bool operator&lt;(const tuple&lt;TTypes...&gt;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);
</pre>
<blockquote>
<p>
-4- <i>Requires</i>: For all <tt>i</tt>, where <tt>0 &lt;= i</tt> and <tt>i &lt; sizeof...(TTypes)</tt>, 
<tt>get&lt;i&gt;(t) &lt; get&lt;i&gt;(u)</tt> and <tt>get&lt;i&gt;(u) &lt; get&lt;i&gt;(t)</tt> are valid 
expressions returning types that <del>are convertible to 
<tt>bool</tt></del><ins>meet the <tt>BooleanTestable</tt> requirements ([booleantestable.requirements])</ins>. 
<tt>sizeof...(TTypes) == sizeof...(UTypes)</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 23.2.1 [container.requirements.general], Table 96 &mdash; "Container requirements", and
Table 98 &mdash; "Optional container operations" as indicated:</p>

<blockquote>
<p>
-4- In Tables 96, 97, and 98 <tt>X</tt> denotes a container class containing objects of type <tt>T</tt>, <tt>a</tt> and 
<tt>b</tt> denote values of type <tt>X</tt>, <tt>u</tt> denotes an identifier, <tt>r</tt> denotes a non-<tt>const</tt> value 
of type <tt>X</tt>, <del>and</del> <tt>rv</tt> denotes a non-<tt>const</tt> rvalue of type <tt>X</tt><ins>, and <tt>BT</tt> 
denotes a type that meets the <tt>BooleanTestable</tt> requirements ([booleantestable.requirements])</ins>.
</p>
<blockquote>
<table border="1">
<caption>Table 96 &mdash; Container requirements</caption>
<tr>
<th align="center">Expression</th>
<th align="center">Return type</th>
<th align="center">[&hellip;]</th>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>a == b</tt>
</td>
<td>
<del>convertible to<br/>
<tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>

<tr>
<td>
<tt>a != b</tt>
</td>
<td>
<del>convertible to<br/>
<tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>a.empty()</tt>
</td>
<td>
<del>convertible to<br/>
<tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>

</table>
</blockquote>
<p>
[&hellip;]
</p>
<blockquote>
<table border="1">
<caption>Table 98 &mdash; Optional container requirements</caption>
<tr>
<th align="center">Expression</th>
<th align="center">Return type</th>
<th align="center">[&hellip;]</th>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>a &lt; b</tt>
</td>
<td>
<del>convertible to<br/>
<tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>

<tr>
<td>
<tt>a &gt; b</tt>
</td>
<td>
<del>convertible to<br/>
<tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>

<tr>
<td>
<tt>a &lt;= b</tt>
</td>
<td>
<del>convertible to<br/>
<tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>

<tr>
<td>
<tt>a &gt;= b</tt>
</td>
<td>
<del>convertible to<br/>
<tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>

</table>
</blockquote>
</blockquote>
</li>

<li><p>Change 24.2.1 [iterator.requirements.general], Table 107 &mdash; "Input iterator requirements", and
Table 111 &mdash; "Random access iterator requirements" as indicated:</p>

<blockquote>
<p>
-11- In the following sections, <tt>a</tt> and <tt>b</tt> denote values of type <tt>X</tt> or <tt>const X</tt>, 
<tt>difference_type</tt> and <tt>reference</tt> refer to the types <tt>iterator_traits&lt;X&gt;::difference_type</tt> and 
<tt>iterator_traits&lt;X&gt;::reference</tt>, respectively, <tt>n</tt> denotes a value of <tt>difference_type</tt>, <tt>u</tt>, 
<tt>tmp</tt>, and <tt>m</tt> denote identifiers, <tt>r</tt> denotes a value of <tt>X&amp;</tt>, <tt>t</tt> denotes
a value of value type <tt>T</tt>, <tt>o</tt> denotes a value of some type that is writable to the output iterator<ins>, and <tt>BT</tt> 
denotes a type that meets the <tt>BooleanTestable</tt> requirements ([booleantestable.requirements])</ins>.
</p>
<blockquote>
<table border="1">
<caption>Table 107 &mdash; Input iterator requirements</caption>
<tr>
<th align="center">Expression</th>
<th align="center">Return type</th>
<th align="center">[&hellip;]</th>
</tr>

<tr>
<td>
<tt>a != b</tt>
</td>
<td>
<del>contextually convertible to<br/>
<tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>
</table>
</blockquote>
<p>
[&hellip;]
</p>
<blockquote>
<table border="1">
<caption>Table 111 &mdash; Random access iterator requirements</caption>
<tr>
<th align="center">Expression</th>
<th align="center">Return type</th>
<th align="center">[&hellip;]</th>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>a &lt; b</tt>
</td>
<td>
<del>contextually convertible to<br/>
<tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>

<tr>
<td>
<tt>a &gt; b</tt>
</td>
<td>
<del>contextually convertible to<br/>
<tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>

<tr>
<td>
<tt>a &gt;= b</tt>
</td>
<td>
<del>contextually convertible to<br/>
<tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>

<tr>
<td>
<tt>a &lt;= b</tt>
</td>
<td>
<del>contextually convertible to<br/>
<tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>

</table>
</blockquote>
</blockquote>
</li>

<li><p>Change 25.1 [algorithms.general] p8+p9 as indicated: [<i>Drafting note</i>: The wording change also fixes
(a) unusual wording forms used ("should work") which are unclear in which sense they are imposing normative requirements and
(b) the problem, that the current wording seems to allow that the predicate may mutate a call argument, if that is not a 
dereferenced iterator.
Upon applying the new wording it became obvious that the wording has the effect that currently algorithms such as
<tt>adjacent_find</tt>, <tt>search_n</tt>, <tt>unique</tt>, and <tt>unique_copy</tt> are not correctly described 
(because they have no iterator argument named <tt>first1</tt>), which could give raise to a new library issue. 
&mdash; <i>end drafting note</i>]</p>

<blockquote>
<p>
-8- The <tt>Predicate</tt> parameter is used whenever an algorithm expects a function object (20.9) that, when applied
to the result of dereferencing the corresponding iterator, returns a value testable as <tt>true</tt>. <del>In other words,
i</del><ins>I</ins>f an algorithm takes <tt>Predicate pred</tt> as its argument and <tt>first</tt> as its iterator argument, 
<del>it should work correctly in the construct <tt>pred(*first)</tt> contextually converted to 
<tt>bool</tt> (Clause 4)</del><ins>the expression <tt>pred(*first)</tt> shall have a type that meets the <tt>BooleanTestable</tt> 
requirements ( [booleantestable.requirements])</ins>. 
The function object <tt>pred</tt> shall not apply any non-constant function through <del>the dereferenced 
iterator</del><ins>its argument</ins>.
<p/>
-9- The <tt>BinaryPredicate</tt> parameter is used whenever an algorithm expects a function object that when applied
to the result of dereferencing two corresponding iterators or to dereferencing an iterator and type
<tt>T</tt> when <tt>T</tt> is part of the signature returns a value testable as <tt>true</tt>. <del>In other words, 
i</del><ins>I</ins>f an algorithm takes <tt>BinaryPredicate binary_pred</tt> as its argument and <tt>first1</tt> and 
<tt>first2</tt> as its iterator arguments, <del>it should work correctly in the construct <tt>binary_pred(*first1, *first2)</tt> 
contextually converted to <tt>bool</tt> (Clause 4)</del><ins>the expression <tt>binary_pred(*first1, *first2)</tt> shall 
have a type that meets the <tt>BooleanTestable</tt> requirements ( [booleantestable.requirements])</ins>. 
<tt>BinaryPredicate</tt> always takes the first iterator's <tt>value_type</tt> as its first argument, that is, in those cases 
when <tt>T</tt> value is part of the signature, <del>it should work correctly in the construct <tt>binary_pred(*first1, value)</tt> 
contextually converted to <tt>bool</tt> (Clause 4)</del><ins>the expression <tt>binary_pred(*first1, value)</tt> shall have a 
type that meets the <tt>BooleanTestable</tt> requirements ( [booleantestable.requirements])</ins>. <tt>binary_pred</tt> 
shall not apply any non-constant function through <del>the dereferenced iterators</del><ins>any of its arguments</ins>.
</p>
</blockquote>
</li>

<li><p>Change 25.4 [alg.sorting] p2 as indicated:</p>

<blockquote>
<p>
[&hellip;]
<p/>
-2- <tt>Compare</tt> is a function object type (20.9). <del>The return value of the function call 
operation applied to an object of type <tt>Compare</tt>, when contextually converted 
to <tt>bool</tt>(Clause 4), yields <tt>true</tt> if the first argument of the call is less than the second, 
and <tt>false</tt> otherwise.</del> <tt>Compare comp</tt> is used throughout for algorithms assuming an ordering relation. 
<ins>Let <tt>a</tt> and <tt>b</tt> denote two argument values whose types depend on the corresponding algorithm. Then the expression 
<tt>comp(a, b)</tt> shall have a type that meets the <tt>BooleanTestable</tt> requirements ( [booleantestable.requirements]).
The return value of <tt>comp(a, b)</tt>, converted to <tt>bool</tt>, yields <tt>true</tt> if the 
first argument <tt>a</tt> is less than the second argument <tt>b</tt>, and <tt>false</tt> otherwise.</ins> It is assumed that 
<tt>comp</tt> will not apply any non-constant function through <del>the dereferenced iterator</del><ins>any of its arguments</ins>.
<p/>
[&hellip;]
</p>
</blockquote>
</li>

<li><p>Change 27.5.4.2 [fpos.operations] and Table 127 &mdash; "Position type requirements" as indicated:</p>

<blockquote>
<p>
-1- Operations specified in Table 127 are permitted. In that table,
</p>
<ul>
<li><p><tt>P</tt> refers to an instance of <tt>fpos</tt>,</p></li>
<li><p>[&hellip;]</p></li>
<li><p><tt>o</tt> refers to a value of type <tt>streamoff</tt>,</p></li>
<li><p><ins><tt>BT</tt> refers to a type that meets the <tt>BooleanTestable</tt> requirements ([booleantestable.requirements]),</ins></p></li>
<li><p>[&hellip;]</p></li>
</ul>
<blockquote>
<table border="1">
<caption>Table 127 &mdash; Position type requirements</caption>
<tr>
<th align="center">Expression</th>
<th align="center">Return type</th>
<th align="center">[&hellip;]</th>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>p == q</tt>
</td>
<td>
<del>convertible to <tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>

<tr>
<td>
<tt>p != q</tt>
</td>
<td>
<del>convertible to <tt>bool</tt></del><ins><tt>BT</tt></ins>
</td>
<td>
[&hellip;]
</td>
</tr>

</table>
</blockquote>
</blockquote>
<blockquote>
</blockquote>
</li>

<li><p>Change 30.2.1 [thread.req.paramname] p2 as indicated:</p>

<blockquote>
<p>
-2- <del>If a parameter is <tt>Predicate</tt>, <tt>operator()</tt> applied to the actual template argument shall return a value that
is convertible to <tt>bool</tt></del><ins><tt>Predicate</tt> is a function object type (20.9 [function.objects]).
Let <tt>pred</tt> denote an lvalue of type <tt>Predicate</tt>. Then the expression <tt>pred()</tt> shall have a type that meets the 
<tt>BooleanTestable</tt> requirements ( [booleantestable.requirements]). The return value of <tt>pred()</tt>, 
converted to <tt>bool</tt>, yields <tt>true</tt> if the corresponding test condition is satisfied, and <tt>false</tt> otherwise</ins>.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2115"></a>2115. Undefined behaviour for <tt>valarray</tt> assignments with <tt>mask_array</tt> index?</h3>
<p><b>Section:</b> 26.6.8 [template.mask.array] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2011-12-10 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Recently I received a Service Request (SR) alleging that one of our testcases causes an 
undefined behavior. The complaint is that 26.6.8 [template.mask.array] in C++11 
(and the corresponding subclause in C++03) are interpreted by some people to require that 
in an assignment "<tt>a[mask] = b</tt>", the subscript <tt>mask</tt> and the rhs <tt>b</tt> 
must have the same number of elements.
<p/>
IMHO, if that is the intended requirement, it should be stated explicitly.
<p/>
In any event, there is a tiny editorial cleanup that could be made:
<p/>
In C++11, 26.6.8.1 [template.mask.array.overview] para 2 mentions
</p>
<blockquote><p>
"the expression <tt>a[mask] = b;</tt>"
</p></blockquote>
<p>
but the semicolon cannot be part of an expression. The correction could omit the 
semicolon, or change the word "expression" to "assignment" or "statement".
<p/>
Here is the text of the SR, slightly modified for publication:
</p>
<blockquote>
<p>
Subject:  SR01174 LVS _26322Y31 has undefined behavior [open]
<p/>
[Client:]<br/>
The test case t263.dir&#47;_26322Y31.cpp seems to be illegal as it has an undefined 
behaviour. I searched into the SRs but found SRs were not related to the topic 
explained in this mail (SR00324, SR00595, SR00838).
</p>
<blockquote><pre>
const char vl[] = {"abcdefghijklmnopqrstuvwxyz"};
const char vu[] = {"ABCDEFGHIJKLMNOPQRSTUVWXYZ"};
const std::valarray&lt;char&gt; v0(vl, 27), vm5(vu, 5), vm6(vu, 6);
std::valarray&lt;char&gt; x = v0;
[&hellip;]
const bool vb[] = {false, false, true, true, false, true};
const std::valarray&lt;bool&gt; vmask(vb, 6);
x = v0;
x[vmask] = vm5;      // ***** HERE....
steq(&amp;x[0], "abABeCghijklmnopqrstuvwxyz");
x2 = x[vmask];       // ***** ....AND HERE
[&hellip;]
</pre></blockquote>
<p>
This problem has already been discussed between [experts]:
See thread <a href="http://gcc.gnu.org/ml/libstdc++/2009-11/threads.html#00051">http:&#47;&#47;gcc.gnu.org&#47;ml&#47;libstdc++&#47;2009-11&#47;threads.html#00051</a> 
Conclusion <a href="http://gcc.gnu.org/ml/libstdc++/2009-11/msg00099.html">http:&#47;&#47;gcc.gnu.org&#47;ml&#47;libstdc++&#47;2009-11&#47;msg00099.html</a>
<p/>
[Plum Hall:]<br/>
Before I log this as an SR, I need to check one detail with you.
<p/>
I did read the email thread you mentioned, and I did find a citation (see INCITS ISO&#47;IEC 14882-2003 
Section 26.3.2.6 on valarray computed assignments):
<p/>
Quote: "If the array and the argument array do not have the same length, the behavior is undefined",
<p/>
But this applies to computed assignment (<tt>*=</tt>, <tt>+=</tt>, etc), not to simple assignment. Here is the C++03 citation 
re simple assignment:
<p/>
26.3.2.2 valarray assignment [lib.valarray.assign]
</p>
<blockquote><pre>
valarray&lt;T&gt;&amp; operator=(const valarray&lt;T&gt;&amp;);
</pre><blockquote>
<p>
1 Each element of the <tt>*this</tt> array is assigned the value of the corresponding element of the argument array.
The resulting behavior is undefined if the length of the argument array is not equal to the length of the
<tt>*this</tt> array.
</p>
</blockquote></blockquote>
<p>
In the new C++11 (N3291), we find ...
<p/>
26.6.2.3 valarray assignment [valarray.assign]
</p>
<blockquote><pre>
valarray&lt;T&gt;&amp; operator=(const valarray&lt;T&gt;&amp; v);
</pre><blockquote>
<p>
1 Each element of the <tt>*this</tt> array is assigned the value of the corresponding element of the argument
array. If the length of <tt>v</tt> is not equal to the length of <tt>*this</tt>, resizes <tt>*this</tt> to make 
the two arrays the same length, as if by calling <tt>resize(v.size())</tt>, before performing the assignment.
</p>
</blockquote></blockquote>
<p>
So it looks like the testcase might be valid for C++11 but not for C++03; what do you think?
<p/>
[Client:]<br/>
I quite agree with you but the two problems I mentioned:
</p>
<blockquote><pre>
x[vmask] = vm5;      // ***** HERE....
[&hellip;]
x2 = x[vmask];       // ***** ....AND HERE
</pre></blockquote>
<p>
refer to <tt>mask_array</tt> assignment hence target the C++03 26.3.8 paragraph. Correct?
<p/>
[Plum Hall:]<br/>
I mentioned the contrast between C++03 26.3.2.2 para 1 versus C++11 26.6.2.3 para 1.
<p/>
But in C++03 26.3.8, I don't find any corresponding restriction. Could you quote the specific 
requirement you're writing about?
<p/>
[Client:]<br/>
I do notice the difference between c++03 26.3.2.2 and c++11 26.6.2.3 about assignments between 
different sized <tt>valarray</tt> and I perfectly agree with you.
<p/>
But, as already stated, this is not a simple <tt>valarray</tt> assignment but a
<tt>mask_array</tt> assignment (c++03 26.3.8 &#47; c++11 26.6.8). See c++11 quote below:
<p/>
26.6.8 Class template mask_array<br/>
26.6.8.1 Class template mask_array overview<br/>
[....]
</p>
<ol>
<li><p>This template is a helper template used by the mask subscript operator:
<tt>mask_array&lt;T&gt; valarray&lt;T&gt;::operator[](const valarray&lt;bool&gt;&amp;)</tt>.
</p></li>
<li><p>It has reference semantics to a subset of an array specified by a boolean mask. Thus, 
the expression <tt>a[mask] = b;</tt> has the effect of assigning <em>the elements of <tt>b</tt></em> 
to the masked elements in <tt>a</tt> (those for which the corresponding element in <tt>mask</tt> is true.)
</p></li>
</ol>
<p>
26.6.8.2 mask_array assignment
</p>
<blockquote><pre>
void operator=(const valarray&lt;T&gt;&amp;) const;
const mask_array&amp; operator=(const mask_array&amp;) const;
</pre><blockquote>
<p>
1 These assignment operators have reference semantics, assigning the values of the argument array 
elements to selected elements of the <tt>valarray&lt;T&gt;</tt> object to which it refers.
</p>
</blockquote></blockquote>
<p>
In particular, [one of the WG21 experts] insisted on the piece "the elements of <tt>b</tt>".
<p/>
That is why I reported the test t263.dir&#47;_26322Y31.cpp having an undefined behaviour.
<p/>
[Plum Hall:]<br/>
OK, I can see that I will have to ask WG21; I will file an appropriate issue 
with the Library subgroup. In the meantime, I will mark this testcase as "DISPUTED" 
so that it is not required for conformance testing, until we get a definitive opinion.
</p>
</blockquote>

<p><i>[2012, Kona]</i></p>

<p>
Moved to Open.
</p>
<p>
There appears to be a real need for clarification in the standard, and
implementations differ in their current interpretation.  This will need
some research by implementers and a proposed resolution before further
discussion is likely to be fruitful.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2116"></a>2116. <tt>std::swap noexcept(what?)</tt></h3>
<p><b>Section:</b> 20.10.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2011-12-09 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
IMO if we specified <tt>is_[nothrow_]constructible</tt> in terms of a variable
declaration whose validity requires destructibility, it is clearly a bug
in our specification and a failure to realize the actual original
intent. The specification should have been in terms of placement-new.
<p/>
Daniel:<br/>
At the time of the specification this was intended and the solution is
<em>not</em> done by removing the destruction semantics of <tt>is_constructible</tt>.
<p/>
The design of <tt>is_constructible</tt> was also impacted by the previous
<tt>Constructible</tt> concept that <em>explicitly</em> contained destruction semantics,
because during conceptification of the library it turned out to simplify
the constraints  in the library because you did not need to add
<tt>Destructible</tt> all the time. It often was implied but never spoken out
in C++03.
<p/>
Pure construction semantics was considered as useful as well, so <tt>HasConstructor</tt> 
did also exist and would surely be useful as trait as well.
<p/>
Another example that is often overlooked: This also affects wrapper types like <tt>pair</tt>, 
<tt>tuple</tt>, <tt>array</tt> that contain potentially more than one type:
This is easy to understand if you think of <tt>T1</tt> having a deleted destructor
and <tt>T2</tt> having a constructor that may throw: Obviously the compiler has
potentially need to use the <tt>destructor</tt> of <tt>T1</tt> in the <em>constructor</em>
of <tt>std::pair&lt;T1, T2&gt;</tt> to ensure that the core language requirements
are satisfied (All previous fully constructed sub-objects must be destructed).
<p/>
The core language also honors this fact in 12.8 [class.copy] p11:
</p>
<blockquote><p>
A defaulted copy&#47;move constructor for a class <tt>X</tt> is defined as deleted (8.4.3 [dcl.fct.def.delete]) 
if <tt>X</tt> has:<br/>
[&hellip;]<br/>
&mdash; any direct or virtual base class or non-static data member of a type with a destructor that is deleted
or inaccessible from the defaulted constructor,<br/>
[&hellip;]
</p></blockquote>
<p>
Dave:<br/>
This is about <tt>is_nothrow_constructible</tt> in particular. The fact that it is 
foiled by not having a <tt>noexcept</tt> dtor is a defect.
</p>

<p><i>[2012, Kona]</i></p>

<p>
Move to Open.
</p>
<p>
<tt>is_nothrow_constructible</tt> is defined in terms of <tt>is_constructible</tt>, which is defined
by looking at a hypothetical variable and asking whether the variable definition is known not to
throw exceptions. The issue claims that this also examines the type's destructor, given the context,
and thus will return <tt>false</tt> if the destructor can potentially throw. At least one
implementation (Howard's) does return <tt>false</tt> if the constructor is <tt>noexcept(true)</tt>
and the destructor is <tt>noexcept(false)</tt>. So that's not a strained interpretation.
The issue is asking for this to be defined in terms of placement <tt>new</tt>, instead of in terms
of a temporary object, to make it clearer that <tt>is_nothrow_constructible</tt> looks at the
<tt>noexcept</tt> status of only the constructor, and not the destructor.
</p>
<p>
Sketch of what the wording would look like:
</p>
<p>
require <tt>is_constructible</tt>, and then also require that a placement <tt>new</tt> operation
does not throw. (Remembering the title of this issue... What does this imply for <tt>swap</tt>?
</p>
<p>
If we accept this resolution, do we need any changes to <tt>swap</tt>?
</p>
<p> STL argues: no, because you are already forbidden from passing anything with a throwing
desturctor to <tt>swap</tt>.
</p>
<p>
Dietmar argues: no, not true. Maybe statically the destructor can conceivably throw for some
values, but maybe there are some values known not to throw. In that case, it's correct to
pass those values to <tt>swap</tt>.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2117"></a>2117. <tt>ios_base</tt> manipulators should have <tt>showgrouping&#47;noshowgrouping</tt></h3>
<p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals], 27.5.3.1.2 [ios::fmtflags], 27.5.6.1 [fmtflags.manip] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Benjamin Kosnik <b>Opened:</b> 2011-12-15 <b>Last modified:</b> 2014-02-20</p>
<p><b>View all other</b> <a href="lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Iostreams should include a manipulator to toggle grouping on&#47;off for
locales that support grouped digits. This has come up repeatedly and
been deferred. See LWG <a href="lwg-closed.html#826">826</a> for the previous attempt.
<p/>
If one is using a locale that supports grouped digits, then output
will always include the generated grouping characters. However, very
plausible scenarios exist where one might want to output the number,
un-grouped. This is similar to existing manipulators that toggle
on&#47;off the decimal point, numeric base, or positive sign.
<p/>
See some user commentary <a href="http://www.tablix.org/~avian/blog/archives/2008/01/c_streams_suck/">here</a>.
</p>


<p><i>[21012, Kona]</i></p>

<p>
Move to Open.
</p>
<p>
This is a feature request.
</p>
<p>
Walter is slightly uncomfortable with processing feature requests through the issues lists.
</p>
<p>
Alisdair says this is far from the first feature request that has come in from the issues list.
</p>
<p>
STL: The fact that you can turn off grouping on hex output is compelling.
</p>
<p>
Marshall: if we add this flag, we'll need to update tables 87-91 as well.
</p>
<p>
STL: If it has been implemented somewhere, and it works, we'd be glad to add it.
</p>
<p>
Howard: We need to say what the default is.
</p>
<p>
Alisdair sumarizes:
</p>
<p>
(1) We want clear wording that says what the effect is of turning the flag off;
</p>
<p>
(2) what the default values are, and
</p>
<p>
(3) how this fits into tables 87-90. (and 128)
</p>

<p><i>[Issaquah 2014-02-10-12: Move to LEWG]</i></p>

<p>
Since this issue was filed, we have grown a new working group that is better placed to handle feature requests.
</p>
<p>
We will track such issues with an LEWG status until we get feedback from the Library Evolution Working Group.
</p>

<p><i>[Issaquah 2014-02-12: LEWG discussion]</i></p>


<table>
  <caption>Do we think this feature should exist?</caption>
  <tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr>
  <tr><td>2</td> <td>4</td><td>1</td><td>0</td><td>0</td></tr>
</table>

<p>Think about the ABI break for adding a flag. But this could be
mitigated by putting the data into an iword instead of a flag.</p>

<p>This needs to change Stage 2 in [facet.num.put.virtuals].</p>

<p>Previous resolution, which needs the above corrections:</p>
<blockquote class="note">
<p>This wording is relative to the FDIS.</p>

<ol>
<li>
<p>Insert in 22.4.2.2.2 [facet.num.put.virtuals] paragraph 5:</p>

<blockquote><p>
<strong>Stage 1</strong>: The first action of stage 1 is to determine a conversion specifier. The tables that describe
this determination use the following local variables
</p>
<pre>
fmtflags flags = str.flags() ;
fmtflags basefield = (flags &amp; (ios_base::basefield));
fmtflags uppercase = (flags &amp; (ios_base::uppercase));
fmtflags floatfield = (flags &amp; (ios_base::floatfield));
fmtflags showpos = (flags &amp; (ios_base::showpos));
fmtflags showbase = (flags &amp; (ios_base::showbase));
<ins>fmtflags showgrouping = (flags &amp; (ios_base::showgrouping));</ins>
</pre>
</blockquote>
</li>

<li><p>Change header <tt>&lt;ios&gt;</tt> synopsis, 27.5.1 [iostreams.base.overview] as indicated:</p>

<blockquote><pre>
#include &lt;iosfwd&gt;

namespace std {
  [&hellip;]
  <i>// 27.5.6, manipulators:</i>
  [&hellip;]
  ios_base&amp; showpoint     (ios_base&amp; str);
  ios_base&amp; noshowpoint   (ios_base&amp; str);
  <ins>ios_base&amp; showgrouping  (ios_base&amp; str);</ins>
  <ins>ios_base&amp; noshowgrouping(ios_base&amp; str);</ins>
  ios_base&amp; showpos       (ios_base&amp; str);
  ios_base&amp; noshowpos     (ios_base&amp; str);
  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Change class <tt>ios_base</tt> synopsis, 27.5.3 [ios.base] as indicated:</p>

<blockquote><pre>
namespace std {
  class ios_base {
  public:
  class failure;
    <i>// 27.5.3.1.2 fmtflags</i>
    typedef <i>T1</i> fmtflags;
    [&hellip;]
    static constexpr fmtflags showpoint = <i>unspecified</i> ;
    <ins>static constexpr fmtflags showgrouping = <i>unspecified</i> ;</ins>
    static constexpr fmtflags showpos = <i>unspecified</i> ;
    [&hellip;]
  };
}
</pre></blockquote>
</li>

<li><p>Add a new entry to Table 122 &mdash; "<tt>fmtflags</tt> effects" as indicated:</p>

<table border="1">
<caption>Table 122 &mdash; <tt>fmtflags</tt> effects</caption>
<tr align="center">
<th>Element</th>
<th>Effect(s) if set</th>
</tr> 

<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

<tr>
<td>
<tt>showpoint</tt>
</td>
<td>
generates a decimal-point character unconditionally in generated floatingpoint output
</td>
</tr>

<tr>
<td>
<ins><tt>showgrouping</tt></ins>
</td>
<td>
<ins>generates grouping characters unconditionally in generated output</ins>
</td>
</tr>

<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

</table>
 
</li>

<li><p>After 27.5.3.1.2 [ios::fmtflags] p12 insert the following:</p>
<blockquote><pre>
<ins>ios_base&amp; showgrouping(ios_base&amp; str);</ins>
</pre><blockquote>
<p>
<ins>-?- <i>Effects</i>: Calls <tt>str.setf(ios_base::showgrouping)</tt>.</ins>
<p/>
<ins>-?- <i>Returns</i>: <tt>str</tt>.</ins>
</p>
</blockquote>
<pre>
<ins>ios_base&amp; noshowgrouping(ios_base&amp; str);</ins>
</pre><blockquote>
<p>
<ins>-?- <i>Effects</i>: Calls <tt>str.unsetf(ios_base::showgrouping)</tt>.</ins>
<p/>
<ins>-?- <i>Returns</i>: <tt>str</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

</ol>

</blockquote>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2118"></a>2118. [CD] <tt>unique_ptr</tt> for array does not support <i>cv</i> qualification conversion of actual argument</h3>
<p><b>Section:</b> 20.8.1.3 [unique.ptr.runtime] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Alf P. Steinbach <b>Opened:</b> 2011-12-16 <b>Last modified:</b> 2014-07-01</p>
<p><b>View all other</b> <a href="lwg-index.html#unique.ptr.runtime">issues</a> in [unique.ptr.runtime].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses US 16</b></p>

<p>
N3290 20.8.1.3.1 [unique.ptr.runtime.ctor] "<tt>unique_ptr</tt> constructors":
</p>
<blockquote><p>
These constructors behave the same as in the primary template except that they do not accept pointer types 
which are convertible to <tt>pointer</tt>. [<i>Note:</i> One implementation technique is to create private 
templated overloads of these members. &mdash; <i>end note</i>]
</p></blockquote>
<p>
This language excludes even <tt>pointer</tt> itself as type for the actual argument.
<p/>
But of more practical concern is that both Visual C++ 10.0 and MinGW g++ 4.1.1 reject the code below, where 
only an implicit <i>cv</i> qualification is needed, which <i>cv</i> qualification is supported by the non-array 
version:
</p>
<blockquote><pre>
#include &lt;memory&gt;
using namespace std;

struct T {};

T* foo() { return new T; }
T const* bar() { return foo(); }

int main()
{
   unique_ptr&lt; T const &gt;       p1( bar() );        // OK
   unique_ptr&lt; T const [] &gt;    a1( bar() );        // OK

   unique_ptr&lt; T const &gt;       p2( foo() );        // OK
   unique_ptr&lt; T const [] &gt;    a2( foo() );        // <span style="color:#C80000;font-weight:bold">? this is line #15</span>
}
</pre></blockquote>
<p>
The <em>intent</em> seems to be clearly specified in 20.8.1.3 [unique.ptr.runtime]&#47;1 second bullet:
</p>
<blockquote><p>
&mdash; Pointers to types derived from <tt>T</tt> are rejected by the constructors, and by <tt>reset</tt>.
</p></blockquote>

<p>
But the following language in 20.8.1.3.1 [unique.ptr.runtime.ctor] then rejects far too much...
<p/>
Proposed new wording of N3290 20.8.1.3.1 [unique.ptr.runtime.ctor] "<tt>unique_ptr</tt> constructors":
</p>
<blockquote><p>
These constructors behave the same as in the primary template except that actual argument pointers <tt>p</tt> 
to types derived from <tt>T</tt> are rejected by the constructors. [<i>Note:</i> One implementation technique 
is to create private templated overloads of these members. &mdash; <i>end note</i>]
</p></blockquote>
<p>
This will possibly capture the intent better, and avoid the inconsistency between the non-array and array 
versions of <tt>unique_ptr</tt>, by using nearly the exact same phrasing as for the paragraph explaining 
the intent.
</p>

<p><i>[2012-08-25 Geoffrey Romer comments in <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=32978">c++std-lib-32978</a>]</i></p>


<ol>
<li><p>
The current P/R seems to intend to support at least two different implementation techniques &mdash; additional 
unusable templates that catch forbidden arguments or replacing existing constructors by templates that 
ensure ill-formed code inside the template body, when the requirements are not met. It seems unclear whether
the current wording allows the second approach, though. It should be considered to allow both strategies or
if that is not possible the note should be clearer.
</p></li>

<li><p>
The very same problem exists for the <tt>reset</tt> member function, but even worse, because the current
specification is more than clear that the deleted <tt>reset</tt> function will catch all cases not equal to 
<tt>pointer</tt>. It seems confusing at best to have different policies for the constructor and for the <tt>reset</tt> 
function. In this case, the question in regard to implementation freedom mentioned above is even more important.
</p></li>

<li><p>
It's awkward to refer to "the constructors" twice in the same sentence; I suggest revising the sentence as 
"...except that they do not accept argument pointers <tt>p</tt> to types derived from <tt>T</tt>"
</p></li>
</ol>

<p><i>[2012-12-20: Geoffrey Romer comments and provides a revised resolution]</i></p>


<p>
The array specialization of <tt>unique_ptr</tt> differs from the primary template in several ways,
including the following:
</p>
<ul>
<li><p>
<tt>unique_ptr&lt;T[], D&gt;</tt> cannot be constructed from a plain pointer whose type is not
exactly <tt>unique_ptr&lt;T[], D&gt;::pointer</tt> or <tt>nullptr_t</tt>.
</p></li>
<li><p>
<tt>unique_ptr&lt;T[], D&gt;</tt> cannot be constructed from a <tt>unique_ptr&lt;U[], E&gt;&amp;&amp;</tt> 
unless <tt>U</tt> is exactly <tt>T</tt> and <tt>E</tt> is exactly <tt>D</tt>.
</p></li>
<li><p>
<tt>unique_ptr&lt;T[], D&gt;</tt> cannot be moveassigned from a <tt>unique_ptr&lt;U[], E&gt;&amp;&amp;</tt> 
unless <tt>U</tt> is exactly <tt>T</tt> and <tt>E</tt> is exactly <tt>D</tt>.
</p></li>
<li><p>
<tt>unique_ptr&lt;T[], D&gt;::reset</tt> cannot take an argument whose type is not exactly
<tt>unique_ptr&lt;T[], D&gt;::pointer</tt> or <tt>nullptr_t</tt>.
</p></li>
<li><p>
<tt>default_delete&lt;T[]&gt;</tt> cannot be constructed from a <tt>default_delete&lt;U[]&gt;</tt> unless 
<tt>U</tt> is exactly <tt>T</tt>.
</p></li>
<li><p>
<tt>default_delete&lt;T[]&gt;::operator()</tt> cannot be called on a pointer whose type is not
exactly <tt>T*</tt>.
</p></li>
</ul>
<p>
The common intent of all these restrictions appears to be to disallow implicit conversions from
pointer-to-derived-class to pointer-to-base-class in contexts where the pointer is known to point
to an array, because such conversions are inherently unsafe; deleting or subscripting the result
of such a conversion leads to undefined behavior (see also CWG 1504). However, these restrictions 
have the effect of disallowing all implicit conversions in those contexts, including most notably 
cv-qualification, but also user-defined conversions, and possibly others. This PR narrows all those 
restrictions, to disallow only unsafe pointer-to-derived to pointer-to-base conversions, while 
allowing all others.
<p/>
I removed the nebulous language stating that certain functions "will not accept" certain arguments. 
Instead I use explicitly deleted template functions, which participate in overload resolution only 
for pointer-to-derived to pointer-to-base conversions. This is more consistent with the existing 
text and easier to express correctly than an approach based on declaring certain types of calls to 
be ill-formed, but may produce inferior compiler diagnostics.
<p/>
Wherever possible, this PR defines the semantics of template specializations in terms of their
differences from the primary template. This improves clarity and minimizes the risk of
unintended differences (e.g. LWG <a href="lwg-defects.html#2169">2169</a>, which this PR also fixes). This PR also makes it 
explicit that the specialization inherits the description of all members, not just member functions, 
from the primary template and, in passing, clarifies the default definition of pointer in the
specialization.
<p/>
This resolution only disallows pointer-to-derived to pointer-to-base conversions between
ordinary pointer types; if user-defined pointer types provide comparable conversions, it is their
responsibility to ensure they are safe. This is consistent with C++'s general preference for
expressive power over safety, and for assuming the user knows what they're doing;
furthermore, enforcing such a restriction on user-defined types appears to be impractical without
cooperation from the user.
<p/>
The "base class without regard to cv-qualifiers" language is intended to parallel the specification
of <tt>std::is_base_of</tt>.
<p/>
Jonathan Wakely has a working implementation of this PR patched into libstdc++.
</p>

<p>
Previous resolution:
</p>
<blockquote class="note">
<p>This wording is relative to the FDIS.</p>

<p>Change 20.8.1.3.1 [unique.ptr.runtime.ctor] as indicated:</p>

<blockquote><pre>
explicit unique_ptr(pointer p) noexcept;
unique_ptr(pointer p, <i>see below</i> d) noexcept;
unique_ptr(pointer p, <i>see below</i> d) noexcept;
</pre>
<blockquote><p>
These constructors behave the same as in the primary template except that <del>they do not accept pointer
types which are convertible to <tt>pointer</tt></del><ins>argument pointers <tt>p</tt> to types derived 
from <tt>T</tt> are rejected by the constructors</ins>. [<i>Note:</i> One implementation technique is to 
create private templated overloads of these members. &mdash; <i>end note</i>]
</p></blockquote></blockquote>
</blockquote>

<p><i>[2014-02, Issaquah]</i></p>

<p>
GR: want to prevent unsafe conversions. Standard is inconsistent how it does this. for <tt>reset()</tt> has deleted function 
template capturing everything except the known-safe cases. Other functions use SFINAE. Main reason this is hard is that 
<tt>unique_ptr</tt> supports fancy pointers. Have to figure out how to handle them and what requirements to put on them. 
Requirements are minimal, not even required to work with <tt>pointer_traits</tt>.
<p/>
STL surprised <tt>pointer_traits</tt> doesn't work
<p/>
GR: ways to get fancy pointers to work is to delegate responsibility for preventing unsafe conversions to the fancy pointers themselves. 
Howard doesn't like that, he wants even fancy pointers to be prevented from doing unsafe conversions in <tt>unique_ptr</tt> contexts.
<p/>
AM: Howard says <tt>unique_ptr</tt> was meant to be very very safe under all conditions, this open a hole in that. Howard wants to 
eke forward and support more, but not if we open any holes in type safety. 
<p/>
GR: do we need to be typesafe even for fancy types with incorrect <tt>pointer_traits</tt>?
<p/>
AM: that would mean it's only unsafe for people who lie by providing a broken specialization of <tt>pointer_traits</tt>
<p/>
GR: probably can't continue with ambiguity between using SFINAE and ill-formedness. Would appreciate guidance on direction used for that.
<p/>
STL: difference is observable in convertibility using type traits. 
<p/>
STL: for <tt>reset()</tt> which doesn't affect convertibility ill-formed allows <tt>static_assert</tt>, better diagnostic. 
For assignment it's detectable and has traits, constraining them is better.
<p/>
EN: I strongly prefer constraints than <tt>static_asserts</tt> 
<p/>
STL: if we could rely on <tt>pointer_traits</tt> that might be good. Alternatively could we add more machinery to deleter? 
make deleter say conversions are allowed, otherwise we lock down all conversions. basically want to know if converting <tt>U</tt> to 
<tt>T</tt> is safe.
</p>

<p>
<strong>Previous resolution [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to N3485.</p>
<ol>
<li><p>Revise 20.8.1.1.3 [unique.ptr.dltr.dflt1] as follows</p>
<blockquote><pre>
namespace std {
  template &lt;class T&gt; struct default_delete&lt;T[]&gt; {
    constexpr default_delete() noexcept = default;
    <ins>template &lt;class U&gt; default_delete(const default_delete&lt;U&gt;&amp;) noexcept;</ins>
    void operator()(T*) const;
    template &lt;class U&gt; void operator()(U*) const = delete;
  };
}
</pre></blockquote>
<p>
<ins>-?- Descriptions are provided below only for member functions that have behavior different from the
primary template.</ins>
</p>
<blockquote>
<pre>
<ins>template &lt;class U&gt; default_delete(const default_delete&lt;U&gt;&amp;) noexcept;</ins>
</pre>
<blockquote><p>
<ins>-?- This constructor behaves the same as in the primary template except that it shall not participate
in overload resolution unless:</ins>
</p>
<ul>
<li><p>
<ins><tt>U</tt> is an array type, and</ins>
</p></li>
<li><p>
<ins><tt>V*</tt> is implicitly convertible to <tt>T*</tt>, and</ins>
</p></li>
<li><p>
<ins><tt>T</tt> is not a base class of <tt>V</tt> (without regard to <i>cv</i>-qualifiers),</ins>
</p></li>
</ul>
<p>
<ins>where <tt>V</tt> is the array element type of <tt>U</tt>.</ins>
</p>
</blockquote>

<blockquote><pre>
void operator()(T* ptr) const;
</pre><blockquote>
<p>
-1- <i>Effects</i>: calls <tt>delete[]</tt> on <tt>ptr</tt>.
<p/>
-2- <i>Remarks</i>: If <tt>T</tt> is an incomplete type, the program is ill-formed.
</p>
</blockquote></blockquote>

<blockquote><pre>
<ins>template &lt;class U&gt; void operator()(U*) const = delete;</ins>
</pre><blockquote>
<p>
<ins>-?- <i>Remarks</i>: This function shall not participate in overload resolution unless <tt>T</tt> is a base 
class of <tt>U</tt> (without regard to <i>cv</i>-qualifiers).</ins>
</p>
</blockquote></blockquote>

</blockquote>
</li>

<li><p>Revise 20.8.1.2 [unique.ptr.single]/3 as follows:</p>
<blockquote><p>
If the type <tt>remove_reference&lt;D&gt;::type::pointer</tt> exists, then <tt>unique_ptr&lt;T, D&gt;::pointer</tt> 
shall be a synonym for <tt>remove_reference&lt;D&gt;::type::pointer</tt>. Otherwise <tt>unique_ptr&lt;T, D&gt;::pointer</tt> 
shall be a synonym for <tt><del>T</del><ins>element_type</ins>*</tt>. The type <tt>unique_ptr&lt;T, D&gt;::pointer</tt> 
shall satisfy the requirements of <tt>NullablePointer</tt> (17.6.3.3 [nullablepointer.requirements]).
</p></blockquote>
</li>

<li><p>Revise 20.8.1.3 [unique.ptr.runtime] as follows:</p>
<blockquote><pre>
namespace std {
  template &lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt; {
  public:
    typedef <i>see below</i> pointer;
    typedef T element_type;
    typedef D deleter_type;

    <i>// 20.7.1.3.1, constructors</i>
    constexpr unique_ptr() noexcept;
    explicit unique_ptr(pointer p) noexcept;
    <ins>template &lt;class U&gt; explicit unique_ptr(U* p) = delete;</ins>
    unique_ptr(pointer p, <i>see below</i> d) noexcept;
    <ins>template &lt;class U&gt; unique_ptr(U* p, <i>see below</i> d) = delete;</ins>
    unique_ptr(pointer p, <i>see below</i> d) noexcept;
    <ins>template &lt;class U&gt; unique_ptr(U* p, <i>see below</i> d) = delete;</ins>
    unique_ptr(unique_ptr&amp;&amp; u) noexcept;
    constexpr unique_ptr(nullptr_t) noexcept : unique_ptr() { }
    <ins>template &lt;class U, class E&gt; unique_ptr(unique_ptr&lt;U, E&gt;&amp;&amp; u) noexcept;</ins>

    <i>// destructor</i>
    ~unique_ptr();

    <i>// assignment</i>
    unique_ptr&amp; operator=(unique_ptr&amp;&amp; u) noexcept;
    <ins>template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u) noexcept;</ins>
    unique_ptr&amp; operator=(nullptr_t) noexcept;

    <i>// 20.7.1.3.2, observers</i>
    T&amp; operator[](size_t i) const;
    pointer get() const noexcept;
    deleter_type&amp; get_deleter() noexcept;
    const deleter_type&amp; get_deleter() const noexcept;
    explicit operator bool() const noexcept;

    <i>// 20.7.1.3.3 modifiers</i>
    pointer release() noexcept;
    void reset(pointer p = pointer()) noexcept;
    <del>void reset(nullptr_t) noexcept;</del>
    template &lt;class U&gt; void reset(U<ins>*</ins>) = delete;
    void swap(unique_ptr&amp; u) noexcept;

    <i>// disable copy from lvalue</i>
    unique_ptr(const unique_ptr&amp;) = delete;
    unique_ptr&amp; operator=(const unique_ptr&amp;) = delete;
  };
}
</pre></blockquote>
<blockquote><p>
-1- A specialization for array types is provided with a slightly altered interface.
</p>
<ul>
<li><p>
Conversions <del>between different types of <tt>unique_ptr&lt;T[], D&gt;</tt></del><ins>from
<tt>unique_ptr&lt;Derived[]&gt;</tt> to <tt>unique_ptr&lt;Base[]&gt;</tt>, where <tt>Base</tt> is a 
base class of <tt>Derived</tt>, from <tt>auto_ptr</tt>,</ins> or to or from the non-array forms of
<tt>unique_ptr</tt> produce an ill-formed program.
</p></li>
<li><p>
Pointers to types derived from <tt>T</tt> are rejected by the constructors, and by <tt>reset</tt>.
</p></li>
<li><p>
The observers <tt>operator*</tt> and <tt>operator-&gt;</tt> are not provided.
</p></li>
<li><p>
The indexing observer <tt>operator[]</tt> is provided.
</p></li>
<li><p>
The default deleter will call <tt>delete[]</tt>.
</p></li>
</ul>
<p>
-2- Descriptions are provided below only for <del>member functions that have behavior 
different</del><ins>members that differ</ins> from the primary template.
<p/>
-3- The template argument <tt>T</tt> shall be a complete type.
</p>
</blockquote>
</li>

<li><p>Revise 20.8.1.3.1 [unique.ptr.runtime.ctor] as follows:</p>
<blockquote>
<pre>
<del>explicit unique_ptr(pointer p) noexcept;
unique_ptr(pointer p, <i>see below</i> d) noexcept;
unique_ptr(pointer p, <i>see below</i> d) noexcept;</del>
<ins>template &lt;class U&gt; explicit unique_ptr(U* p) = delete;</ins>
<ins>template &lt;class U&gt; unique_ptr(U* p, <i>see below</i> d) = delete;</ins>
<ins>template &lt;class U&gt; unique_ptr(U* p, <i>see below</i> d) = delete;</ins>
</pre><blockquote><p>
<del>These constructors behave the same as in the primary template except that they do not accept pointer
types which are convertible to pointer. [<i>Note</i>: One implementation technique is to create private
templated overloads of these members. &mdash; <i>end note</i>]</del><ins>These constructors shall not 
participate in overload resolution unless:</ins></p>
<ul>
<li><p><ins><tt>pointer</tt> is a pointer type, and</ins></p></li>
<li><p><ins><tt>U*</tt> is implicitly convertible to <tt>pointer</tt>, and</ins></p></li>
<li><p><ins><tt>T</tt> is a base class of <tt>U</tt> (without regard to <i>cv</i>-qualifiers).</ins></p></li>
</ul>
<p><ins>The type of <tt>d</tt> is determined as in the corresponding non-deleted constructors.</ins></p>
</blockquote>
<pre>
<ins>template &lt;class U, class E&gt; unique_ptr(unique_ptr&lt;U, E&gt;&amp;&amp; u) noexcept;</ins>
</pre><blockquote><p>
<ins>-?- This constructor behaves the same as in the primary template, except that it shall not participate
in overload resolution unless:</ins>
</p>
<ul>
<li><p><ins><tt>unique_ptr&lt;U, E&gt;::pointer</tt> is implicitly convertible to <tt>pointer</tt>, and</ins></p></li>
<li><p><ins><tt>U</tt> is an array type, and</ins></p></li>
<li><p><ins>either <tt>D</tt> is a reference type and <tt>E</tt> is the same type as <tt>D</tt>, or <tt>D</tt> 
is not a reference type and <tt>E</tt> is implicitly convertible to <tt>D</tt>, and</ins></p></li>
<li><p><ins>either at least one of <tt>pointer</tt> and <tt>unique_ptr&lt;U, E&gt;::pointer</tt> is not a 
pointer type, or <tt>T</tt> is not a base class of the array element type of <tt>U</tt> (without regard to 
<i>cv</i>-qualifiers).</ins></p></li>
</ul>
</blockquote></blockquote>
</li>

<li><p>Insert a new sub-clause following 20.8.1.3.1 [unique.ptr.runtime.ctor] as follows:</p>

<p><ins>?? <tt>unique_ptr</tt> assignment [unique.ptr.runtime.asgn]</ins></p>

<blockquote>
<pre>
<ins>template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u) noexcept;</ins>
</pre><blockquote><p>
<ins>-?- This operator behaves the same as in the primary template, except that it shall not participate in
overload resolution unless:</ins></p>
<ul>
<li><p><ins><tt>unique_ptr&lt;U, E&gt;::pointer</tt> is implicitly convertible to <tt>pointer</tt>, and</ins></p></li>
<li><p><ins><tt>U</tt> is an array type, and</ins></p></li>
<li><p><ins>either <tt>D</tt> is a reference type and <tt>E</tt> is the same type as <tt>D</tt>, or <tt>D</tt> 
is not a reference type and <tt>E</tt> is implicitly convertible to <tt>D</tt>, and</ins></p></li>
<li><p><ins>either at least one of <tt>pointer</tt> and <tt>unique_ptr&lt;U, E&gt;::pointer</tt> is not a 
pointer type, or <tt>T</tt> is not a base class of the array element type of <tt>U</tt> (without regard to 
<i>cv</i>-qualifiers).</ins></p></li>
</ul>
</blockquote></blockquote>
</li>

<li><p>Revise 20.8.1.3.3 [unique.ptr.runtime.modifiers] as follows:</p>

<blockquote>
<pre>
<del>void reset(pointer p = pointer()) noexcept;
void reset(nullptr_t p) noexcept;</del>
<ins>template &lt;class U&gt; void reset(U*) = delete;</ins>
</pre><blockquote><p>
<del>-1- <i>Effects</i>: If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.</del>
<p/>
<del>-2- <i>Postcondition</i>: <tt>get() == p</tt>.</del>
<p/>
<ins>-?- This function shall not participate in overload resolution unless:</ins>
</p>
<ul>
<li><p><ins><tt>pointer</tt> is a pointer type, and</ins></p></li>
<li><p><ins><tt>U*</tt> is implicitly convertible to <tt>pointer</tt>, and</ins></p></li>
<li><p><ins><tt>T</tt> is a base class of <tt>U</tt> (without regard to <i>cv</i>-qualifiers).</ins></p></li>
</ul>

</blockquote></blockquote>
</li>
</ol>
</blockquote>

<p><i>[2014-06 post-Rapperswil]</i></p>

<p>
As described in N4089.
</p>


<p><b>Proposed resolution:</b></p>
<p>
See proposed wording in N4089.
</p>





<hr>
<h3><a name="2119"></a>2119. Missing <tt>hash</tt> specializations for extended integer types</h3>
<p><b>Section:</b> 20.9.12 [unord.hash] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-12-16 <b>Last modified:</b> 2014-05-23</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
According to the header <tt>&lt;functional&gt;</tt> synopsis 20.9 [function.objects] 
and to the explicit description in 20.9.12 [unord.hash] class template 
<tt>hash</tt> specializations shall be provided for all arithmetic types that are 
not extended integer types. This is not explicitly mentioned, but neither the list 
nor any normative wording does include them, so it follows by implication.
<p/>
What are the reasons that extended integer types are excluded? E.g. for 
<tt>numeric_limits</tt> corresponding specializations are required. I would 
expect that an <tt>unordered_map</tt> with key type <tt>std::uintmax_t</tt> would 
just work, but that depends now on whether this type is an extended integer type 
or not.
<p/>
This issue is <em>not</em> asking for also providing specializations for the
<i>cv</i>-qualified arithmetic types. While this is surely a nice-to-have feature,
I consider that restriction as a more secondary problem in practice.
<p/>
The proposed resolution also fixes a problem mentioned in <a href="lwg-defects.html#2109">2109</a> in regard
to confusing requirements on user-defined types and those on implementations.
</p>


<p><i>[2012, Kona]</i></p>

<p>
Move to Open.
</p>
<p>
Agreed that it's a real issue and that the proposed wording fixes it. However, the wording
change is not minimal and isn't consistent with the way we fixed hash wording elsewhere.
</p>
<p>Alisdair will provide updated wording.
</p>

<p><i>[2014-05-06 Geoffrey Romer suggests alternative wording]</i></p>


<p>
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to the FDIS.</p>

<p>Change 20.9.12 [unord.hash] p2 as indicated:</p>

<blockquote><pre>
template &lt;&gt; struct hash&lt;bool&gt;;
template &lt;&gt; struct hash&lt;char&gt;;
[&hellip;]
template &lt;&gt; struct hash&lt;long double&gt;;
template &lt;class T&gt; struct hash&lt;T*&gt;;
</pre><blockquote>
<p>
-2- <del><i>Requires</i>: the template specializations shall meet the requirements 
of class template <tt>hash</tt> (20.9.12 [unord.hash])</del><ins>The header 
<tt>&lt;functional&gt;</tt> provides definitions for specializations of the 
<tt>hash</tt> class template for each <i>cv</i>-unqualified arithmetic type. This 
header also provides a definition for a partial specialization of the <tt>hash</tt> 
class template for any pointer type. The requirements for the members of these 
specializations are given in sub-clause 20.9.12 [unord.hash]</ins>.
</p>
</blockquote></blockquote>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<p>Change 20.9.12 [unord.hash] p1 as indicated:</p>

<blockquote><p>
The unordered associative containers defined in 23.5 use specializations of the class template <tt>hash</tt> as the
default hash function. For all object types <tt>Key</tt> for which there exists a specialization <tt>hash&lt;Key&gt;</tt>, 
and for all <ins>integral and</ins> enumeration types (7.2) <tt>Key</tt>, the instantiation <tt>hash&lt;Key&gt;</tt> shall: [&hellip;]
</p></blockquote>






<hr>
<h3><a name="2121"></a>2121. <tt>app</tt> for string streams</h3>
<p><b>Section:</b> 27.8.6 [stringstream.cons] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2012-01-15 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
This issue was raised while discussing issue <a href="lwg-defects.html#1448">1448</a>.
<p/>
Note the following program:
</p>
<blockquote><pre>
string s("s1: 123456789");
ostringstream s1(s, ios_base::out|ios_base::app);
s1 &lt;&lt; "hello";
cout &lt;&lt; s1.str() &lt;&lt; endl;
</pre></blockquote>
<p>
With g++4.x it prints:
</p>
<blockquote><pre>
s1: 123456789hello
</pre></blockquote>
<p>
With VisualC++10 it prints:
</p>
<blockquote><pre>
hello23456789
</pre></blockquote>
<p>
From my intuitive understanding the flag "app" should result in the output of g++4.x.
I also would read that from 27.5.3.1.4 [ios::openmode] claiming:
</p>
<blockquote><p>
<tt>app</tt>&nbsp;&nbsp;&nbsp;seek to end before each write
</p></blockquote>
<p>
However in issue <a href="lwg-defects.html#1448">1448</a> P.J.Plauger comments:
</p>
<blockquote><p>
I think we should say nothing special about <tt>app</tt> at construction time (thus leaving the write pointer at the beginning of the buffer).
Leave implementers wiggle room to ensure subsequent append writes as they see fit, but don't change existing rules for initial seek
position.
</p></blockquote>
<p>
Note that the flag <tt>ate</tt> on both platforms appends "hello" to <tt>s</tt>.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2127"></a>2127. Move-construction with <tt>raw_storage_iterator</tt></h3>
<p><b>Section:</b> 20.7.10 [storage.iterator] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-01-23 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#storage.iterator">issues</a> in [storage.iterator].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Aliaksandr Valialkin pointed out that <tt>raw_storage_iterator</tt> only supports constructing 
a new object from lvalues so cannot be used to construct move-only types:
</p>
<blockquote><pre>
template &lt;typename InputIterator, typename T&gt;
void move_to_raw_buffer(InputIterator first, InputIterator last, T *raw_buffer)
{
  std::move(first, last, std::raw_storage_iterator&lt;T *, T&gt;(raw_buffer));
}
</pre></blockquote>
<p>
This could easily be solved by overloading <tt>operator=</tt> for rvalues.
<p/>
Dave Abrahams:
<p/>
<tt>raw_storage_iterator</tt> causes exception-safety problems when used with any
generic algorithm. I suggest leaving it alone and not encouraging its use.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf">N3337</a>.</p>

<ol>
<li><p>Add a new signature to the synopsis in 20.7.10 [storage.iterator] p1:</p>

<blockquote><pre>
namespace std {
  template &lt;class OutputIterator, class T&gt;
  class raw_storage_iterator
    : public iterator&lt;output_iterator_tag,void,void,void,void&gt; {
  public:
    explicit raw_storage_iterator(OutputIterator x);

    raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator*();
    raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator=(const T&amp; element);
    <ins>raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator=(T&amp;&amp; element);</ins>
    raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator++();
    raw_storage_iterator&lt;OutputIterator,T&gt; operator++(int);
};
}
</pre></blockquote>
</li>

<li><p>Insert the new signature and a new paragraph before p4:</p>

<blockquote><pre>
raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator=(const T&amp; element);
<ins>raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator=(T&amp;&amp; element);</ins>
</pre><blockquote>
<p>
<ins>-?- <i>Requires</i>: For the first signature <tt>T</tt> shall be <tt>CopyConstructible</tt>. For
the second signature <tt>T</tt> shall be <tt>MoveConstructible</tt>.</ins>
<p/>
-4- <i>Effects</i>: Constructs a value from <tt>element</tt> at the location to which the iterator points.
<p/>
-5- <i>Returns</i>: A reference to the iterator.
</p>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2129"></a>2129. User specializations of <tt>std::initializer_list</tt></h3>
<p><b>Section:</b> 17.6.4.2.1 [namespace.std], 18.9 [support.initlist] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2012-01-18 <b>Last modified:</b> 2014-05-02</p>
<p><b>View other</b> <a href="lwg-index-open.html#namespace.std">active issues</a> in [namespace.std].</p>
<p><b>View all other</b> <a href="lwg-index.html#namespace.std">issues</a> in [namespace.std].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Since the implementation is intended to magically synthesize instances of <tt>std::initializer_list</tt> 
(rather than by a constructor call, for instance), user specializations of this type can't generally be 
made to work. I can't find any wording which makes such specializations ill-formed, though, which leads 
me to suspect that they're technically legal under the provisions of 17.6.4.2.1 [namespace.std] p1.</p>


<p><i>[2012, Kona]</i></p>

<p>
This sounds correct, but we need wording for a resolution.
</p>
<p>
Marshall Clow volunteers to produce wording.
</p>

<p><i>[2014-02-19, Jonathan Wakely provides proposed wording]</i></p>


<p><i>[2014-03-27, Library reflector vote]</i></p>

<p>
The issue has been identified as Tentatively Ready based on six votes in favour.
</p>

<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Add new new paragraph below 18.9 [support.initlist] p2:</p>

<blockquote>
<p>
-2- An object of type <tt>initializer_list&lt;E&gt;</tt> provides access to an array of objects of type <tt>const E</tt>. [&hellip;]
<p/>
<ins>-?- If an explicit specialization or partial specialization of <tt>initializer_list</tt> is declared, the program is ill-formed.</ins>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2133"></a>2133. Attitude to overloaded comma for iterators</h3>
<p><b>Section:</b> 17.6.5.4 [global.functions] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Yakov Galka <b>Opened:</b> 2012-01-25 <b>Last modified:</b> 2014-05-23</p>
<p><b>View all other</b> <a href="lwg-index.html#global.functions">issues</a> in [global.functions].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
17.6.5.4 [global.functions] says
</p>
<blockquote><p>
Unless otherwise specified, global and non-member functions in the standard library 
shall not use functions from another namespace which are found through argument-dependent 
name lookup (3.4.2).
</p></blockquote>
<p>
This sounds clear enough. There are just two problems:
</p>
<ol>
<li><p>
Both implementations I tested (VS2005 and GCC 3.4.3) do unqualified
calls to the comma operator in some parts of the library with operands
of user-defined types.
</p></li>
<li>
<p>
The standard itself does this in the description of some algorithms. E.g. <tt>uninitialized_copy</tt> 
is defined as:
</p>
<blockquote><p>
<i>Effects</i>:
</p><blockquote>
<pre>
for (; first != last; <span style="color:#C80000;font-weight:bold">++result, ++first</span>)
  ::new (static_cast&lt;void*&gt;(&amp;*result))
    typename iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
</pre>
</blockquote>
</blockquote>
</li>
</ol>
<p>
If understood literally, it is required to call <tt>operator,(ForwardIterator, InputIterator)</tt>.
<p/>
For detailed discussion with code samples see 
<a href="http://stackoverflow.com/questions/8719829/should-the-implementation-guard-itself-against-comma-overloading">here</a>.
<p/>
Proposal:
</p>
<ol>
<li>
Add an exception to the rule in 17.6.5.4 [global.functions] by permitting
the implementation to call the comma operator as much as it wants to. I doubt we want this. or
</li>
<li>
Fix the description of the said algorithms and perhaps add a note to 17.6.5.4 [global.functions] 
that brings attention of the implementers to avoid this pitfall.
</li>
</ol>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
There are real questions here, that may require a paper to explore and answer properly.
</p>

<p><i>[2014-05-18, Daniel comments and suggests concrete wording]</i></p>


<p>
Other issues, such as <a href="lwg-active.html#2114">2114</a> already follow a similar spirit as the one suggested by bullet 2 of the
issue submitter. I assert that consideration of possible user-provided overloads of the comma-operator were not intended
by the original wording and doing so afterwards would unnecessarily complicate a future conceptualization of the library
and would needlessly restrict implementations.
<p/>
I don't think that a paper is needed to solve this issue, there is a simply way to ensure that the code-semantics
excludes consideration of user-provided comma operators. The provided wording below clarifies this by explicitly
casting the first argument of the operator to <tt>void</tt>. 
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 20.7.12.2 [uninitialized.copy] as indicated:</p>

<blockquote>
<pre>
template &lt;class InputIterator, class ForwardIterator&gt;
  ForwardIterator uninitialized_copy(InputIterator first, InputIterator last,
                                     ForwardIterator result);
</pre>
<blockquote>
<p>
-1- <i>Effects</i>:
</p>
<blockquote>
<pre>
for (; first != last; ++result, <ins>(void)</ins> ++first)
  ::new (static_cast&lt;void*&gt;(&amp;*result))
    typename iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
</pre>
</blockquote>
<p>
[&hellip;]
</p>
</blockquote>

<pre>
template &lt;class InputIterator, class Size,class ForwardIterator&gt;
  ForwardIterator uninitialized_copy_n(InputIterator first, Size n,
                                       ForwardIterator result);
</pre>
<blockquote>
<p>
-3- <i>Effects</i>:
</p>
<blockquote>
<pre>
for (; n &gt; 0; ++result, <ins>(void)</ins> ++first, --n)
  ::new (static_cast&lt;void*&gt;(&amp;*result))
    typename iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
</pre>
</blockquote>
</blockquote>

</blockquote>
</li>

<li><p>Change 25.4.8 [alg.lex.comparison] p3 as indicated:</p>

<blockquote>
<pre>
template&lt;class InputIterator1, class InputIterator2&gt;
  bool
    lexicographical_compare(InputIterator1 first1, InputIterator1 last1,
                            InputIterator2 first2, InputIterator2 last2);
template&lt;class InputIterator1, class InputIterator2, class Compare&gt;
  bool
    lexicographical_compare(InputIterator1 first1, InputIterator1 last1,
                            InputIterator2 first2, InputIterator2 last2,
                            Compare comp);
</pre>
<blockquote>
<p>
-3- <i>Remarks</i>: [&hellip;]
</p>
<blockquote>
<pre>
for ( ; first1 != last1 &amp;&amp; first2 != last2 ; ++first1, <ins>(void)</ins> ++first2) {
  if (*first1 &lt; *first2) return true;
  if (*first2 &lt; *first1) return false;
}
return first1 == last1 &amp;&amp; first2 != last2;
</pre>
</blockquote>
</blockquote>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="2136"></a>2136. Postconditions vs. exceptions</h3>
<p><b>Section:</b> 17.5.1 [structure] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2012-03-08 <b>Last modified:</b> 2014-02-10</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The front matter in clause 17 should clarify that postconditions will not hold if a 
standard library function exits via an exception. Postconditions or guarantees that 
apply when an exception is thrown (beyond the basic guarantee) are described in an 
"Exception safety" section.
</p>

<p><i>[
2012-10 Portland: Move to Open
]</i></p>


<p>
Consensus that we do not clearly say this, and that we probably should.  A likely
location to describe the guarantees of <i>postconditions</i> could well be a new
sub-clause following 17.6.4.11 [res.on.required] which serves the same purpose
for <i>requires</i> clauses.  However, we need such wording before we can make
progress.
</p>

<p>
Also, see <a href="lwg-active.html#2137">2137</a> for a suggestion that we want to see a paper resolving
both issues together.
</p>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2137"></a>2137. Misleadingly constrained post-condition in the presence of exceptions</h3>
<p><b>Section:</b> 28.8.3 [re.regex.assign] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-03-08 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#re.regex.assign">issues</a> in [re.regex.assign].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The post-conditions of <tt>basic_regex&lt;&gt;::assign</tt> 28.8.3 [re.regex.assign] p16 say:
</p>
<blockquote><p>
<span style="color:#C80000;font-weight:bold">If no exception is thrown,</span> <tt>flags()</tt> returns 
<tt>f</tt> and <tt>mark_count()</tt> returns the number of marked sub-expressions within the expression.
</p></blockquote>
<p>
The default expectation in the library is that post-conditions only hold, if there is no failure 
(see also <a href="lwg-active.html#2136">2136</a>), therefore the initial condition should be removed to prevent any
misunderstanding.
</p>

<p><i>[
2012-10 Portland: Move to Open
]</i></p>


<p>
A favorable resolution clearly depends on a favorable resolution to <a href="lwg-active.html#2136">2136</a>.
There is also a concern that this is just one example of where we would want to apply
such a wording clean-up, and which is really needed to resolve both this issue and
<a href="lwg-active.html#2136">2136</a> is a paper providing the clause 17 wording that gives the guarantee
for <i>postcondition</i> paragaraphs, and then reviews clauses 18-30 to apply that
guarantee consistently.  We do not want to pick up these issues piecemeal, as we risk
openning many issues in an ongoing process.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<blockquote><pre>
template &lt;class string_traits, class A&gt;
  basic_regex&amp; assign(const basic_string&lt;charT, string_traits, A&gt;&amp; s,
    flag_type f = regex_constants::ECMAScript);
</pre><blockquote>
<p>
[&hellip;]
<p/>
-15- <i>Effects</i>: Assigns the regular expression contained in the string <tt>s</tt>, interpreted according 
the flags specified in <tt>f</tt>. If an exception is thrown, <tt>*this</tt> is unchanged.
<p/>
-16- <i>Postconditions</i>: <del>If no exception is thrown,</del> <tt>flags()</tt> returns <tt>f</tt> and 
<tt>mark_count()</tt> returns the number of marked sub-expressions within the expression.
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="2139"></a>2139. What is a <em>user-defined</em> type?</h3>
<p><b>Section:</b> 17.6.4.2.1 [namespace.std], 19.5 [syserr], 20.7.7.1 [allocator.uses.trait], 20.9.9.1.1 [func.bind.isbind], 20.9.9.1.2 [func.bind.isplace], 20.9.12 [unord.hash], 20.10.7.6 [meta.trans.other], 22.3.1 [locale], 22.4.1.4 [locale.codecvt], 28.12.1.4 [re.regiter.incr] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Lo&iuml;c Joly <b>Opened:</b> 2012-03-08 <b>Last modified:</b> 2014-02-20</p>
<p><b>View other</b> <a href="lwg-index-open.html#namespace.std">active issues</a> in [namespace.std].</p>
<p><b>View all other</b> <a href="lwg-index.html#namespace.std">issues</a> in [namespace.std].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The expression "user-defined type" is used in several places in the standard, but I'm not sure what 
it means. More specifically, is a type defined in the standard library a user-defined type?
<p/>
From my understanding of English, it is not. From most of the uses of this term in the standard, it 
seem to be considered as user defined. In some places, I'm hesitant, e.g. 17.6.4.2.1 [namespace.std] p1:
</p>
<blockquote><p>
A program may add a template specialization for any standard library template to namespace <tt>std</tt> 
only if the declaration depends on a user-defined type and the specialization meets the standard library 
requirements for the original template and is not explicitly prohibited.
</p></blockquote>
<p>
Does it mean we are allowed to add in the namespace <tt>std</tt> a specialization for 
<tt>std::vector&lt;std::pair&lt;T, U&gt;&gt;</tt>, for instance?
<p/>
Additional remarks from the reflector discussion: The traditional meaning of user-defined types refers
to class types and enum types, but the library actually means here user-defined types that are not
(purely) library-provided. Presumably a new term - like <em>user-provided type</em> - should be introduced
and properly defined.
</p>

<p><i>[
2012-10 Portland: Move to Deferred 
]</i></p>


<p>
The issue is real, in that we never define this term and rely on a "know it when I see it"
intuition.  However, there is a fear that any attempt to pin down a definition is more
likely to introduce bugs than solve them - getting the wording for this precisely correct
is likely far more work than we are able to give it.
</p>

<p>
There is unease at simple closing as NAD, but not real enthusiasm to provide wording either.
Move to Deferred as we are not opposed to some motivated individual coming back with full
wording to review, but do not want to go out of our way to encourage someone to work on this
in preference to other issues.
</p>

<p><i>[2014-02-20 Re-open Deferred issues as Priority 4]</i></p>




<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2146"></a>2146. Are reference types <tt>Copy</tt>&#47;<tt>Move-Constructible</tt>&#47;<tt>Assignable</tt> or <tt>Destructible</tt>?</h3>
<p><b>Section:</b> 17.6.3.1 [utility.arg.requirements] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2012-03-23 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
According to 17.6.3.1 [utility.arg.requirements] p1
</p>
<blockquote><p>
The template definitions in the C++ standard library refer to various named requirements whose details are set out in 
tables 17-24. In these tables, <tt>T</tt> is an object or reference type to be supplied by a C++ program instantiating 
a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are values of type (possibly <tt>const</tt>) <tt>T</tt>; <tt>s</tt> 
and <tt>t</tt> are modifiable lvalues of type <tt>T</tt>; <tt>u</tt> denotes an identifier; <tt>rv</tt> is an rvalue of 
type <tt>T</tt>; and <tt>v</tt> is an lvalue of type (possibly <tt>const</tt>) <tt>T</tt> or an rvalue of type <tt>const T</tt>.
</p></blockquote>
<p>
Is it really intended that <tt>T</tt> may be a reference type? If so, what should <tt>a</tt>, <tt>b</tt>, <tt>c</tt>, 
<tt>s</tt>, <tt>t</tt>, <tt>u</tt>, <tt>rv</tt>, and <tt>v</tt> mean? For example, are "<tt>int &amp;</tt>" and 
"<tt>int &amp;&amp;</tt>" <tt>MoveConstructible</tt>?
<p/>
As far as I understand, we can explicitly specify template arguments for <tt>std::swap</tt> and <tt>std::for_each</tt>. 
Can we use reference types there?
</p>
<ol>
<li>
<blockquote><pre>
#include &lt;iostream&gt;
#include &lt;utility&gt;

int main()
{
  int x = 1;
  int y = 2;
  std::swap&lt;<span style="color:#C80000;font-weight:bold">int &amp;&amp;</span>&gt;(x, y); // <em>undefined?</em>
  std::cout &lt;&lt; x &lt;&lt; " " &lt;&lt; y &lt;&lt; std::endl;
}
</pre></blockquote>
</li>
<li>
<blockquote><pre>
#include &lt;algorithm&gt;
#include &lt;iostream&gt;
#include &lt;iterator&gt;
#include &lt;utility&gt;

struct F
{
  void operator()(int n)
  {
    std::cout &lt;&lt; n &lt;&lt; std::endl;
    ++count;
  }
  int count;
} f;

int main()
{
  int arr[] = { 1, 2, 3 };
  auto&amp;&amp; result = std::for_each&lt;int *, <span style="color:#C80000;font-weight:bold">F &amp;&amp;</span>&gt;( // <em>undefined?</em>
    std::begin(arr),
    std::end(arr),
    std::move(f));
  std::cout &lt;&lt; "count: " &lt;&lt; result.count &lt;&lt; std::endl;
}
</pre></blockquote>
</li>
</ol>
<p>
Are these forms of usage well-defined?
<p/>
Let's also consider the following constructor of <tt>std::thread</tt>:
</p>
<blockquote><pre>
template &lt;class F, class ...Args&gt;
explicit thread(F&amp;&amp; f, Args&amp;&amp;... args);
</pre><blockquote>
<p>
<i>Requires</i>: <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall satisfy the <tt>MoveConstructible</tt> requirements.
</p>
</blockquote></blockquote>
<p>
When the first argument of this constructor is an lvalue (e.g. a name of a global function), template argument for <tt>F</tt> 
is deduced to be lvalue reference type. What should "<tt>MoveConstructible</tt>" mean with regard to an lvalue reference 
type? Maybe the wording should say that <tt>std::decay&lt;F&gt;::type</tt> and each <tt>std::decay&lt;Ti&gt;::type</tt> (where 
<tt>Ti</tt> is an arbitrary item in <tt>Args</tt>) shall satisfy the <tt>MoveConstructible</tt> requirements?
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
The questions raised by the issue are real, and should have a clear answer.
</p>



<p><b>Proposed resolution:</b></p>






<hr>
<h3><a name="2151"></a>2151. <tt>basic_string&lt;&gt;::swap</tt> semantics ignore allocators</h3>
<p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Robert Shearer <b>Opened:</b> 2012-04-13 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#string.require">issues</a> in [string.require].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
In C++11, <tt>basic_string</tt> is not described as a "container", and is not governed by the allocator-aware 
container semantics described in sub-clause 23.2 [container.requirements]; as a result, and 
requirements or contracts for the <tt>basic_string</tt> interface must be documented in Clause 
21 [strings].
<p/>
Sub-clause 21.4.6.8 [string::swap] defines the <tt>swap</tt> member function with no requirements, and
with guarantees to execute in constant time without throwing. Fulfilling such a contract is not reasonable 
in the presence of unequal non-propagating allocators.
<p/>
In contrast, 23.2.1 [container.requirements.general] p7 declares the behavior of member <tt>swap</tt> 
for containers with unequal non-propagating allocators to be undefined.
<p/>
Resolution proposal:
<p/>
Additional language from Clause 23 [containers] should probably be copied to Clause 
21 [strings]. I will refrain from an exactly recommendation, however, as I am raising further
issues related to the language in Clause 23 [containers].
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
Alisdair has offered to provide wording.
</p>
<p>
Telecon notes that 23.2.1 [container.requirements.general]p13 says that <tt>string</tt> is an
allocator-aware container.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2152"></a>2152. Instances of standard container types are not swappable</h3>
<p><b>Section:</b> 17.6.3.2 [swappable.requirements], 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Robert Shearer <b>Opened:</b> 2012-04-13 <b>Last modified:</b> 2014-02-10</p>
<p><b>View all other</b> <a href="lwg-index.html#swappable.requirements">issues</a> in [swappable.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Sub-clause 17.6.3.2 [swappable.requirements] defines two notions of swappability: a binary version defining
when two objects are <em>swappable with</em> one another, and a unary notion defining whether an object is 
<em>swappable</em> (without qualification), with the latter definition requiring that the object satisfy the 
former with respect to all values of the same type.
<p/>
Let <tt>T</tt> be a container type based on a non-propagating allocator whose instances do not necessarily 
compare equal. Then sub-clause 23.2.1 [container.requirements.general] p7 implies that no object <tt>t</tt> 
of type <tt>T</tt> is swappable (by the unary definition).
<p/>
Throughout the standard it is the unary definition of "swappable" that is listed as a requirement (with the 
exceptions of 20.2.2 [utility.swap] p4, 20.3.2 [pairs.pair] p31, 20.4.2.3 [tuple.swap] p2, 
25.3.3 [alg.swap] p2, and 25.3.3 [alg.swap] p6, which use the binary definition). This renders 
many of the mutating sequence algorithms of sub-clause 25.3 [alg.modifying.operations], for example, 
inapplicable to sequences of standard container types, even where every element of the sequence is swappable 
with every other.
<p/>
Note that this concern extends beyond standard containers to all future allocator-based types.
<p/>
Resolution proposal:
<p/>
I see two distinct straightforward solutions:
</p>
<ol style="list-style-type:lower-roman">
<li>Modify the requirements of algorithms from sub-clause 25.3 [alg.modifying.operations], and all other
places that reference the unary "swappable" definition, to instead use the binary "swappable with" definition 
(over a domain appropriate to the context). The unary definition of "swappable" could then be removed from the 
standard.
</li>
<li>Modify sub-clause 23.2.1 [container.requirements.general] such that objects of standard container types 
are "swappable" by the unary definition.
</li>
</ol>
<p>
I favor the latter solution, for reasons detailed in the following issue.
</p>

<p><i>[
2012-10 Portland: Move to Open 
]</i></p>


<p>
The issue is broader than containers with stateful allocotors, although they are the most obvious
example contained within the standard itself.  The basic problem is that once you have a stateful
allocator, that does not <tt>propagate_on_swap</tt>, then whether two objects of this type can be
swapped with well defined behavior is a run-time property (the allocators compare equal) rather
than a simple compile-time property that can be deduced from the type.  Strictly speaking, any
type where the nature of swap is a runtime property does not meet the <tt>swappable</tt>
requirements of C++11, although typical sequences of such types are going to have elements that
are all <tt>swappable with</tt> any other element in the sequence (using our other term of art
for specifying requirements) as the common case is a container of elements who all share the
same allocator.
</p>

<p>
The heart of the problem is that the <tt>swappable</tt> requirments demand that any two objects
of the same type be <tt>swappable with</tt> each other, so if any two such objects would not
be <tt>swappable with</tt> each other, then the whole type is never <tt>swappable</tt>.  Many
algorithms in clause 25 are specified in terms of <tt>swappable</tt> which is essentially an
overspecification as all they actually need is that any element in the sequence is <tt>swappable
with</tt> any other element in the sequence.
</p>

<p>
At this point Howard joins the discussion and points out that the intent of introducing the
two swap-related terms was to support <tt>vector&lt;bool&gt;::reference</tt> types, and we are
reading something into the wording that was never intended.  Consuses is that regardless of
the intent, that is what the words today say.
</p>

<p>
There is some support to see a paper reviewing the whole of clause 25 for this issue, and
other select clauses as may be necessary.
</p>

<p>
There was some consideration to introducing a note into the front of clause 25 to indicate
<tt>swappable</tt> requirements in the clause should be interpreted to allow such awkward
types, but ultimately no real enthusiasm for introducing a <tt>swappable for clause 25</tt>
requirement term, especially if it confusingly had the same name as a term used with a
subtly different meaning through the rest of the standard.
</p>

<p>
There was no enthusiasm for the alternate resolution of requiring containers with unequal
allocators that do not propagate provide a well-defined swap behavior, as it is not
believed to be possible without giving <tt>swap</tt> linear complexity for such values,
and even then would require adding the constraint that the container element types are
CopyConstructible.
</p>

<p>
Final conclusion: move to open pending a paper from a party with a strong interest in
stateful allocators.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2153"></a>2153. Narrowing of the non-member <tt>swap</tt> contract</h3>
<p><b>Section:</b> 20.2.2 [utility.swap], 17.6.3.2 [swappable.requirements], 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Robert Shearer <b>Opened:</b> 2012-04-13 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Sub-clause 20.2.2 [utility.swap] defines a non-member 'swap' function with defined behavior for
all <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt> types. It does not guarantee
constant-time complexity or <tt>noexcept</tt> in general, however this definition does
render all objects of <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt> type swappable
(by the unary definition of sub-clause 17.6.3.2 [swappable.requirements]) in the absence of 
specializations or overloads.
<p/>
The overload of the non-member <tt>swap</tt> function defined in Table 96, however,
defines semantics incompatible with the generic non-member <tt>swap</tt> function,
since it is defined to call a member <tt>swap</tt> function whose semantics are
undefined for some values of <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt> types.
<p/>
The obvious (perhaps naive) interpretation of sub-clause 17.6.3.2 [swappable.requirements] is as a guide to
the "right" semantics to provide for a non-member <tt>swap</tt> function (called in
the context defined by 17.6.3.2 [swappable.requirements] p3) in order to provide interoperable
user-defined types for generic programming. The standard container types don't follow these guidelines.
<p/>
More generally, the design in the standard represents a classic example of "contract narrowing". It 
is entirely reasonable for the contract of a particular <tt>swap</tt> overload to provide <em>more</em> 
guarantees, such as constant-time execution and <tt>noexcept</tt>, than are provided by the <tt>swap</tt> 
that is provided for any <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt> types, but it is <em>not</em> 
reasonable for such an overload to fail to live up to the guarantees it provides for general types when 
it is applied to more specific types. Such an overload or specialization in generic programming is akin 
to an override of an inherited virtual function in OO programming: violating a superclass contract in a
subclass may be legal from the point of view of the language, but it is poor design and can easily lead 
to errors. While we cannot prevent user code from providing overloads that violate the more general 
<tt>swap</tt> contract, we can avoid doing so within the library itself.
<p/>
My proposed resolution is to draw a sharp distinction between member <tt>swap</tt> functions, which provide 
optimal performance but idiosyncratic contracts, and non-member <tt>swap</tt> functions, which should always 
fulfill at least the contract of 20.2.2 [utility.swap] and thus render objects swappable. The member 
<tt>swap</tt> for containers with non-propagating allocators, for example, would offer constant-time
guarantees and <tt>noexcept</tt> but would only offer defined behavior for values with allocators that compare 
equal; non-member <tt>swap</tt> would test allocator equality and then dispatch to either member <tt>swap</tt> or 
<tt>std::swap</tt> depending on the result, providing defined behavior for all values (and rendering the type
"swappable"), but offering neither the constant-time nor the <tt>noexcept</tt> guarantees.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
This topic deserves more attention than can be given in the telocon, and there is no proposed resolution.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2154"></a>2154. What exactly does compile-time complexity imply?</h3>
<p><b>Section:</b> 26.5.1.3 [rand.req.urng] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> John Salmon <b>Opened:</b> 2012-04-26 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#rand.req.urng">issues</a> in [rand.req.urng].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The expressions <tt>G::min()</tt> and <tt>G::max()</tt> in Table 116 in 26.5.1.3 [rand.req.urng] are specified 
as having "compile-time" complexity.
<p/>
It is not clear what, exactly, this requirement implies.  If a URNG has a method:
</p>
<blockquote><pre>
static int min();
</pre></blockquote>
<p>
then is the method required to have a <tt>constexpr</tt> qualifier?  I believe the standard would benefit from 
clarification of this point.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2155"></a>2155. Macro <tt>__bool_true_false_are_defined</tt> should be removed</h3>
<p><b>Section:</b> 18.10 [support.runtime] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2012-04-30 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#support.runtime">active issues</a> in [support.runtime].</p>
<p><b>View all other</b> <a href="lwg-index.html#support.runtime">issues</a> in [support.runtime].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Since C99, the C standard describes a macro named  <tt>__bool_true_false_are_defined</tt>.
<p/>
In the process of harmonizing C++11 with C99, this name became part of the C++ standard.
<p/>
I propose that all mention of this name should be removed from the C and C++ standards.
<p/>
Here's the problem: The name was originally proposed as a transition tool, so that the headers for a 
project could contain lines like the following.
</p>
<blockquote><pre>
#if !defined(__bool_true_false_are_defined)
#define bool int /* or whatever */
#define true 1
#define false 0
#endif
</pre></blockquote>
<p>
Then when the project was compiled by a "new" compiler that implemented <tt>bool</tt> as defined by the 
evolving C++98 or C99 standards, those lines would be skipped; but when compiled by an "old" compiler that 
didn't yet provide <tt>bool</tt>, <tt>true</tt>, and <tt>false</tt>, then the <tt>#define</tt>'s would provide a
simulation that worked for most purposes.
<p/>
It turns out that there is an unfortunate ambiguity in the name.  One interpretation is as shown above, but 
a different reading says "bool, true, and false are #define'd", i.e. that the meaning of the macro is to
assert that these names are macros (not built-in) ... which is true in C, but not in C++.
<p/>
In C++11, the name appears in parentheses followed by a stray period, so
some editorial change is needed in any event:
<p/>
18.10 [support.runtime] para 1:
</p>
<blockquote><p>
Headers <tt>&lt;csetjmp&gt;</tt> (nonlocal jumps), <tt>&lt;csignal&gt;</tt> (signal handling), <tt>&lt;cstdalign&gt;</tt> 
(alignment), <tt>&lt;cstdarg&gt;</tt> (variable arguments), <tt>&lt;cstdbool&gt;</tt> (<tt>__bool_true_false_are_defined</tt>). 
<tt>&lt;cstdlib&gt;</tt> (runtime environment <tt>getenv()</tt>, <tt>system()</tt>), and <tt>&lt;ctime&gt;</tt> 
(system clock <tt>clock()</tt>, <tt>time()</tt>) provide further compatibility with C code.
</p></blockquote>
<p>
However, para 2 says
</p>
<blockquote><p>
"The contents of these headers are the same as the Standard C library headers <tt>&lt;setjmp.h&gt;</tt>, 
<tt>&lt;signal.h&gt;</tt>, <tt>&lt;stdalign.h&gt;</tt>, <tt>&lt;stdarg.h&gt;</tt>, <tt>&lt;stdbool.h&gt;</tt>, 
<tt>&lt;stdlib.h&gt;</tt>, and <tt>&lt;time.h&gt;</tt>, respectively, with the following 
changes:",
</p></blockquote>
<p>
and para 8 says 
</p>
<blockquote><p>
"The header <tt>&lt;cstdbool&gt;</tt> and the header <tt>&lt;stdbool.h&gt;</tt> shall 
not define macros named <tt>bool</tt>, <tt>true</tt>, or <tt>false</tt>."
</p></blockquote>
<p>
Thus para 8 doesn't exempt the C++ implementation from the arguably clear requirement of the C standard, to 
provide a macro named <tt>__bool_true_false_are_defined</tt> defined to be 1.
<p/>
Real implementations of the C++ library differ, so the user cannot count upon any consistency; furthermore, the 
usefulness of the transition tool has faded long ago.
<p/>
That's why my suggestion is that both C and C++ standards should eliminate any mention of 
<tt>__bool_true_false_are_defined</tt>.  In that case, the name belongs to implementers to provide, or not, as 
they choose.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
While not strictly necessary, the clean-up look good.
</p>
<p>
We would like to hear from our C liaison before moving on this issue though.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2156"></a>2156. Unordered containers' <tt>reserve(n)</tt> reserves for <tt>n-1</tt> elements</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel James <b>Opened:</b> 2012-05-07 <b>Last modified:</b> 2014-03-03</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
I think that unordered containers' <tt>reserve</tt> doesn't quite do what it should. I'd expect after calling 
<tt>x.reserve(n)</tt> to be able to insert <tt>n</tt> elements without invalidating iterators. But as 
the standard is written (I'm looking at n3376), I think the guarantee only holds for <tt>n-1</tt> elements.
<p/>
For a container with <tt>max_load_factor</tt> of <tt>1</tt>, <tt>reserve(n)</tt> is equivalent to
<tt>rehash(ceil(n/1))</tt>, ie. <tt>rehash(n)</tt>. <tt>rehash(n)</tt> requires that the bucket
count is <tt>&gt;= n</tt>, so it can be <tt>n</tt> (Table 103). The rule is that <tt>insert</tt>
shall not affect the validity of iterators if <tt>(N + n) &lt; z * B</tt> (23.2.5 [unord.req] p15). 
But for this case the two sides of the equation are equal, so <tt>insert</tt> can affect the validity of iterators.
</p>

<p><i>[2013-03-16 Howard comments and provides wording]</i></p>


<p>
Given the following:
</p>

<blockquote><pre>
LF := load_factor()
MLF := max_load_factor()
S := size()
B := bucket_count()

LF == S/B
</pre></blockquote>

<p>
The container has an invariant:
</p>

<blockquote><pre>
LF &lt;= MLF
</pre></blockquote>

<p>
Therefore:
</p>

<blockquote><pre>
MLF &gt;= S/B
S &lt;= MLF * B
B &gt;= S/MLF
</pre></blockquote>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
Howard to provide rationale and potentally revised wording.
</p>


<p><i>[2012-02-12 Issaquah : recategorize as P3]</i></p>

<p>
Jonathon Wakely: submitter is Boost.Hash maintainer. Think it's right.
</p>

<p>
Marshall Clow: even if wrong it's more right than what we have now
</p>

<p>
Geoffrey Romer: issue is saying rehash should not leave container in such a state that a notional insertion of zero elements should not trigger a rehash
</p>

<p>
AJM: e.g. if you do a range insert from an empty range
</p>

<p>
AJM: we don't have enough brainpower to do this now, so not priority zero
</p>

<p>
Recategorised as P3
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3485.</p>

<ol>
<li>
<p>
In 23.2.5 [unord.req] Table 103 &mdash; Unordered associative container requirements, change the post-condition 
in the row for <code>a.rehash(n)</code> to:
</p>
<blockquote>
Post: <code>a.bucket_count() &gt;<ins>=</ins> a.size() / a.max_load_factor()</code> and <code>a.bucket_count() &gt;= n</code>.
</blockquote>
</li>

<li>
<p>
In 23.2.5 [unord.req]/p15 change
</p>
<blockquote>
The <code>insert</code> and <code>emplace</code> members shall not affect the validity of iterators if 
<code>(N+n) &lt;<ins>=</ins> z * B</code>, where <code>N</code> is the number of elements in the container 
prior to the insert operation, <code>n</code> is the number of elements inserted, <code>B</code> is the container's 
bucket count, and <code>z</code> is the container's maximum load factor.
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2157"></a>2157. How does <tt>std::array&lt;T,0&gt;</tt> initialization work when <tt>T</tt> is not default-constructible?</h3>
<p><b>Section:</b> 23.3.2.8 [array.zero] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daryle Walker <b>Opened:</b> 2012-05-08 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#array.zero">issues</a> in [array.zero].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Objects of <tt>std::array&lt;T,N&gt;</tt> are supposed to be initialized with aggregate initialization (when 
not the destination of a copy or move). This clearly works when <tt>N</tt> is positive. What happens when <tt>N</tt> 
is zero?  To continue using an (inner) set of braces for initialization, a <tt>std::array&lt;T,0&gt;</tt> implementation 
must have an array member of at least one element, and let default initialization take care of those secret elements.  
This cannot work when <tt>T</tt> has a set of constructors and the default constructor is deleted from that set.
Solution: Add a new paragraph in 23.3.2.8 [array.zero]:
</p>
<blockquote><p>
The unspecified internal structure of array for this case shall allow initializations like:
</p>
<blockquote><pre>
array&lt;T, 0&gt; a = { };
</pre></blockquote>
<p>
and said initializations must be valid even when <tt>T</tt> is not default-constructible.
</p></blockquote>

<p><i>[2012, Portland: Move to Open]</i></p>

<p>
Some discussion to understand the issue, which is that implementations currently have freedom to implement
an empty <tt>array</tt> by holding a dummy element, and so might not support value initialization, which is
surprising when trying to construct an empty container.  However, this is not mandated, it is an unspecified
implementation detail.
</p>

<p>
Jeffrey points out that the implication of 23.3.2.1 [array.overview] is that this initialization syntax
must be supported by empty <tt>array</tt> objects already.  This is a surprising inference that was not
obvious to the room, but consensus is that the reading is accurate, so the proposed resolution is not necessary,
although the increased clarity may be useful.
</p>

<p>
Further observation is that the same clause effectively implies that <tt>T</tt> must always be DefaultConstructible,
regardless of <tt>N</tt> for the same reasons - as an <i>initializer-list</i> may not supply enough values, and the
remaining elements must all be value initialized.
</p>

<p>
Concern that we are dancing angels on the head of pin, and that relying on such subtle implications in wording is
not helpful.  We need a clarification of the text in this area, and await wording.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<p>Add the following new paragraph between the current 23.3.2.8 [array.zero] p1 and p2:</p>

<blockquote><p>
-1- <tt>array</tt> shall provide support for the special case <tt>N == 0</tt>.
<p/>
<ins>-?- The unspecified internal structure of <tt>array</tt> for this case shall allow initializations like:</ins>
</p>
<blockquote><pre>
<ins>array&lt;T, 0&gt; a = { };</ins>
</pre></blockquote>
<p>
<ins>and said initializations must be valid even when <tt>T</tt> is not default-constructible.</ins>
<p/>
-2- In the case that <tt>N == 0</tt>, <tt>begin() == end() ==</tt> unique value. The return value of 
<tt>data()</tt> is unspecified.
<p/>
-3- The effect of calling <tt>front()</tt> or <tt>back()</tt> for a zero-sized array is undefined.
<p/>
-4- Member function <tt>swap()</tt> shall have a <em>noexcept-specification</em> which is equivalent to 
<tt>noexcept(true)</tt>.
</p></blockquote>





<hr>
<h3><a name="2158"></a>2158. Conditional copy&#47;move in <tt>std::vector</tt></h3>
<p><b>Section:</b> 23.3.6.3 [vector.capacity] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2012-05-08 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#vector.capacity">active issues</a> in [vector.capacity].</p>
<p><b>View all other</b> <a href="lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
There are various operations on <tt>std::vector</tt> that can cause elements of the vector to be 
moved from one location to another. A move operation can use either rvalue or const lvalue as 
argument; the choice depends on the value of <tt>!is_nothrow_move_constructible&lt;T&gt;::value &amp;&amp;
is_copy_constructible&lt;T&gt;::value</tt>, where <tt>T</tt> is the element type. Thus, some operations 
on <tt>std::vector</tt> (e.g. 'resize' with single parameter, 'reserve', 'emplace_back') should have 
conditional requirements. For example, let's consider the requirement for 'reserve' in N3376 &ndash; 
23.3.6.3 [vector.capacity]&#47;2:
</p>
<blockquote><p>
<i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.
</p></blockquote>
<p>
This requirement is not sufficient if an implementation is free to select copy constructor when 
<tt>!is_nothrow_move_constructible&lt;T&gt;::value &amp;&amp; is_copy_constructible&lt;T&gt;::value</tt> 
evaluates to true. Unfortunately, <tt>is_copy_constructible</tt> cannot reliably determine whether 
<tt>T</tt> is really copy-constructible. A class may contain public non-deleted copy constructor whose 
definition does not exist or cannot be instantiated successfully (e.g., 
<tt>std::vector&lt;std::unique_ptr&lt;int&gt;&gt;</tt> has copy constructor, but this type is not 
copy-constructible). Thus, the actual requirements should be:
</p>
<ul>
<li><p>
if <tt>!is_nothrow_move_constructible&lt;T&gt;::value &amp;&amp; is_copy_constructible&lt;T&gt;::value</tt> 
then <tt>T</tt> shall be <tt>CopyInsertable</tt> into <tt>*this</tt>;
</p></li>
<li><p>
otherwise <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.
</p></li>
</ul>
<p>
Maybe it would be useful to introduce a new name for such conditional requirement (in addition to 
"<tt>CopyInsertable</tt>" and "<tt>MoveInsertable</tt>").
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2160"></a>2160. Unintended destruction ordering-specification of <tt>resize</tt></h3>
<p><b>Section:</b> 23.3.6.3 [vector.capacity] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-06-07 <b>Last modified:</b> 2014-07-01</p>
<p><b>View other</b> <a href="lwg-index-open.html#vector.capacity">active issues</a> in [vector.capacity].</p>
<p><b>View all other</b> <a href="lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>

<p>
As part of resolving LWG issue <a href="lwg-defects.html#2033">2033</a> a wording change was done for <tt>resize()</tt> to 
respect the problem mentioned in the question:
</p>
<blockquote><p>
Does a call to 'void resize(size_type sz)' of <tt>std::vector</tt> require the element type to be 
<tt>MoveAssignable</tt> because the call <tt>erase(begin() + sz, end())</tt> mentioned in the Effects 
paragraph would require the element type to be <tt>MoveAssignable</tt>?
</p></blockquote>
<p>
The wording change was to replace in 23.3.3.3 [deque.capacity] and 23.3.6.3 [vector.capacity]:
</p>
<blockquote><p>
-1- <i>Effects</i>: If <tt>sz &lt;= size()</tt>, equivalent to <tt>erase(begin() + sz, end())</tt>; [&hellip;]
</p></blockquote>
<p>
by:
</p>
<blockquote><p>
-1- <i>Effects</i>: If <tt>sz &lt;= size()</tt>, equivalent to calling <tt>pop_back() size() - sz</tt> times. [&hellip;]
</p></blockquote>
<p>
The overlooked side-effect of this wording change is that this implies a destruction order
of the removed elements to be in reverse order of construction, but the previous version
did not impose any specific destruction order due to the way how the semantics of <tt>erase</tt>
is specified in Table 100.
<p/>
Given the program:
</p>
<blockquote><pre>
#include &lt;vector&gt;
#include &lt;iostream&gt;

struct Probe {
  int value;
  Probe() : value(0) {}
  Probe(int value) : value(value) {}
  ~Probe() { std::cout &lt;&lt; "~Probe() of " &lt;&lt; value &lt;&lt; std::endl; }
};

int main() {
  std::vector&lt;Probe&gt; v;
  v.push_back(Probe(1));
  v.push_back(Probe(2));
  v.push_back(Probe(3));
  std::cout &lt;&lt; "---" &lt;&lt; std::endl;
  <span style="color:#C80000;font-weight:bold">v.resize(0)</span>;
}
</pre></blockquote>
<p>
the last three lines of the output for every compiler I tested was:
</p>
<blockquote><pre>
~Probe() of 1
~Probe() of 2
~Probe() of 3
</pre></blockquote>
<p>
but a conforming implementation would now need to change this order to
</p>
<blockquote><pre>
~Probe() of 3
~Probe() of 2
~Probe() of 1
</pre></blockquote>
<p>
This possible stringent interpretation makes sense, because one can argue that sequence containers 
(or at least <tt>std::vector</tt>) should have the same required destruction order of it's elements,
as elements of a C array or controlled by memory deallocated with an array <tt>delete</tt> have.
I also learned that libc++ does indeed implement <tt>std::vector::resize</tt> in a way that the
second output form is observed.
<p/>
While I agree that required reverse-destruction would better mimic the natural behaviour of
<tt>std::vector</tt> this was not required in C++03 and this request may be too strong. My current 
suggestion would be to restore the effects of the previous wording <em>in regard to the destruction order</em>, 
because otherwise several currently existing implementations would be broken just because of this
additional requirement.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
Jonathan says that he believes this is a valid issue.
</p>
<p>
Walter wonders if this was intended when we made the previous change - if so, this would be NAD.
</p>
<p>
Jonathan said that Issue <a href="lwg-defects.html#2033">2033</a> doesn't mention ordering.
</p>
<p>
Walter then asked if anyone is really unhappy that we're destroying items in reverse order of construction.
</p>
<p>
Jonathan points out that this conflicts with existing practice (libstc++, but not libc++).
</p>
<p>
Jonathan asked for clarification as to whether this change was intended by <a href="lwg-defects.html#2033">2033</a>.
</p>

<p><i>[2014-06 Rapperswil]</i></p>

<p>
Daniel points out that the ordering change was not intended.
<p/>
General agreement that implementations should not be required to change.
</p>

<p><i>[2014-06-28 Daniel provides alternative wording]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p> 

<ol>
<li><p>Change 23.3.3.3 [deque.capacity] as indicated: [<i>Drafting note</i>: The chosen wording form is similar to that for
<tt>forward_list</tt>. Note that the existing <i>Requires</i> element already specifies the necessary operational requirements 
on the value type. &mdash; <i>end drafting note</i>]</p>

<blockquote>
<pre>
void resize(size_type sz);
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: If <tt>sz &lt;<del>=</del> size()</tt>, <ins>erases the last <tt>size() - sz</tt> elements from the 
sequence</ins><del>equivalent to calling <tt>pop_back() size() - sz</tt> times</del>. <ins>Otherwise</ins><del>If <tt>size() 
&lt;= sz</tt></del>, appends <tt>sz - size()</tt> default-inserted elements to the sequence.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
void resize(size_type sz, const T&amp; c);
</pre>
<blockquote>
<p>
-3- <i>Effects</i>: If <tt>sz &lt;<del>=</del> size()</tt>, <ins>erases the last <tt>size() - sz</tt> elements from the 
sequence</ins><del>equivalent to calling <tt>pop_back() size() - sz</tt> times</del>. <ins>Otherwise</ins><del>If <tt>size() 
&lt; sz</tt></del>, appends <tt>sz - size()</tt> copies of <tt>c</tt> to the sequence.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 23.3.6.3 [vector.capacity] as indicated: [<i>Drafting note</i>: See <tt>deque</tt> for the rationale of the
used wording. &mdash; <i>end drafting note</i>]</p>

<blockquote>
<pre>
void resize(size_type sz);
</pre>
<blockquote>
<p>
-12- <i>Effects</i>: If <tt>sz &lt;<del>=</del> size()</tt>, <ins>erases the last <tt>size() - sz</tt> elements from the 
sequence</ins><del>equivalent to calling <tt>pop_back() size() - sz</tt> times</del>. <ins>Otherwise</ins><del>If <tt>size() 
&lt; sz</tt></del>, appends <tt>sz - size()</tt> default-inserted elements to the sequence.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
void resize(size_type sz, const T&amp; c);
</pre>
<blockquote>
<p>
-15- <i>Effects</i>: If <tt>sz &lt;<del>=</del> size()</tt>, <ins>erases the last <tt>size() - sz</tt> elements from the 
sequence</ins><del>equivalent to calling <tt>pop_back() size() - sz</tt> times</del>. <ins>Otherwise</ins><del>If <tt>size() 
&lt; sz</tt></del>, appends <tt>sz - size()</tt> copies of <tt>c</tt> to the sequence.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2161"></a>2161. <tt>const</tt> equivalence of <tt>std::map</tt></h3>
<p><b>Section:</b> 23.4 [associative], 23.5 [unord] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Bjarne Stroustrup <b>Opened:</b> 2012-06-18 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#associative">issues</a> in [associative].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
As described in the reflector discussion c++std-core-21860 consider the following example:
</p>
<blockquote><pre>
map&lt;const int, int&gt; mci{};
map&lt;int, int&gt; mi = mci; // ??
mci[1] = 2;
mi[1] = 2;
</pre></blockquote>
<p>
Should it be required that the marked initialization is well-formed? As a possible solution
this could be realized by an alias template:
</p>
<blockquote><pre>
template &lt;class K, class T&gt;
struct OriginalMap { [&hellip;] };

template &lt;class K, class T&gt;
using ImprovedMap = OriginalMap&lt;const K, T&gt;;
</pre></blockquote>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2164"></a>2164. What are the semantics of <tt>vector.emplace(vector.begin(), vector.back())</tt>?</h3>
<p><b>Section:</b> 23.3.6.5 [vector.modifiers], 23.2 [container.requirements] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2012-07-07 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#vector.modifiers">active issues</a> in [vector.modifiers].</p>
<p><b>View all other</b> <a href="lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Nikolay Ivchenkov recently brought the following example on the
<a href="https://groups.google.com/a/isocpp.org/d/topic/std-discussion/dhy23mDFXj4/discussion">std-discussion</a> 
newsgroup, asking whether the following program well-defined:
</p>
<blockquote><pre>
#include &lt;iostream&gt;
#include &lt;vector&gt;

int main()
{
  std::vector&lt;int&gt; v;
  v.reserve(4);
  v = { 1, 2, 3 };
  v.emplace(v.begin(), v.back());
  for (int x : v)
    std::cout &lt;&lt; x &lt;&lt; std::endl;
}
</pre></blockquote>
<p>
Nikolay Ivchenkov:
<p/>
I think that an implementation of <tt>vector</tt>'s 'emplace' should initialize an intermediate object with 
<tt>v.back()</tt> before any shifts take place, then perform all necessary shifts and finally replace the 
value pointed to by <tt>v.begin()</tt> with the value of the intermediate object. So, I would expect the 
following output:
</p>
<blockquote><pre>
3
1
2
3
</pre></blockquote>
<p>
GNU C++ 4.7.1 and GNU C++ 4.8.0 produce other results:
</p>
<blockquote><pre>
2
1
2
3
</pre></blockquote>
<p>
Howard Hinnant:
<p/>
I believe Nikolay is correct that vector should initialize an intermediate object with <tt>v.back()</tt> 
before any shifts take place. As Nikolay pointed out in another email, this appears to be the only way to 
satisfy the strong exception guarantee when an exception is not thrown by <tt>T</tt>'s copy constructor, 
move constructor, copy assignment operator, or move assignment operator as specified by 
23.3.6.5 [vector.modifiers]/p1. I.e. if the emplace construction throws, the vector must remain unaltered.
<p/>
That leads to an implementation that tolerates objects bound to the function parameter pack of the <tt>emplace</tt> 
member function may be elements or sub-objects of elements of the container.
<p/>
My position is that the standard is correct as written, but needs a clarification in this area. Self-referencing 
<tt>emplace</tt> should be legal and give the result Nikolay expects. The proposed resolution of LWG <a href="lwg-closed.html#760">760</a> 
is not correct.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2165"></a>2165. <tt>std::atomic&lt;X&gt;</tt> requires <tt>X</tt> to be nothrow default constructible</h3>
<p><b>Section:</b> 29.5 [atomics.types.generic], 29.6 [atomics.types.operations] <b>Status:</b> <a href="lwg-active.html#Core">Core</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-07-19 <b>Last modified:</b> 2013-10-15</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p>
<p><b>Discussion:</b></p>

<p>
As raised in c++std-lib-32781, this fails to compile even though the default constructor is not used:
</p>
<blockquote><pre>
#include &lt;atomic&gt;

struct X {
  X() noexcept(false) {}
  X(int) { }
};

std::atomic&lt;X&gt; x(3);
</pre></blockquote>
<p>This is because <tt>atomic&lt;T&gt;</tt>'s default constructor is declared to be non-throwing and 
is explicitly-defaulted on its first declaration:
</p>
<blockquote><pre>
atomic() noexcept = default;
</pre></blockquote>
<p>
This is ill-formed if the implicitly-declared default constructor would not be non-throwing.
<p/>
Possible solutions:
</p>
<ol>
<li>
Add nothrow default constructible to requirements for template argument of the generic <tt>atomic&lt;T&gt;</tt>
</li>
<li>
Remove <tt>atomic&lt;T&gt;::atomic()</tt> from the overload set if <tt>T</tt> is not nothrow default constructible.
</li>
<li>
Remove <tt>noexcept</tt> from <tt>atomic&lt;T&gt;::atomic()</tt>, allowing it to be
deduced (but the default constructor is intended to be always noexcept)
</li>
<li>
Do not default <tt>atomic&lt;T&gt;::atomic()</tt> on its first declaration (but makes the default constructor 
user-provided and so prevents <tt>atomic&lt;T&gt;</tt> being trivial)
</li>
<li>
A core change to allow the mismatched exception specification if the default constructor isn't used 
(see c++std-core-21990)
</li>
</ol>

<p><i>[2012, Portland: move to Core]</i></p>

<p>
Recommend referring to core to see if the constructor <tt>noexcept</tt> mismatch
can be resolved there. The issue is not specific to concurrency.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2166"></a>2166. Heap property underspecified?</h3>
<p><b>Section:</b> 25.4.6 [alg.heap.operations] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Peter Sommerlad <b>Opened:</b> 2012-07-09 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.heap.operations">issues</a> in [alg.heap.operations].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Another similar issue to the <tt>operator&lt;</tt> vs greater in <tt>nth_element</tt> but not as direct occurs 
in 25.4.6 [alg.heap.operations]:
</p>
<blockquote><p>
-1- A <em>heap</em> is a particular organization of elements in a range between two random access iterators 
<tt>[a,b)</tt>. Its two key properties are:
</p>
<ol>
<li>There is no element greater than <tt>*a</tt> in the range and
</li>
<li><tt>*a</tt> may be removed by <tt>pop_heap()</tt>, or a new element added by <tt>push_heap()</tt>, in 
O(log(<tt>N</tt>)) time.
</li>
</ol>
</blockquote>
<p>
As noted by Richard Smith, it seems that the first bullet should read:
</p>
<blockquote><p>
<tt>*a</tt> is not less than any element in the range
</p></blockquote>
<p>
Even better the heap condition could be stated here directly, instead of leaving it unspecified, i.e.,
</p>
<blockquote><p>
Each element at <tt>(a+2*i+1)</tt> and <tt>(a+2*i+2)</tt> is less than the element at <tt>(a+i)</tt>, 
if those elements exist, for <tt>i&gt;=0</tt>.
</p></blockquote>
<p>
But may be that was may be intentional to allow other heap organizations?
<p/>
See also follow-up discussion of c++std-lib-32780.
<p/>

</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2168"></a>2168. Inconsistent specification of <tt>uniform_real_distribution</tt> constructor</h3>
<p><b>Section:</b> 26.5.8.2.2 [rand.dist.uni.real] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Marshall Clow <b>Opened:</b> 2012-07-14 <b>Last modified:</b> 2014-06-19</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
uniform_real says in 26.5.8.2.2 [rand.dist.uni.real] p1:
</p>
<blockquote><p>
A <tt>uniform_real_distribution</tt> random number distribution produces random numbers <tt>x</tt>, <tt>a &le; x &lt; b</tt>,
</p></blockquote>
<p>
but also that (26.5.8.2.2 [rand.dist.uni.real] p2):
</p>
<blockquote><pre>
explicit uniform_real_distribution(RealType a = 0.0, RealType b = 1.0);
</pre><blockquote><p>
-2- <i>Requires</i>: <tt>a &le; b</tt> and <tt>b - a &le; numeric_limits&lt;RealType&gt;::max()</tt>.
</p>
</blockquote></blockquote>
<p>
If you construct a <tt>uniform_real_distribution&lt;RealType&gt;(a, b)</tt> where there are no representable 
numbers between 'a' and 'b' (using <tt>RealType</tt>'s representation) then you cannot satisfy 
26.5.8.2.2 [rand.dist.uni.real].
<p/>
An obvious example is when <tt>a == b</tt>.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2170"></a>2170. Aggregates cannot be <tt>DefaultConstructible</tt></h3>
<p><b>Section:</b> 17.6.3.1 [utility.arg.requirements] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-07-19 <b>Last modified:</b> 2014-03-03</p>
<p><b>View other</b> <a href="lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The lack of the definition of the <tt>DefaultConstructible</tt> requirements in C++03 was fixed 
by LWG <a href="lwg-defects.html#724">724</a> at a time where the core rules of list-initialization were slightly
different than today, at that time value-initialization (shortly) was the primary rule for
class types, i.e. just before applying <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1301">CWG 1301</a>, 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1324">CWG 1324</a>, and 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1368">CWG 1368</a>.
<p/>
The order in 8.5.4 [dcl.init.list] p3 was changed to respect aggregate initialization, but that
had the side-effect that formally aggregate types cannot satisfy the <tt>DefaultConstructible</tt>
requirements anymore, because we require that
</p>
<blockquote><pre>
T u{};
</pre></blockquote>
<p>
<em>value-initializes</em> the object <tt>u</tt>.
<p/>
Of-course exclusion of aggregates was not intended, therefore I suggest to extend the requirements
in Table 19 (17.6.3.1 [utility.arg.requirements]) for empty aggregate-initialization as well.
</p>

<p><i>[
2012-10 Portland: Move to Core 
]</i></p>


<p>
We are not qualified to pick apart the Core rules quickly at this point, but the consensus is
that if the core language has changed in this manner, then the fix should similarly be applied
in Core - this is not something that we want users of the language to have to say every time
they want to Value initialize (or aggregate initialize) an object.
</p>

<p>
More to Open until we get a clear response from Core, Alisdair to file an issue with Mike.
</p>

<p><i>[2013-04 Bristol: Back to Library]</i></p>


<p>
The Core Working group opened, discussed, and resolved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1578">CWG 1578</a>
as NAD for this library-related problem: Empty aggregate initialization and value-initialization are different core language concepts,
and this difference can be observed (e.g. for a type with a deleted default-constructor).
</p>

<p><i>[2014-02-15 Issaquah: Move to Ready]</i></p>

<p>
AM: core says still LWG issue, wording has been non-controversial, move to ready?
</p>
<p>
NJ: what about durations? think they are ok
</p>
<p>
Ville: <tt>pair</tt> and a few other have value initialize
</p>
<p>
AM: look at core 1578
</p>
<p>
AM: value initialize would require <tt>()</tt>, remove braces from third row?
</p>
<p>
STL: no
</p>
<p>
PH: core has new issue on aggregates and non-aggregates.
</p>
<p>
AM: right, they said does not affect this issue
</p>
<p>
NJ: why ok with <tt>pair</tt> and <tt>tuple</tt>?
</p>
<p>
STL: will use <tt>()</tt>, <tt>tuple</tt> of aggregates with deleted constructor is ill-formed
</p>
<p>
Ville: aggregate with reference can't have <tt>()</tt>
</p>
<p>
STL: <tt>{}</tt> would be an issue too
</p>
<p>
Ville: aggregate with reference will have <tt>()</tt> deleted implicitly
</p>
<p>
Move to Ready.
</p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<p>Change Table 19 in 17.6.3.1 [utility.arg.requirements] as indicated:</p>

<table border="1">
<caption>Table 19 &mdash; <tt>DefaultConstructible</tt> requirements [defaultconstructible]</caption>

<tr>
<th>Expression</th>
<th>Post-condition</th>
</tr> 

<tr>
<td>
<tt>T t;</tt>
</td>
<td>
object <tt>t</tt> is default-initialized
</td>
</tr>

<tr>
<td>
<tt>T u{};</tt>
</td>
<td>
object <tt>u</tt> is value-initialized <ins>or aggregate-initialized</ins>
</td>
</tr>

<tr>
<td>
<tt>T()</tt><br/>
<tt>T{}</tt>
</td>
<td>
a temporary object of type <tt>T</tt> is value-initialized <ins>or aggregate-initialized</ins>
</td>
</tr>

</table>






<hr>
<h3><a name="2173"></a>2173. The meaning of operator + in the description of the algorithms</h3>
<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2012-08-01 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all other</b> <a href="lwg-index.html#algorithms">issues</a> in [algorithms].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
According to 25.1 [algorithms.general]/12,
</p>
<blockquote><p>
In the description of the algorithms operators <tt>+</tt> and <tt>-</tt> are used for some of the iterator categories 
for which they do not have to be defined. In these cases the semantics of <tt>a+n</tt> is the same as that of
</p>
<blockquote><pre>
X tmp = a;
advance(tmp, n);
return tmp;
</pre></blockquote>
</blockquote>
<p>
There are several places where such operator <tt>+</tt> is applied to an output iterator &mdash; for example, see the 
description of <tt>std::copy</tt>:
</p>
<blockquote><pre>
template&lt;class InputIterator, class OutputIterator&gt;
OutputIterator copy(InputIterator first, InputIterator last,
                    OutputIterator result);
</pre>
<blockquote><p>
-1- <i>Effects</i>: Copies elements in the range <tt>[first,last)</tt> into the range <tt>[result,result + (last -
first))</tt> starting from <tt>first</tt> and proceeding to <tt>last</tt>. For each non-negative integer 
<tt>n &lt; (last - first)</tt>, performs <tt>*(result + n) = *(first + n)</tt>.
</p></blockquote></blockquote>
<p>
<tt>std::advance</tt> is not supposed to be applicable to output iterators, so we need a different method of description.
<p/>
See also message <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=32908">c++std-lib-32908</a>.
</p>

<p><i>[2014-06-07 Daniel comments and provides wording]</i></p>

<p>
The specification for output iterators is somewhat tricky, because here a sequence of increments is required to
be combined with intervening <em>assignments</em> to the dereferenced iterator. I tried to respect this
fact by using a conceptual assignment operation as part of the specification.
<p/>
Another problem in the provided as-if-code is the question which requirements are imposed on <tt>n</tt>. Unfortunately,
the corresponding function <tt>advance</tt> is completely underspecified in this regard, so I couldn't borrow wording
from it. We cannot even assume here that <tt>n</tt> is the difference type of the iterator, because for output iterators there is
no requirements for this associated type to be defined. The presented wording attempts to minimize assumptions, but still
can be considered as controversial. 
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 25.1 [algorithms.general] around p12 as indicated:</p>

<blockquote>
<p>
-12- In the description of the algorithms operators <tt>+</tt> and <tt>-</tt> are used for some of the iterator categories for which
they do not have to be defined. In these cases the semantics of <tt>a+n</tt> is the same as that of
</p>
<blockquote>
<pre>
X tmp = a;
advance(tmp, n);
return tmp;
</pre>
</blockquote>
<p>
<ins>when <tt>X</tt> meets the input iterator requirements (24.2.3 [input.iterators]), otherwise it is the same as that of</ins>
</p>
<blockquote>
<pre>
<ins>X tmp = a;
for (auto i = n; i; ++tmp, (void) --i) 
  *tmp = <i>Expr</i>(i); 
return tmp;</ins>
</pre>
</blockquote>
<p>
<ins>where <tt><i>Expr</i>(i)</tt> denotes the <tt>n-i</tt>-th expression that is assigned to for the corresponding algorithm;</ins> 
and that of <tt>b-a</tt> is the same as of
</p>
<blockquote>
<pre>
return distance(a, b);
</pre>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2178"></a>2178. <tt>Allocator</tt> requirement changes not mentioned Annex C</h3>
<p><b>Section:</b> 17.6.3.5 [allocator.requirements], C.4 [diff.library] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Nevin Liber <b>Opened:</b> 2012-08-14 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Given that a number of things were removed from the allocator requirements (<tt>reference</tt>, <tt>const_reference</tt>, 
<tt>address()</tt> in 17.6.3.5 [allocator.requirements]), it seems that these incompatible changes should be 
mentioned in Annex C.4 [diff.library], more specifically in [diff.cpp03].
</p>

<p><i>[
2012-10 Portland: Move to Open 
]</i></p>


<p>
It was clearly pointed out by Bill during the C++11 process that our change to allocator requirements
potentially broke 3rd party user containers written to expect C++03 allocators, or rather, an
allocator written to the minimal requirements of C++11 might not be guaranteed to work with a container
written to the previous rules.  This was a trade-off in making allocaters easier to write by use of
the <tt>allocator_traits</tt> framework.
</p>

<p>
This probably does merit a write-up in Annex C, and we look forward to seeing wording.  Until then,
the best we can do is move the issue to Open.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2179"></a>2179. <tt>enable_shared_from_this</tt> and construction from raw pointers</h3>
<p><b>Section:</b> 20.8.2.5 [util.smartptr.enab], 20.8.2.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-08-16 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
On reflector message <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=32927">c++std-lib-32927</a>, 
Matt Austern asked whether the following example should be well-defined or not
</p>
<blockquote><pre>
struct X : public enable_shared_from_this&lt;X&gt; { };
auto xraw = new X;
shared_ptr&lt;X&gt; xp1(xraw);
shared_ptr&lt;X&gt; xp2(xraw);
</pre></blockquote>
<p>
pointing out that 20.8.2.2.1 [util.smartptr.shared.const] does not seem to allow it, since
<tt>xp1</tt> and <tt>xp2</tt> aren't allowed to share ownership, because each of them is required to have 
<tt>use_count() == 1</tt>. Despite this wording it might be reasonable (and technical possible)
to implement that request.
<p/>
On the other hand, there is the non-normative note in 20.8.2.5 [util.smartptr.enab] p11 (already part of TR1):
</p>
<blockquote><p>
The <tt>shared_ptr</tt> constructors that <span style="color:#C80000;font-weight:bold">create unique pointers</span> 
can detect the presence of an <tt>enable_shared_from_this</tt> base and assign the newly created <tt>shared_ptr</tt> 
to its <tt>__weak_this member</tt>.
</p></blockquote>
<p>
Now according to the specification in 20.8.2.2.1 [util.smartptr.shared.const] p3-7:
</p>
<blockquote><pre>
template&lt;class Y&gt; explicit shared_ptr(Y* p);
</pre></blockquote>
<p>
the notion of <em>creating unique pointers</em> can be read to be included by this note, because the post-condition
of this constructor is <tt>unique() == true</tt>. Evidence for this interpretation seems to be weak, though.
<p/>
Howard Hinnant presented the counter argument, that actually the following is an "anti-idiom" and it seems questionable 
to teach it to be well-defined in any case:
</p>
<blockquote><pre>
auto xraw = new X;
shared_ptr&lt;X&gt; xp1(xraw);
shared_ptr&lt;X&gt; xp2(xraw);
</pre></blockquote>
<p>
He also pointed out that the current post-conditions of the affected <tt>shared_ptr</tt> constructor
would need to be reworded.
<p/>
It needs to be decided, which direction to follow. If this idiom seems too much broken to be supported,
the note could be improved. If it should be supported, the constructors in
20.8.2.2.1 [util.smartptr.shared.const] need a careful analysis to ensure that post-conditions
are correct.
<p/>
Several library implementations currently do not support this example, instead they typically
cause a crash. Matt points out that there are currently no explicit requirements imposed on
<tt>shared_ptr</tt> objects to prevent them from owning the same underlying object without sharing the 
ownership. It might be useful to add such a requirement.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
More discussion is needed to pick a direction to guide a proposed resolution.
</p>

<p><i>[2013-05-09 Jonathan comments]</i></p>

<p>
The note says the newly created <tt>shared_ptr</tt> is assigned to the <tt>weak_ptr</tt> member. It doesn't 
say before doing that the <tt>shared_ptr</tt> should check if the <tt>weak_ptr</tt> is non-empty and possibly 
share ownership with some other pre-existing <tt>shared_ptr</tt>.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2181"></a>2181. Exceptions from <em>seed sequence</em> operations</h3>
<p><b>Section:</b> 26.5.1.2 [rand.req.seedseq], 26.5.3 [rand.eng], 26.5.4 [rand.adapt] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-08-18 <b>Last modified:</b> 2014-05-23</p>
<p><b>View all other</b> <a href="lwg-index.html#rand.req.seedseq">issues</a> in [rand.req.seedseq].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
LWG issue <a href="lwg-defects.html#2180">2180</a> points out some deficiences in regard to the specification of the library-provided
type <tt>std::seed_seq</tt> regarding exceptions, but there is another specification problem 
in regard to general types satisfying the <em>seed sequence</em> constraints (named <tt>SSeq</tt>) as described in 
26.5.1.2 [rand.req.seedseq].
<p/>
26.5.3 [rand.eng] p3 and 26.5.4.1 [rand.adapt.general] p3 say upfront:
</p>
<blockquote><p>
Except where specified otherwise, no function described in this section 
26.5.3 [rand.eng]/26.5.4 [rand.adapt] throws an exception.
</p></blockquote>
<p>
This constraint causes problems, because the described templates in these sub-clauses depend on operations of 
<tt>SSeq::generate()</tt> which is a function template, that depends both on operations provided by the 
implementor of <tt>SSeq</tt> (e.g. of <tt>std::seed_seq</tt>), and those of the random access iterator type 
provided by the caller. With class template <tt>linear_congruential_engine</tt> we have just one example for a user 
of <tt>SSeq::generate()</tt> via:
</p>
<blockquote><pre>
template&lt;class Sseq&gt; 
linear_congruential_engine&lt;&gt;::linear_congruential_engine(Sseq&amp; q);

template&lt;class Sseq&gt; 
void linear_congruential_engine&lt;&gt;::seed(Sseq&amp; q);
</pre></blockquote>
<p>
None of these operations has an exclusion rule for exceptions.
<p/>
As described in <a href="lwg-defects.html#2180">2180</a> the wording for <tt>std::seed_seq</tt> should and can be fixed to ensure that 
operations of <tt>seed_seq::generate()</tt> won't throw except from operations of the provided iterator range, 
but there is no corresponding "safety belt" for user-provided <tt>SSeq</tt> types, since 26.5.1.2 [rand.req.seedseq]
does not impose no-throw requirements onto operations of <em>seed sequences</em>.
</p>

<ol style="list-style-type:upper-roman">

<li><p>
A quite radical step to fix this problem would be to impose general no-throw requirements on the expression
<tt>q.generate(rb,re)</tt> from Table 115, but this is not as simple as it looks initially, because this
function again depends on general types that are mutable random access iterators. Typically, we do not
impose no-throw requirements on iterator operations and this would restrict general seed sequences where
exceptions are not a problem. Furthermore, we do not impose comparable constraints for other expressions,
like that of the expression <tt>g()</tt> in Table 116 for good reasons, e.g. <tt>random_device::operator()</tt>
explicitly states when it throws exceptions.
</p></li>

<li><p>
A less radical variant of the previous suggestion would be to add a normative requirement on the expression
<tt>q.generate(rb,re)</tt> from Table 115 that says: "Throws nothing if operations of <tt>rb</tt> and <tt>re</tt> 
do not throw exceptions". Nevertheless we typically do not describe <em>conditional</em> Throws elements in proper
requirement sets elsewhere (Container requirements excluded, they just describe the containers from Clause 23)
and this may exclude resonable implementations of seed sequences that could throw exceptions under rare
situations. 
</p></li>

<li><p>
The iterator arguments provided to <tt>SSeq::generate()</tt> for operations in templates of 26.5.3 [rand.eng] and 
26.5.4 [rand.adapt] are under control of implementations, so we could impose stricter exceptions requirements
on <tt>SSeq::generate()</tt> for <tt>SSeq</tt> types that are used to instantiate member templates in 26.5.3 [rand.eng] 
and 26.5.4 [rand.adapt] solely.
</p></li>

<li><p>
We simply add extra wording to the introductive parts of 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]
that specify that operations of the engine (adaptor) templates that depend on a template parameter <tt>SSeq</tt>
throw no exception unless <tt>SSeq::generate()</tt> throws an exception.
</p></li>
</ol>

<p>
Given these options I would suggest to apply the variant described in the fourth bullet.
<p/>
The proposed resolution attempts to reduce a lot of the redundancies of requirements in the introductory paragraphs of 
26.5.3 [rand.eng] and 26.5.4 [rand.adapt] by introducing a new intermediate sub-clause 
"Engine and engine adaptor class templates" following sub-clause 26.5.2 [rand.synopsis]. This approach also
solves the problem that currently 26.5.3 [rand.eng] also describes requirements that apply for
26.5.4 [rand.adapt] (Constrained templates involving the <tt>Sseq</tt> parameters).
</p>

<p><i>[2013-04-20, Bristol]</i></p>


<p>
Remove the first bullet point:
</p>
<blockquote><p>
?- Throughout this sub-clause general requirements and conventions are described that apply to every class 
template specified in sub-clause 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]. Phrases of the form "in those 
sub-clauses" shall be interpreted as equivalent to "in sub-clauses 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]". 
</p></blockquote>
<p>
Replace "in those sub-clauses" with "in sub-clauses 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]".
<p/>
Find another place for the wording. 
<p/>
Daniel: These are requirements on the implementation not on the types. I'm not comfortable in moving it to another place 
without double checking. 
<p/>
Improve the text (there are 4 "for"s): <em>for</em> copy constructors, <em>for</em> copy assignment operators, 
<em>for</em> streaming operators, and <em>for</em> equality and inequality operators are not shown in the synopses. 
<p/>
Move the information of this paragraph to the paragraphs it refers to: 
</p>
<blockquote><p>
"-?- Descriptions are provided in those sub-clauses only for engine operations that are not described in 
26.5.1.4 [rand.req.eng], for adaptor operations that are not described in 26.5.1.5 [rand.req.adapt], or for 
operations where there is additional semantic information. In particular, declarations for copy constructors, for 
copy assignment operators, for streaming operators, and for equality and inequality operators are not shown in the synopses." 
</p></blockquote>
<p>
Alisdair: I prefer duplication here than consolidation/reference to these paragraphs. 
<p/>
The room showed weakly favjust or for duplication. 
</p>

<p>
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<ol>
<li><p>Add a new sub-clause titled "Engine and engine adaptor class templates" following sub-clause 
26.5.2 [rand.synopsis] (but at the same level) and add one further sub-clause "General" as
child of the new sub-clause as follows:
<p/>
<ins>Engine and engine adaptor class templates [rand.engadapt]</ins>
<p/>
<ins>General [rand.engadapt.general]</ins>
</p>
<blockquote><p>
<ins>-?- Throughout this sub-clause general requirements and conventions are described that apply to every class 
template specified in sub-clause 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]. Phrases of the 
form "in those sub-clauses" shall be interpreted as equivalent to "in sub-clauses 26.5.3 [rand.eng] and 
26.5.4 [rand.adapt]".
</ins>
<p/>
<ins>-?- Except where specified otherwise, the complexity of each function specified in those sub-clauses is constant.</ins>
<p/>
<ins>-?- Except where specified otherwise, no function described in those sub-clauses throws an exception.</ins>
<p/>
<ins>-?- Every function described in those sub-clauses that has a function parameter <tt>q</tt> of type
<tt>SSeq&amp;</tt> for a template type parameter named <tt>SSeq</tt> that is different from type <tt>std::seed_seq</tt> 
throws what and when the invocation of <tt>q.generate</tt> throws.</ins>
<p/>
<ins>-?- Descriptions are provided in those sub-clauses only for engine operations that are not described in 
26.5.1.4 [rand.req.eng], for adaptor operations that are not described in 26.5.1.5 [rand.req.adapt],
or for operations where there is additional semantic information. In particular, declarations for copy constructors,
for copy assignment operators, for streaming operators, and for equality and inequality operators
are not shown in the synopses.</ins>
<p/>
<ins>-?- Each template specified in those sub-clauses requires one or more relationships, involving the value(s) of
its non-type template parameter(s), to hold. A program instantiating any of these templates is ill-formed if
any such required relationship fails to hold.</ins>
<p/>
<ins>-?- For every random number engine and for every random number engine adaptor <tt>X</tt> defined in those 
sub-clauses:</ins>
</p>
<ul>
<li><p>
<ins>if the constructor</ins>
</p>
<blockquote><pre>
<ins>template &lt;class Sseq&gt; explicit X(Sseq&amp; q);</ins>
</pre></blockquote>
<p>
<ins>is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this constructor shall not
participate in overload resolution;</ins>
</p>
</li>

<li><p>
<ins>if the member function</ins>
</p>
<blockquote><pre>
<ins>template &lt;class Sseq&gt; void seed(Sseq&amp; q);</ins>
</pre></blockquote>
<p>
<ins>is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this function shall not
participate in overload resolution;</ins>
</p>
</li>
</ul>
<p>
<ins>The extent to which an implementation determines that a type cannot be a seed sequence is unspecified,
except that as a minimum a type shall not qualify as a seed sequence if it is implicitly convertible to
<tt>X::result_type</tt>.</ins>
</p>
</blockquote>

</li>

<li><p>Edit the contents of sub-clause 26.5.3 [rand.eng] as indicated:</p>

<blockquote><p>
-1- Each type instantiated from a class template specified in this section 26.5.3 [rand.eng] satisfies the 
requirements of a random number engine (26.5.1.4 [rand.req.eng]) type <ins>and the general implementation 
requirements specified in sub-clause [rand.engadapt.general]</ins>.
<p/>
<del>-2- Except where specified otherwise, the complexity of each function specified in this section 26.5.3 [rand.eng] 
is constant.</del>
<p/>
<del>-3- Except where specified otherwise, no function described in this section 26.5.3 [rand.eng] throws an exception.</del>
<p/>
<del>-4- Descriptions are provided in this section 26.5.3 [rand.eng] only for engine operations that are not 
described in 26.5.1.4 [rand.req.eng] [&hellip;]</del>
<p/>
<del>-5- Each template specified in this section 26.5.3 [rand.eng] requires one or more relationships, 
involving the value(s) of its non-type template parameter(s), to hold. [&hellip;]</del>
<p/>
<del>-6- For every random number engine and for every random number engine adaptor <tt>X</tt> defined in this subclause
(26.5.3 [rand.eng]) and in sub-clause 26.5.3 [rand.eng]: [&hellip;]</del>
</p></blockquote>

</li>

<li><p>Edit the contents of sub-clause 26.5.4.1 [rand.adapt.general] as indicated:</p>

<blockquote><p>
-1- Each type instantiated from a class template specified in this section <del>26.5.3 [rand.eng]</del><ins>26.5.4 [rand.adapt]</ins> satisfies the 
requirements of a random number engine adaptor (26.5.1.5 [rand.req.adapt]) type <ins>and the general 
implementation requirements specified in sub-clause [rand.engadapt.general]</ins>.
<p/>
<del>-2- Except where specified otherwise, the complexity of each function specified in this section 26.5.4 [rand.adapt] 
is constant.</del>
<p/>
<del>-3- Except where specified otherwise, no function described in this section 26.5.4 [rand.adapt] throws an exception.</del>
<p/>
<del>-4- Descriptions are provided in this section 26.5.4 [rand.adapt] only for engine operations that are not 
described in 26.5.1.5 [rand.req.adapt] [&hellip;]</del>
<p/>
<del>-5- Each template specified in this section 26.5.4 [rand.adapt] requires one or more relationships, involving 
the value(s) of its non-type template parameter(s), to hold. [&hellip;]</del>
</p></blockquote>

</li>

</ol>
</blockquote>

<p><i>[2014-02-09, Daniel provides alternative resolution]</i></p>


<p><i>[2014-05-22, Daniel syncs with recent WP]</i></p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Edit the contents of sub-clause 26.5.3 [rand.eng] as indicated:</p>

<blockquote><p>
-1- Each type instantiated from a class template specified in this section 26.5.3 [rand.eng] satisfies the 
requirements of a random number engine (26.5.1.4 [rand.req.eng]) type.
<p/>
-2- Except where specified otherwise, the complexity of each function specified in this section 26.5.3 [rand.eng] 
is constant.
<p/>
-3- Except where specified otherwise, no function described in this section 26.5.3 [rand.eng] throws an exception.
<p/>
<ins>-?- Every function described in this section 26.5.3 [rand.eng] that has a function parameter <tt>q</tt> of 
type <tt>Sseq&amp;</tt> for a template type parameter named <tt>Sseq</tt> that is different from type <tt>std::seed_seq</tt> 
throws what and when the invocation of <tt>q.generate</tt> throws.</ins>
<p/>
-4- Descriptions are provided in this section 26.5.3 [rand.eng] only for engine operations that are not 
described in 26.5.1.4 [rand.req.eng] or for operations where there is additional semantic information. In particular, 
declarations for copy constructors, <del>for</del> copy assignment operators, <del>for</del> streaming operators, <del>and 
for</del> equality <ins>operators,</ins> and inequality operators are not shown in the synopses.
<p/>
-5- Each template specified in this section 26.5.3 [rand.eng] requires one or more relationships, 
involving the value(s) of its non-type template parameter(s), to hold. A program instantiating any of these templates is 
ill-formed if any such required relationship fails to hold.
<p/>
-6- For every random number engine and for every random number engine adaptor <tt>X</tt> defined in this subclause
(26.5.3 [rand.eng]) and in sub-clause 26.5.4 [rand.adapt]: 
</p>
<ul>
<li><p>
if the constructor
</p>
<blockquote><pre>
template &lt;class Sseq&gt; explicit X(Sseq&amp; q);
</pre></blockquote>
<p>
is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this constructor shall not
participate in overload resolution;
</p>
</li>
<li><p>
if the member function
</p>
<blockquote><pre>
template &lt;class Sseq&gt; void seed(Sseq&amp; q);
</pre></blockquote>
<p>
is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this function shall not
participate in overload resolution;
</p>
</li>
</ul>
<p>
The extent to which an implementation determines that a type cannot be a seed sequence is unspecified,
except that as a minimum a type shall not qualify as a seed sequence if it is implicitly convertible to
<tt>X::result_type</tt>.
</p>
</blockquote>
</li>

<li><p>Edit the contents of sub-clause 26.5.4.1 [rand.adapt.general] as indicated:</p>

<blockquote><p>
-1- Each type instantiated from a class template specified in this section 
<del>26.5.3 [rand.eng]</del><ins>26.5.4 [rand.adapt]</ins> satisfies the requirements of a 
random number engine adaptor (26.5.1.5 [rand.req.adapt]) type.
<p/>
-2- Except where specified otherwise, the complexity of each function specified in this section 26.5.4 [rand.adapt] 
is constant.
<p/>
-3- Except where specified otherwise, no function described in this section 26.5.4 [rand.adapt] throws an exception.
<p/>
<ins>-?- Every function described in this section 26.5.4 [rand.adapt] that has a function parameter <tt>q</tt> of 
type <tt>Sseq&amp;</tt> for a template type parameter named <tt>Sseq</tt> that is different from type <tt>std::seed_seq</tt> 
throws what and when the invocation of <tt>q.generate</tt> throws.</ins>
<p/>
-4- Descriptions are provided in this section 26.5.4 [rand.adapt] only for adaptor operations that are not 
described in section 26.5.1.5 [rand.req.adapt] or for operations where there is additional semantic information. In particular, 
declarations for copy constructors, <del>for</del> copy assignment operators, <del>for</del> streaming operators, <del>and for</del> 
equality <ins>operators,</ins> and inequality operators are not shown in the synopses.
<p/>
-5- Each template specified in this section 26.5.4 [rand.adapt] requires one or more relationships, involving 
the value(s) of its non-type template parameter(s), to hold. A program instantiating any of these templates is ill-formed if
any such required relationship fails to hold.
</p></blockquote>
</li>

<li><p>Edit the contents of sub-clause 26.5.8.1 [rand.dist.general] p2 as indicated: [<i>Drafting note</i>: These
editorial changes are just for consistency with those applied to 26.5.3 [rand.eng] and 
26.5.4.1 [rand.adapt.general] &mdash; <i>end drafting note</i>]</p>

<blockquote><p>
-2- Descriptions are provided in this section 26.5.8 [rand.dist] only for distribution operations that are not 
described in 26.5.1.6 [rand.req.dist] or for operations where there is additional semantic information. In particular, 
declarations for copy constructors, <del>for</del> copy assignment operators, <del>for</del> streaming operators, <del>and for</del> 
equality <ins>operators,</ins> and inequality operators are not shown in the synopses.
</p></blockquote>
</li>

</ol>





<hr>
<h3><a name="2183"></a>2183. Muddled allocator requirements for <tt>match_results</tt> constructors</h3>
<p><b>Section:</b> 28.10.1 [re.results.const], 28.10.6 [re.results.all] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-08-29 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#re.results.const">active issues</a> in [re.results.const].</p>
<p><b>View all other</b> <a href="lwg-index.html#re.results.const">issues</a> in [re.results.const].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
28.10.1 [re.results.const] p1 says:
</p>
<blockquote><p>
In all <tt>match_results</tt> constructors, a copy of the <tt>Allocator</tt> argument shall be used for any memory 
allocation performed by the constructor or member functions during the lifetime of the object.
</p></blockquote>
<p>
There are three constructors:
</p>
<blockquote><pre>
match_results(const Allocator&amp; = Allocator());
match_results(const match_results&amp; m);
match_results(match_results&amp;&amp; m) noexcept;
</pre></blockquote>
<p>
The second and third constructors do no have an <tt>Allocator</tt> argument, so despite the "all <tt>match_results</tt> 
constructors", it is not possible to use "the <tt>Allocator</tt> argument" for the second and third constructors.
<p/>
The requirements for those two constructors also does not give any guidance. The second constructor has no language 
about allocators, and the third states that the stored <tt>Allocator</tt> value is move constructed from 
<tt>m.get_allocator()</tt>, but doesn't require using that allocator to allocate memory.
<p/>
The same basic problem recurs in 28.10.6 [re.results.all], which gives the required return value for 
<tt>get_allocator()</tt>:
</p>
<blockquote><p>
<i>Returns</i>: A copy of the <tt>Allocator</tt> that was passed to the object's constructor or, if that allocator 
has been replaced, a copy of the most recent replacement.
</p></blockquote>
<p>
Again, the second and third constructors do not take an <tt>Allocator</tt>, so there is nothing that meets this 
requirement when those constructors are used.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2184"></a>2184. Muddled allocator requirements for <tt>match_results</tt> assignments</h3>
<p><b>Section:</b> 28.10.1 [re.results.const], 28.10.6 [re.results.all] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-08-29 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#re.results.const">active issues</a> in [re.results.const].</p>
<p><b>View all other</b> <a href="lwg-index.html#re.results.const">issues</a> in [re.results.const].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The effects of the two assignment operators are specified in Table 141. Table 141 makes no mention of allocators, 
so, presumably, they don't touch the target object's allocator. That's okay, but it leaves the question: 
<tt>match_results::get_allocator()</tt> is supposed to return "A copy of the Allocator that was passed to the 
object's constructor or, if that allocator has been replaced, a copy of the most recent replacement"; if assignment 
doesn't replace the allocator, how can the allocator be replaced?
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2189"></a>2189. Throwing <tt>swap</tt> breaks unordered containers' state</h3>
<p><b>Section:</b> 23.2.5.1 [unord.req.except] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2012-09-23 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The hash functor and key-comparison functor of unordered containers are allowed to throw on <tt>swap</tt>.
</p>
<p>
23.2.5.1 [unord.req.except]p3 "For unordered associative containers, no <tt>swap</tt> function throws
an exception unless that exception is thrown by the swap of the container's Hash or Pred object (if any)."
</p>
<p>
In such a case we must offer the basic exception safety guarantee, where both objects are left in valid
but unspecified states, and no resources are leaked.  This yields a corrupt, un-usable container if the
first <tt>swap</tt> succeeds, but the second fails by throwing, as the functors form a matched pair.
</p>
<p>
So our basic scenario is first, swap the allocators if the allocators propagate on swap, according to
<tt>allocator_traits</tt>.  Next we swap the pointers to our internal hash table data structures, so that
they match the allocators that allocated them.  (Typically, this operation cannot throw).  Now our containers
are back in a safely destructible state if an exception follows.
</p>
<p>
Next, let's say we swap the hash functor, and that throws.  We have a corrupt data structure, in that the
buckets are not correctly indexed by the correct functors, lookups will give unpredicatable results etc.
We can safely restore a usable state by forcibly clearing each container - which does not leak resources
and leaves us with two (empty but) usable containers.
</p>
<p>
Now let us assume that the hasher swap succeeds.  Next we swap the equality comparator functor, and this
too could throw. The important point to bear in mind is that these two functors form an important pairing
- two objects that compare equal by the equality functor must also hash to the same value.  If we swap
one without the other, we most likely leave the container in an unusable state, even if we clear out all
elements.
</p>
<p>
1. A colleague pointed out that the solution for this is to dynamically allocate the two functors, and then
we need only swap pointers, which is not a throwing operation.  And if we don't want to allocate on default
construction (a common QoI request), we might consider moving to a dynamically allocated functors whenever
<tt>swap</tt> is called, or on first insertion.  Of course, allocating memory in <tt>swap</tt> is a whole
new can of worms, but this does not really sound like the design we had intended.
</p>

<p>
2. The simplest option is to say that we do not support hasher or equality functors that throw on ADL
<tt>swap</tt>.  Note that the requirement is simply to not throw, rather than to be explicitly
marked as <tt>noexcept</tt>.  Throwing functors are allowed, so long as we never use values that
would actually manifest a throw when used in an unordered container.
</p>

<p>
Pablo went on to give me several more options, to be sure we have a full set to consider:
</p>
<p>
3. Disallow one or the other functor from throwing.  In that case, the 
possibly-throwing functor must be swapped first, then the other functor, 
the allocator, and the data pointer(s) afterwards (in any order -- there 
was a TC that allocator assignment and swap may not throw if the 
corresponding propagation trait is true.). Of course, the question 
becomes: which functor is allowed to throw and which one is not?
</p>
<p>
4. Require that any successful functor <tt>swap</tt> be reliably reversible.  
This is very inventive.  I know of no other place in the standard where 
such a requirement is stated, though I have occasionally wanted such a 
guarantee.
</p>
<p>
5. Allow a failed swap to leave the containers in a state where future 
insertions may fail for reasons other than is currently allowed.  
Specifically, if the hash and equality functors are out of sync, all 
insertions will fail.  Presumably some "incompletely swapped" exception 
would be thrown.  This is "slightly" inventive, although people have been 
discussing "radioactive" states for a while.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>



<p><b>Proposed resolution:</b></p>






<hr>
<h3><a name="2191"></a>2191. Incorrect specification of <tt>match_results(match_results&amp;&amp;)</tt></h3>
<p><b>Section:</b> 28.10.1 [re.results.const] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-10-02 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#re.results.const">active issues</a> in [re.results.const].</p>
<p><b>View all other</b> <a href="lwg-index.html#re.results.const">issues</a> in [re.results.const].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
28.10.1 [re.results.const]/3: "Move-constructs an object of class <tt>match_results</tt> satisfying the same 
postconditions as Table 141."
</p>
<p>
Table 141 lists various member functions and says that their results should be the results of the corresponding member 
function calls on <tt>m</tt>. But <tt>m</tt> has been moved from, so the actual requirement ought to be based on the 
value that <tt>m</tt> had <em>before</em> the move construction, not on <tt>m</tt> itself.
</p>
<p>
In addition to that, the requirements for the copy constructor should refer to Table 141.
<p/>
<u>Ganesh</u>:
<p/>
Also, the requirements for move-assignment should refer to Table 141. Further it seems as if in Table 141 all phrases of
"for all integers <tt>n &lt; m.size()</tt>" should be replaced by "for all <em>unsigned</em> integers 
<tt>n &lt; m.size()</tt>".
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2192"></a>2192. Validity and return type of <tt>std::abs(0u)</tt> is unclear</h3>
<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-10-02 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
<p><b>View all other</b> <a href="lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
In C++03 the following two programs are invalid:
</p>
<ol style="list-style-type:upper-alpha"><li>
<blockquote><pre>
#include &lt;cmath&gt;

int main() {
  std::abs(0u);
}
</pre></blockquote>
</li>
<li>
<blockquote><pre>
#include &lt;cstdlib&gt;

int main() {
  std::abs(0u);
}
</pre></blockquote>
</li>
</ol>
<p>
because none of the <tt>std::abs()</tt> overloads is a best match.
</p>
<p>
In C++11 the additional "sufficient overload" rule from 26.8 [c.math] p11 (see also LWG
<a href="lwg-defects.html#2086">2086</a>) can be read to be applicable to the <tt>std::abs()</tt> overloads as well, which
can lead to the following possible conclusions:
<p/>
<ol>
<li><p>The program</p>
<blockquote><pre>
#include &lt;type_traits&gt;
#include &lt;cmath&gt;

static_assert(std::is_same&lt;decltype(std::abs(0u)), double&gt;(), "Oops");

int main() {
  std::abs(0u); // Calls std::abs(double)
}
</pre></blockquote>
<p>
is required to be well-formed, because of sub-bullet 2 ("[..] or an integer type [..]") of 
26.8 [c.math] p11 (Note that the current resolution of LWG <a href="lwg-defects.html#2086">2086</a> doesn't
fix this problem).
</p>
</li>
<li><p>Any translation unit including both <tt>&lt;cmath&gt;</tt> and <tt>&lt;cstdlib&gt;</tt>
might be ill-formed because of two conflicting requirements for the return type of the overload
<tt>std::abs(int)</tt>.
</p>
</li>
</ol>
</p>

<p>
It seems to me that at least the second outcome is not intended, personally I think that both
are unfortunate: In contrast to all other floating-point functions explicitly listed in sub-clause 
26.8 [c.math], the <tt>abs</tt> overloads have a special and well-defined meaning for 
signed integers and thus have explicit overloads returning a signed integral type. I also believe that 
there is no problem accepting that <tt>std::fabs(0u)</tt> is well-defined with return type <tt>double</tt>, 
because the leading 'f' clearly signals that we have a floating point function here. But the expected 
return type of <tt>std::abs(0u)</tt> seems less than clear to me. A very reasonable answer could be that 
this has the same type as its argument type, alternatively it could be a reasonably chosen signed 
integer type, or a floating point type. It should also be noted, that the corresponding
"generic type function" rule set from C99/C1x in 7.25 p2+3 is restricted to the floating-point functions
from <tt>&lt;math.h&gt;</tt> and <tt>&lt;complex.h&gt;</tt>, so cannot be applied to the <tt>abs</tt>
functions (but to the <tt>fabs</tt> functions!).
<p/>
Selecting a signed integer return type for unsigned input values can also problematic: The directly
corresponding signed integer type would give half of the possible argument values an implementation-defined
result value. Choosing the first signed integer value that can represent all positive values would solve this
problem for <tt>unsigned int</tt>, but there would be no clear answer for the input type <tt>std::uintmax_t</tt>.
</p>
<p>
Based on this it seems to me that the C++03 state in regard to unsigned integer values was the better
situation, alerting the user that this code is ambigious at the moment (This might be change with different core-language
rules as described in N3387).
</p>

<p><i>[2013-04-20, Bristol]</i></p>


<p>
Resolution: leave as new and bring it back in Chicago. 
</p>

<p><i>[2013-09 Chicago]</i></p>

<p>
This issue also relates to LWG <a href="lwg-active.html#2294">2294</a>
<p/> 
STL: these two issues should be bundled 
<p/>
Stefanus: do what Pete says, and add overloads for unsigned to return directly 
<p/>
STL: agree Consensus that this is an issue 
<p/>
Walter: motion to move to Open 
<p/>
STL: no wording for <a href="lwg-active.html#2294">2294</a> 
<p/>
Stefanus: move to open and note the 2 issues are related and should be moved together 
<p/>
Stefanus: add and define unsigned versions of <tt>abs()</tt>
</p>

<p><i>[2014-02-03 Howard comments]</i></p>

<p>
Defining <tt>abs()</tt> for unsigned integers is a bad idea. Doing so would turn compile time errors into run time errors, 
especially in C++ where we have templates, and the types involved are not always apparent to the programmer at design time.  
For example, consider:
</p>
<blockquote><pre>
template &lt;class Int&gt;
Int
analyze(Int x, Int y)
{
  // ...
  if (std::abs(<span style="color:#C80000;font-weight:bolder">x - y</span>) &lt; threshold)
  {
    // ...
  }
  // ...
}
</pre></blockquote>
<p>
<tt>std::abs(<i>expr</i>)</tt> is often used to ask: Are these two numbers sufficiently close?  When the assumption is that 
the two numbers are signed (either signed integral, or floating point), the logic is sound. But when the same logic is 
accidentally used with an arithmetic type not capable of representing negative numbers, and especially if unsigned overflow 
will silently happen, then the logic is no longer correct:
</p>
<blockquote><pre>
auto i = analyze(20u, 21u);  // Today a compile time error
    // But with <tt>abs(unsigned)</tt> becomes a run time error
</pre></blockquote>
<p>
This is not idle speculation. Search the net for "<tt>abs unsigned</tt>" 
<a href="http://www.avrfreaks.net/index.php?name=PNphpBB2&amp;file=printview&amp;t=35514&amp;start=0">here</a> or 
<a href="http://fischerlaender.de/mysql/surprising-mysql-behaviour-using-unsigned-int">here</a>.
<p/>
In C++11, <tt>chrono</tt> <tt>duration</tt>s and <tt>time_point</tt>s are allowed to be based on unsigned integers. Taking the 
absolute value of the difference of two such <tt>time_point</tt>s would be easy to accidentally do (say in code templated on 
<tt>time_point</tt>s), and would certainly be a logic bug, caught at compile time unless we provide the error prone <tt>abs(unsigned)</tt>.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Change 26.8 [c.math] p11 as indicated:</p>
<blockquote><p>
-11- Moreover<ins>, except for the <tt>abs</tt> functions</ins>, there shall be additional overloads sufficient to ensure:
<p/>
[&hellip;]
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="2195"></a>2195. Missing constructors for <tt>match_results</tt></h3>
<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-10-06 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all other</b> <a href="lwg-index.html#re.results">issues</a> in [re.results].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The requirement expressed in 28.10 [re.results] p2
</p>
<blockquote><p>
The class template <tt>match_results</tt> shall satisfy the requirements of an allocator-aware container and of a
sequence container, as specified in 23.2.3 [sequence.reqmts], except that only operations defined for 
const-qualified sequence containers are supported.
</p></blockquote>
<p>
can be read to require the existence of the described constructors from as well, but they do not exist in the
synopsis. 
<p/>
The missing sequence constructors are: 
</p>
<blockquote><pre>
match_results(initializer_list&lt;value_type&gt;);
match_results(size_type, const value_type&amp;);
template&lt;class InputIterator&gt; match_results(InputIterator, InputIterator);
</pre></blockquote>
<p>
The missing allocator-aware container constructors are:
</p>
<blockquote><pre>
match_results(const match_results&amp;, const Allocator&amp;);
match_results(match_results&amp;&amp;, const Allocator&amp;);
</pre></blockquote>
<p>
It should be clarified, whether (a) constructors are an exception of above mentioned operations or (b) whether
at least some of them (like those accepting a <tt>match_results</tt> value and an allocator) should be added.
<p/>
As visible in several places of the standard (including the core language), constructors seem usually to be considered 
as "operations" and they certainly can be invoked for const-qualified objects.
<p/>
The below given proposed resolution applies only the minimum necessary fix, i.e. it excludes constructors from
above requirement. 
</p>

<p><i>[2013-04-20, Bristol]</i></p>


<p>
Check current implementations to see what they do and, possibly, write a paper.   
</p>

<p><i>[2013-09 Chicago]</i></p>

<p>
Ask Daniel to update the proposed wording to include the allocator copy and move constructors.
</p>

<p><i>[2014-01-18 Daniel changes proposed resolution]</i></p>

<p>
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
</p>

<blockquote class="note">
<ol>
<li><p>Change 28.10 [re.results] p2 as indicated:</p>
<blockquote><p>
The class template <tt>match_results</tt> shall satisfy the requirements of an allocator-aware container and of a
sequence container, as specified in 23.2.3 [sequence.reqmts], except that only operations defined for 
const-qualified sequence containers <ins>that are not constructors</ins> are supported.
</p></blockquote>
</li>
</ol>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 28.10 [re.results] p4, class template <tt>match_results</tt> synopsis, as indicated:</p>
<blockquote><pre>
[&hellip;]
// 28.10.1, construct/copy/destroy:
explicit match_results(const Allocator&amp; a = Allocator());
match_results(const match_results&amp; m);
<ins>match_results(const match_results&amp; m, const Allocator&amp; a);</ins>
match_results(match_results&amp;&amp; m) noexcept;
<ins>match_results(match_results&amp;&amp; m, const Allocator&amp; a) noexcept;</ins>
[&hellip;]
</pre></blockquote>
</li>

<li><p>Change 28.10.1 [re.results.const]  as indicated: [<i>Drafting note:</i> Paragraph 6 as currently written,
makes not much sense, because the <tt>noexcept</tt> does not allow any exception to propagate. Further-on, the allocator requirements
do not allow for throwing move constructors. Deleting it seems to be near to editorial &mdash; <i>end drafting note</i>]</p>
<blockquote>

<pre>
match_results(const match_results&amp; m);
<ins>match_results(const match_results&amp; m, const Allocator&amp; a);</ins>
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> Constructs an object of class <tt>match_results</tt>, as a copy of <tt>m</tt>.
</p>
</blockquote>

<pre>
match_results(match_results&amp;&amp; m) noexcept;
<ins>match_results(match_results&amp;&amp; m, const Allocator&amp; a) noexcept;</ins>
</pre>
<blockquote>
<p>
-5- <i>Effects:</i> Move-constructs an object of class <tt>match_results</tt> from <tt>m</tt> satisfying the same postconditions
as Table 142. <del>Additionally</del><ins>For the first form</ins>, the stored <tt>Allocator</tt> value is move constructed 
from <tt>m.get_allocator()</tt>.
<p/>
<del>-6- <i>Throws:</i> Nothing if the allocator's move constructor throws nothing.</del>
</p>
</blockquote>

</blockquote>
</li>
</ol>






<hr>
<h3><a name="2198"></a>2198. <tt>max_load_factor(z)</tt> makes no strong guarantees, but bans useful behavior</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2012-10-09 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The user cannot specify a <tt>max_load_factor</tt> for their unordered container
at construction, it must be supplied after the event, when the container is
potentially not empty.  The contract for this method is deliberately vague, not
guaranteeing to use the value supplied by the user, and any value actually used
will be used as a ceiling that the container will <i>attempt</i> to respect.
</p>
<p>
The only guarantee we have is that, if user requests a <tt>max_load_factor</tt>
that is less than the current <tt>load_factor</tt>, then the operation will take
constant time, thus outlawing an implementation that chooses to rehash and so
preserve as a class invariant that <tt>load_factor &lt; max_load_factor</tt>.
</p>
<p>
Reasonable options conforming to the standard include ignoring the user's request
if the requested value is too low, or deferring the rehash to the next <tt>insert</tt>
operation and allowing the container to have a strange state (wrt <tt>max_load_factor</tt>)
until then - and there is still the question of rehashing if the next <tt>insert</tt>
is for a duplicate key in a unique container.
</p>
<p>
Given the deliberate vagueness of the current wording, to support a range of reasonable
(but not <i>perfect</i>) behaviors, it is not clear why the equally reasonable rehash
to restore the constraint should be outlawed.  It is not thought that this is a performance
critical operation, where users will be repeatedly setting low load factors on populated
containers, in a tight or (less unlikely) an instant response scenario.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
Alisdair to provide wording.
</p>



<p><b>Proposed resolution:</b></p>






<hr>
<h3><a name="2199"></a>2199. unordered containers are required to have an initial max load factor of 1.0</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2012-10-09 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The default constructor, allocator-aware constructor, and range-based constructors
for the unordered containers do not offer a means to control the initial
<tt>max_load_factor</tt>, so the standard mandates the value 1.0.  This seems overly
restrictive, as there is plenty of research suggesting a value between 0.5 and 1.0
is more often optimal for unique-key containers, and perhaps a slightly higher
value might be appropriate for multi-containers.
</p>
<p>
Rather than guess at the appropriate <tt>max_load_factor</tt>, it seems reasonable
that the standard should allow vendors to pick a value at their discretion, with
perhaps a note of advice.  It is less clear whether the default value should be
implementation-defined or unspecified, given the ease of a user determining this
by querying this attribute immediately after construction.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
Alisdair to provide wording.
</p>
<p>
Marshall: It seems to me that what you really want is to be able to pass a max load factor in the
constructor, but that's a different issue.
</p>
<p>
Alisdair agrees in principle, but concerned with adding yet more constructors to these classes.
</p>



<p><b>Proposed resolution:</b></p>






<hr>
<h3><a name="2201"></a>2201. Missing macro entries from C standard library</h3>
<p><b>Section:</b> C.4 [diff.library] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Kevin McCarty <b>Opened:</b> 2012-02-03 <b>Last modified:</b> 2014-03-02</p>
<p><b>View all other</b> <a href="lwg-index.html#diff.library">issues</a> in [diff.library].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
It seems that in C.4 [diff.library], Table 150 the following macros from 18.3.3 [c.limits], Table 31 
are missing:
</p>
<blockquote><pre>
LLONG_MIN 
LLONG_MAX
ULLONG_MAX
</pre></blockquote>
<p>
In addition in C.4 [diff.library], Table 150 the following macros from 18.3.3 [c.limits], Table 32 
are missing:
</p>
<blockquote><pre>
DECIMAL_DIG 
FLT_EVAL_METHOD
</pre></blockquote>
<p>
Furtheron it seems that in C.4 [diff.library], Table 149/150 further macros are missing as well, e.g. 
<tt>HUGE_VALF</tt>, <tt>INFINITY</tt>, etc.
</p>

<p><i>[2014-02 Issaquah:]</i></p>

<p>
This is an issue, all of C has not been updated for C99, C99 functions are missing, whole section needs to be overhauled.
<p/>
The issue needs to be updated for functions and other missing items and when that happens the issue title is wrong and
needs to be adapted.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2202"></a>2202. Missing allocator support by <tt>async</tt></h3>
<p><b>Section:</b> 30.6.8 [futures.async] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2012-10-19 <b>Last modified:</b> 2014-02-20</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.async">issues</a> in [futures.async].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
<tt>promise</tt>, <tt>packaged_task</tt>, and <tt>async</tt> are the only
places where a shared state is actually supposed to be allocated. Accordingly,
<tt>promise</tt> and <tt>packaged_task</tt> are "allocator-aware". But
function template <tt>async</tt> provides no way to provide an allocator.
</p>

<p><i>[2013-09 Chicago]</i></p>

<p>
Matt: deprecate async 
<p/>
Nico: read my paper 
<p/>
Alisdair: defer issues to wait for polymorphic allocators 
<p/>
Alisdair: defer, active topic of research Deferred 
</p>

<p><i>[2014-02-20 Re-open Deferred issues as Priority 4]</i></p>




<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2206"></a>2206. Inaccuracy in <tt>initializer_list</tt> constructor requirements</h3>
<p><b>Section:</b> 23.2.3 [sequence.reqmts], 23.2.4 [associative.reqmts], 23.2.5 [unord.req], 26.5.1.2 [rand.req.seedseq] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2012-10-21 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
<p><b>View all other</b> <a href="lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
In 23.2.3 [sequence.reqmts] p3, we have "<tt>il</tt> designates an object of type
<tt>initializer_list&lt;value_type&gt;</tt>", and then several functions that take
'<tt>il</tt>' as an argument. However, an expression like <tt>{1, 2, 'a'}</tt> is <em>not</em>
an object of type <tt>initializer_list&lt;int&gt;</tt> unless it's used to initialize
an explicitly-typed variable of that type. I believe we want:
</p>
<blockquote><pre>
std::vector&lt;int&gt; v;
v = {1, 2, 'a'};
</pre></blockquote>
<p>
to compile portably, so we should say something different when defining '<tt>il</tt>'. The 
same phrasing happens in 23.2.4 [associative.reqmts], 23.2.5 [unord.req], and 
26.5.1.2 [rand.req.seedseq].
<p/>
This may just be an editorial issue because the actual class synopses declare the functions 
to take <tt>initializer_list&lt;exact_type&gt;</tt>.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
This is definitely not NAD
</p>
<p>
Should copy the suggested wording as the proposed resolution.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2208"></a>2208. <tt>std::reverse_iterator</tt> should be a literal type</h3>
<p><b>Section:</b> 24.5.1 [reverse.iterators] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2012-10-30 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#reverse.iterators">issues</a> in [reverse.iterators].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
<tt>std::reverse_iterator::reverse_iterator(Iterator)</tt> should be constexpr
so that other constexpr functions can return <tt>reverse_iterator</tt>s. Of the
other methods, the other constructors, <tt>base()</tt>, <tt>operator+</tt>, <tt>operator-</tt>,
<tt>operator[]</tt>, and the non-member operators can probably also be
<tt>constexpr</tt>.
<p/>
<tt>operator*</tt> cannot be constexpr because it involves an assignment to a
member variable. Discussion starting with c++std-lib-33282 indicated
that it would be useful to make reverse_iterator a literal type
despite this restriction on its use at compile time.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2212"></a>2212. <tt>tuple_size</tt> for <tt>const pair</tt> request <tt>&lt;tuple&gt;</tt> header</h3>
<p><b>Section:</b> 20.2 [utility] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2012-11-09 <b>Last modified:</b> 2014-05-02</p>
<p><b>View all other</b> <a href="lwg-index.html#utility">issues</a> in [utility].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>&lt;utility&gt;</tt> header declares sufficient of the tuple API to specialize
the necessary templates for <tt>pair</tt>, notably <tt>tuple_size</tt> and
<tt>tuple_element</tt>.  However, it does not make available the partial specializations
that support cv-qualified template arguments, so while I can write the following after
including only <tt>&lt;utility&gt;</tt>: 
</p>
<blockquote><pre>
#include &lt;utility&gt;

using TestType = std::pair&lt;int, int&gt;;
static_assert(2 == std::tuple_size&lt;TestType&gt;(), "Pairs have two elements");
std::tuple_element&lt;0, TestType&gt;::type var{1};
</pre></blockquote>
<p>
the following may fail to compile unless I also include <tt>&lt;tuple&gt;</tt>:
</p>
<blockquote><pre>
#include &lt;utility&gt;

using TestType = const std::pair&lt;int, int&gt;;
static_assert(2 == std::tuple_size&lt;TestType&gt;(), "Pairs have two elements");
std::tuple_element&lt;0, TestType&gt;::type var{1};
</pre></blockquote>
<p>
Note, however, that the latter <em>may</em> compile with some standard library implementations
but not others, leading to subtle portability issues.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
Howard notes that we have the same issue with array, so any resolution should apply to that header too.
</p>

<p><i>[2013-10-18 Daniel provides wording]</i></p>


<p>
The suggested wording uses a similar approach as we already have in 24.7 [iterator.range] to
ensure that the range access templates are available when at least one of an enumerated list of header files is
included.
<p/>
I also think that the restricted focus on <tt>tuple_size</tt> of this issue is too narrow and should be extended to
the similar partial template specializations of <tt>tuple_element</tt> as well. Therefore the suggested wording
ensures this as well.
</p>

<p><i>[2014-03-27 Library reflector vote]</i></p>

<p>
The issue has been identified as Tentatively Ready based on eight votes in favour.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 20.4.2.5 [tuple.helper] as indicated:</p>

<blockquote><pre>
template &lt;class T&gt; class tuple_size&lt;const T&gt;;
template &lt;class T&gt; class tuple_size&lt;volatile T&gt;;
template &lt;class T&gt; class tuple_size&lt;const volatile T&gt;;
</pre><blockquote>
<p>
-3- Let <tt><i>TS</i></tt> denote <tt>tuple_size&lt;T&gt;</tt> of the <i>cv</i>-unqualified type <tt>T</tt>. Then 
each of the three templates shall meet the <tt>UnaryTypeTrait</tt> requirements (20.10.1) with a <tt>BaseCharacteristic</tt> of
</p>
<blockquote><pre>
integral_constant&lt;size_t, <i>TS</i>::value&gt;
</pre></blockquote>
<p>
<ins>-?- In addition to being available via inclusion of the <tt>&lt;tuple&gt;</tt> header, each of the three templates are
available when any of the headers <tt>&lt;array&gt;</tt> or <tt>&lt;utility&gt;</tt> are included.</ins>
</p>
</blockquote></blockquote>

<blockquote><pre>
template &lt;size_t I, class T&gt; class tuple_element&lt;I, const T&gt;;
template &lt;size_t I, class T&gt; class tuple_element&lt;I, volatile T&gt;;
template &lt;size_t I, class T&gt; class tuple_element&lt;I, const volatile T&gt;;
</pre><blockquote>
<p>
<ins>-?-</ins> Let <tt><i>TE</i></tt> denote <tt>tuple_element&lt;I, T&gt;</tt> of the <i>cv</i>-unqualified type <tt>T</tt>. 
Then each of the three templates shall meet the <tt>TransformationTrait</tt> requirements (20.10.1) with a member typedef 
<tt>type</tt> that names the following type:
</p>
<ul>
<li><p>
for the first specialization, <tt>add_const&lt;<i>TE</i>::type&gt;::type</tt>,
</p></li>
<li><p>
for the second specialization, <tt>add_volatile&lt;<i>TE</i>::type&gt;::type</tt>, and
</p></li>
<li><p>
for the third specialization, <tt>add_cv&lt;<i>TE</i>::type&gt;::type</tt>.
</p></li>
</ul>
<p>
<ins>-?- In addition to being available via inclusion of the <tt>&lt;tuple&gt;</tt> header, each of the three templates are
available when any of the headers <tt>&lt;array&gt;</tt> or <tt>&lt;utility&gt;</tt> are included.</ins>
</p>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2214"></a>2214. Clarify <tt>basic_ios::init</tt> call restrictions</h3>
<p><b>Section:</b> 27.5.5.2 [basic.ios.cons] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Andrey Semashev <b>Opened:</b> 2012-11-09 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There is an ambiguity in how <tt>std::basic_ios::init</tt> method (27.5.5.2 [basic.ios.cons]) 
can be used in the derived class. The Standard only specify the state of the <tt>basic_ios</tt> 
object after the call completes. However, in <tt>basic_ios</tt> default constructor description 
(27.5.5.2 [basic.ios.cons]) there is this sentence:
</p>
<blockquote><p>
<i>Effects</i>: Constructs an object of class <tt>basic_ios</tt> (27.5.3.7 [ios.base.cons]) 
leaving its member objects uninitialized. The object shall be initialized by calling <tt>basic_ios::init</tt> 
before its first use or before it is destroyed, whichever comes first; otherwise the behavior is undefined.
</p></blockquote>
<p>
This restriction hints that <tt>basic_ios::init</tt> should be called exactly
once before the object can be used or destroyed, because <tt>basic_ios::init</tt> 
may not know whether it was called before or not (i.e. whether its members are actually 
uninitialized or are initialized by the previous call to <tt>basic_ios::init</tt>). There 
is no such restriction in the <tt>basic_ios::init</tt> preconditions so it is not clear whether it is
allowed to call <tt>basic_ios::init</tt> multiple times or not.
<p/>
This problem has already affected publicly available implementations.
For example, Microsoft Visual C++ STL introduces a memory leak if
<tt>basic_ios::init</tt> is called multiple times, while GCC 4.7 and STLPort
reinitialize the <tt>basic_ios</tt> object correctly without memory leak or any
other undesired effects. There was a discussion of this issue on Boost
<a href="http://article.gmane.org/gmane.comp.lib.boost.devel/235659">developers mailing list</a>, 
and there is a <a href="https://sourceforge.net/apps/trac/boost-log/ticket/2#comment:4">test case 
that reproduces the problem</a>. The test case is actually a bug report for my Boost.Log library, 
which attempts to cache <tt>basic_ostream</tt>-derived objects internally to avoid expensive construction 
and destruction. My stream objects allowed resetting the stream buffer pointers the stream
is attached to, without requiring to destroy and construct the stream.
<p/>
My personal view of the problem and proposed resolution follows.
<p/>
While apparently the intent of <tt>basic_ios::init</tt> is to provide a way to
initialize <tt>basic_ios</tt> after default construction, I see no reason to
forbid it from being called multiple times to reinitialize the stream.
Furthermore, it is possible to implement a conforming <tt>basic_ios</tt> that
does not have this restriction.
<p/>
The quoted above section of the Standard that describes the effects of
the default constructor is misleading. The Standard does not mandate
any data members of <tt>basic_ios</tt> or <tt>ios_base</tt> (27.5.3 [ios.base]), which
it derives from. This means that the implementation is allowed to use
non-POD data members with default constructors that initialize the
members with particular default values. For example, in the case of
Microsoft Visual C++ STL the leaked memory is an <tt>std::locale</tt> instance
that is dynamically allocated during <tt>basic_ios::init</tt>, a raw pointer to
which is stored within ios_base. It is possible to store e.g. an
<tt>unique_ptr</tt> instead of a raw pointer as a member of <tt>ios_base</tt>, the smart
pointer will default initialize the underlying raw pointer on default
construction and automatically destroy the allocated object upon being
reset or destroyed, which would eliminate the leak and allow
<tt>basic_ios::init</tt> to be called multiple times. This leads to conclusion
that the default constructor of <tt>basic_ios</tt> cannot leave "its member
objects uninitialized" but instead performs default initialization of
the member objects, which would mean the same thing in case of POD types.
<p/>
However, I feel that restricting <tt>ios_base</tt> and <tt>basic_ios</tt> members to
non-POD types is not acceptable. Since multiple calls to <tt>basic_ios::init</tt> are 
not forbidden by the Standard, I propose to correct the <tt>basic_ios</tt> default 
constructor description so that it is allowed to destroy <tt>basic_ios</tt> object 
without calling <tt>basic_ios::init</tt>. This would imply that any raw members of 
<tt>basic_ios</tt> and <tt>ios_base</tt> should be initialized to values suitable for 
destruction (essentially, this means only initializing raw pointers to NULL). The new 
wording could look like this:
</p>
<blockquote><p>
<i>Effects</i>: Constructs an object of class <tt>basic_ios</tt> (27.5.3.7 [ios.base.cons])
initializing its member objects to unspecified state, only suitable for <tt>basic_ios</tt> destruction.
The object shall be initialized by calling <tt>basic_ios::init</tt> before its first use; otherwise 
the behavior is undefined.
</p></blockquote>
<p>
This would remove the hint that <tt>basic_ios::init</tt> must be called exactly
once. Also, this would remove the requirement for <tt>basic_ios::init</tt> to
be called at all before the destruction. This is also an important issue because 
the derived stream constructor may throw an exception before it manages to call 
<tt>basic_ios::init</tt> (for example, if the streambuf constructor throws), and 
in this case the <tt>basic_ios</tt> destructor has undefined behavior.
<p/>
To my mind, the described modification is sufficient to resolve the issue. But to 
emphasize the possibility to call <tt>basic_ios::init</tt> multiple times, a remark 
or a footnote for <tt>basic_ios::init</tt> postconditions could be added to explicitly 
state the semantics of calling it multiple times. The note could read as follows:
</p>
<blockquote><p>
The function can be called multiple times during the object lifetime. Each subsequent 
call reinitializes the object to the described in postconditions initial state.
</p></blockquote>

<p><i>[2013-04-20, Bristol]</i></p>


<p>
Alisdair: The current wording is unclear but the proposed resolution is wrong
<p/>
Solution: Clarify that <tt>init</tt> must be called once and only once. Move then to review. 
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3485.</p>

<ol>
<li><p>Edit 27.5.5.2 [basic.ios.cons] as indicated:</p>
<blockquote><pre>
basic_ios();
</pre>
<blockquote>
<p>
-2- <i>Effects</i>: Constructs an object of class <tt>basic_ios</tt> (27.5.3.7 [ios.base.cons]) 
<del>leaving its member objects uninitialized</del><ins>initializing its member objects to unspecified state, 
only suitable for <tt>basic_ios</tt> destruction</ins>. The object shall be initialized by calling 
<tt>basic_ios::init</tt> before its first use <del>or before it is destroyed, whichever comes first</del>; 
otherwise the behavior is undefined.
</p>
</blockquote>
<pre>
void init(basic_streambuf&lt;charT,traits&gt;* sb);
</pre><blockquote>
<p>
<i>Postconditions</i>: The postconditions of this function are indicated in Table 128.
<p/>
<ins>-?- <i>Remarks</i>: The function can be called multiple times during the object lifetime. Each subsequent 
call reinitializes the object to the described in postconditions initial state.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2215"></a>2215. (unordered) associative container functors should be <tt>CopyConstructible</tt></h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts], 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2012-11-14 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The requirements on the functors used to arrange elements in the various associative and
unordered containers are given by a set of expressions in tables 102 &mdash; Associative container
requirements, and 103 &mdash; Unordered associative container requirements.  In keeping with Library
convention these expressions make the minimal requirements necessary on their types.  For
example, we have the following 3 row extracts for the unordered containers:
</p>
<table>
<tr>
  <td>
    <b>Expression</b>
  </td>
  <td>
    <b>Assertion/note pre-/post-condition</b>
  </td>
</tr>

<tr>
  <td>
<pre>
<tt>X(n, hf, eq)</tt>
<tt>X a(n, hf, eq)</tt>
</pre>
  </td>
  <td>
    <i>Requires:</i> <tt>hasher</tt> and <tt>key_equal</tt> are <tt>CopyConstructible</tt>.
 </td>
</tr>

<tr>
  <td>
<pre>
<tt>X(n, hf)</tt>
<tt>X a(n, hf)</tt>
</pre>
  </td>
  <td>
    <i>Requires:</i> <tt>hasher</tt> is <tt>CopyConstructible</tt> and 
                  <tt>key_equal</tt> is <tt>DefaultConstructible</tt>.
 </td>
</tr>

<tr>
  <td>
<pre>
<tt>X(n)</tt>
<tt>X a(n)</tt>
</pre>
  </td>
  <td>
    <i>Requires:</i> <tt>hasher</tt> and <tt>key_equal</tt> are <tt>DefaultConstructible</tt>.
 </td>
</tr>
</table>

<p>
However, the signature for each class template requires that the functors must effectively be
<tt>CopyConstructible</tt> for each of these expressions:
</p>

<blockquote><pre>
template &lt;class Key,
          class T,
          class Hash  = hash&lt;Key>,
          class Pred  = std::equal_to&lt;Key>,
          class Allocator = std::allocator&lt;std::pair&lt;const Key, T> > >
class unordered_map
{
  <i>...</i>

  <i>// construct/destroy/copy</i>
  explicit unordered_map(size_type n = <i>see below</i>,
                         const hasher&amp; hf = hasher(),
                         const key_equal&amp; eql = key_equal(),
                         const allocator_type&amp; a = allocator_type());

  <i>...</i>
}
</pre></blockquote>

<p>
The letter of the standard can be honored as long as implementors recognize
their freedom to split this one signature into multiple overloads, so that
the documented default arguments (requiring a <tt>CopyConstructible</tt> functor)
are not actually passed as default arguments.
</p>
<p>
As we look into the requirements for the copy constructor and copy-assignment
operator, the requirements are even more vague, as the explicit requirements on
the functors are not called out, other than saying that the functors are copied.
</p>
<p>
Must the functors be <tt>CopyAssignable</tt>? Or is <tt>CopyConstructible</tt>
sufficient in this case?  Do we require that the functors be <tt>Swappable</tt>
so that the copy-swap idiom can be deployed here?  Note that a type that is both
<tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> is still not guaranteed to
be <tt>Swappable</tt> as the user may delete the <tt>swap</tt> function for their
type in their own namespace, which would be found via ADL.
</p>
<p>
Some clean-up of the requirements table looks necessary, to at least document the
assignment behavior.  In addition, we should have clear guidance on whether these
functors should always be <tt>CopyConstructible</tt>, as suggested by the class
template definitions, or if the requirement tables are correct and we should
explicitly split up the constructors in the (unordered) associative containers
to no longer use default (function) arguments to obtain their defaulted functors.
</p>
<p>
I recommend the simplest solution would be to always require that the functors
for (unordered) associative containers be <tt>CopyConstructible</tt>, above the
requirements tables themselves, so that the issue need not be addressed within
the tables.  I suggest that the assignment operators for these containers add
the requirement that the functors be <tt>Swappable</tt>, rather than forwarding
the corresponding <tt>Assignable</tt> requirement.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
Alisdair to propose wording.
</p>

<p><i>[2014-06-08, Daniel comments]</i></p>

<p>
The area of this issue partially overlaps what LWG <a href="lwg-active.html#2227">2227</a> addresses.
</p>



<p><b>Proposed resolution:</b></p>
<p>
</p>





<hr>
<h3><a name="2216"></a>2216. <tt>regex_replace(basic_string)</tt> allocator handling</h3>
<p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2012-11-26 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<blockquote><pre>
template &lt;class traits, class charT, class ST, class SA&gt;
  basic_string&lt;charT, ST, SA&gt;
  regex_replace(const basic_string&lt;charT, ST, SA&gt;&amp; s,
      const basic_regex&lt;charT, traits&gt;&amp; e,
      const charT* fmt,
      regex_constants::match_flag_type flags = 
	    regex_constants::match_default);
</pre></blockquote>
<p>
and friends are documented as
</p>
<blockquote><p>
Constructs an empty string result of type <tt>basic_string&lt;charT, ST, SA&gt;</tt>
and calls <tt>regex_replace(back_inserter(result), s.begin(), s.end(), e, fmt, flags)</tt>.
</p></blockquote>
<p>
This appears to require the result to have a default-constructed
allocator, which isn't even possible for all allocator types. I
suspect the allocator should be copied from 's' instead. Possibly
there should be an additional defaulted argument to override the
allocator of the result.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2217"></a>2217. <tt>operator==(sub_match, string)</tt> slices on embedded <tt>'\0'</tt>s</h3>
<p><b>Section:</b> 28.9.2 [re.submatch.op] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2012-11-26 <b>Last modified:</b> 2014-05-02</p>
<p><b>View all other</b> <a href="lwg-index.html#re.submatch.op">issues</a> in [re.submatch.op].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>

<blockquote><pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator==(
    const basic_string&lt;
      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
    const sub_match&lt;BiIter&gt;&amp; rhs);
</pre></blockquote>
<p>
is specified as:
</p>
<blockquote><p>
<i>Returns</i>: <tt>rhs.compare(lhs.c_str()) == 0</tt>.
</p></blockquote>
<p>
This is odd because <tt>sub_match::compare(basic_string)</tt> is defined to
honor embedded <tt>'\0'</tt> characters. This could allow a <tt>sub_match</tt> to <tt>==</tt> or
<tt>!=</tt> a <tt>std::string</tt> unexpectedly.
</p>

<p><i>[Daniel:]</i></p>

<p>
This wording change was done intentionally as of LWG <a href="lwg-defects.html#1181">1181</a>, but the here mentioned slicing
effect was not considered at that time. It seems best to use another overload of compare to fix this problem:
</p>
<blockquote><p>
<i>Returns</i>: <tt>rhs.str().compare(0, rhs.length(), lhs.data(), lhs.size()) == 0</tt>.
</p></blockquote>
<p>
or
</p>
<blockquote><p>
<i>Returns</i>: <tt>rhs.compare(sub_match&lt;BiIter&gt;::string_type(lhs.data(), lhs.size())) == 0</tt>.
</p></blockquote>

<p><i>[2013-10-17: Daniel provides concrete wording]</i></p>


<p>
The original wording was suggested to reduce the need to allocate memory during comparisons. The specification would be
very much easier, if <tt>sub_match</tt> would provide an additional <tt>compare</tt> overload of the form:
</p>
<blockquote><pre>
int compare(const value_type* s, size_t n) const;
</pre></blockquote>
<p>
But given the fact that currently <em>all</em> of <tt>basic_string</tt>'s <tt>compare</tt> overloads are defined in terms
of temporary string constructions, the following proposed wording does follow the same string-construction route as 
<tt>basic_string</tt> does (where needed to fix the embedded zeros issue) and to hope that existing implementations
ignore to interpret this semantics in the literal sense.
<p/>
I decided to use the second replacement form
</p>
<blockquote><pre>
<i>Returns</i>: <tt>rhs.compare(sub_match&lt;BiIter&gt;::string_type(lhs.data(), lhs.size())) == 0</tt>.
</pre></blockquote>
<p>
because it already reflects the existing style used in 28.9.2 [re.submatch.op] p31.
</p>


<p><i>[2014-02-15 post-Issaquah session : move to Tentatively Ready]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Change 28.9.2 [re.submatch.op] as indicated:</p>

<blockquote><pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator==(
    const basic_string&lt;
      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
    const sub_match&lt;BiIter&gt;&amp; rhs);
</pre><blockquote>
<p>
-7- <i>Returns:</i> <tt>rhs.compare(<del>lhs.c_str()</del><ins>typename sub_match&lt;BiIter&gt;::string_type(lhs.data(), lhs.size())</ins>) == 0</tt>.
</p>
</blockquote></blockquote>
<p>
[&hellip;]
</p>
<blockquote><pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator&lt;(
    const basic_string&lt;
      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
    const sub_match&lt;BiIter&gt;&amp; rhs);
</pre><blockquote>
<p>
-9- <i>Returns:</i> <tt>rhs.compare(<del>lhs.c_str()</del><ins>typename sub_match&lt;BiIter&gt;::string_type(lhs.data(), lhs.size())</ins>) &gt; 0</tt>.
</p>
</blockquote></blockquote>
<p>
[&hellip;]
</p>
<blockquote><pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator==(const sub_match&lt;BiIter&gt;&amp; lhs,
                  const basic_string&lt;
                    typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA>&amp; rhs);
</pre><blockquote>
<p>
-13- <i>Returns:</i> <tt>lhs.compare(<del>rhs.c_str()</del><ins>typename sub_match&lt;BiIter&gt;::string_type(rhs.data(), rhs.size())</ins>) == 0</tt>.
</p>
</blockquote></blockquote>
<p>
[&hellip;]
</p>
<blockquote><pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator&lt;(const sub_match&lt;BiIter&gt;&amp; lhs,
                 const basic_string&lt;
                   typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA>&amp; rhs);
</pre><blockquote>
<p>
-15- <i>Returns:</i> <tt>lhs.compare(<del>rhs.c_str()</del><ins>typename sub_match&lt;BiIter&gt;::string_type(rhs.data(), rhs.size())</ins>) &lt; 0</tt>.
</p>
</blockquote></blockquote>

<blockquote><pre>
</pre><blockquote>
<p>
</p>
</blockquote></blockquote>

<blockquote><pre>
</pre><blockquote>
<p>
</p>
</blockquote></blockquote>

<blockquote><pre>
</pre><blockquote>
<p>
</p>
</blockquote></blockquote>

<blockquote><pre>
</pre><blockquote>
<p>
</p>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2218"></a>2218. Unclear how containers use <tt>allocator_traits::construct()</tt></h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-11-27 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Firstly, 23.2.1 [container.requirements.general]/7 says a container's
allocator is used to obtain memory, but it isn't stated explicitly that the same 
allocator is used to construct and destroy elements, as opposed to a value-initialized 
allocator of the same type.
</p>
<p>
Secondly, 23.2.1 [container.requirements.general]/3 says elements "shall be
constructed using the <tt>allocator_traits&lt;allocator_type&gt;::construct</tt>
function and destroyed using the <tt>allocator_traits&lt;allocator_type&gt;::destroy</tt> function" and
23.2.1 [container.requirements.general]/13 defines <tt>CopyInsertable</tt> etc. in
terms of an allocator <tt>A</tt> which is identical to the container's <tt>allocator_type</tt>.
</p>
<p>
The intent of making <tt>construct()</tt> and <tt>destroy()</tt> function templates was
that containers would be permitted to use <tt>allocator_traits&lt;A&gt;::construct()</tt> instead of
<tt>allocator_traits&lt;allocator_type&gt;::construct()</tt>, where <tt>A</tt> is
<tt>allocator_traits&lt;allocator_type&gt;::rebind_alloc&lt;U&gt;</tt> for some other type
<tt>U</tt>.  This allows node-based containers to store an allocator of the right type for 
allocating nodes and to use the same object to construct elements in aligned storage within 
those nodes, avoiding rebinding and copying the stored allocator every time an element needs
to be constructed.
<p/>
It should be made clear that a possibly-rebound copy of the container's allocator is used for object 
construction.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
Jonathan: point 2 in the proposed resolution is definitely needed.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3485.</p>

<ol>
<li><p>Edit 23.2.1 [container.requirements.general] paragraph 3:</p>
<blockquote><p>
For the components affected by this subclause that declare an <tt>allocator_type</tt>, objects stored in these
components shall be constructed using the <tt>allocator_traits&lt;allocator_type&gt;::<ins>rebind_alloc&lt;U&gt;::</ins>construct</tt> 
function and destroyed using the <tt>allocator_traits&lt;allocator_type&gt;::<ins>rebind_alloc&lt;U&gt;::</ins>destroy</tt> 
function (20.7.8.2 [allocator.traits.members])<ins>, where <tt>U</tt> is either <tt>allocator_type::value_type</tt> 
or an internal type used by the container</ins>. These functions are called only for the container's element type, 
not for internal types used by the container. [ <i>Note</i>: This means, for example, that a node-based container 
might need to construct nodes containing aligned buffers and call construct to place the element into the buffer. 
&mdash; <i>end note</i> ]
</p></blockquote>
</li>

<li><p>Edit 23.2.1 [container.requirements.general] paragraph 7:</p>
<blockquote><p>
[&hellip;] A copy of this allocator is used for any memory allocation <ins>and element construction</ins> performed, 
by these constructors and by all member functions, during the lifetime of each container object or until the allocator 
is replaced. [&hellip;]
</p></blockquote>
</li>

<li><p>Edit 23.2.1 [container.requirements.general] paragraph 13:</p>
<blockquote><p>
[&hellip;] Given <ins>an allocator type <tt>A</tt> and given</ins> a container type <tt>X</tt> having <del>an 
<tt>allocator_type</tt> identical to <tt>A</tt> and</del> a <tt>value_type</tt> identical to <tt>T</tt> 
<ins>and an <tt>allocator_type</tt> identical to <tt>allocator_traits&lt;A&gt;::rebind_alloc&lt;T&gt;</tt></ins> 
and given an lvalue <tt>m</tt> of type <tt>A</tt>, a pointer <tt>p</tt> 
of type <tt>T*</tt>, an expression <tt>v</tt> of type (possibly <tt>const</tt>) <tt>T</tt>, and an rvalue <tt>rv</tt> 
of type <tt>T</tt>, the following terms are defined.
<p/>
[&hellip;]
<p/>
[ <i>Note</i>: A container calls <tt>allocator_traits&lt;A&gt;::construct(m, p, args)</tt> to construct an element 
at <tt>p</tt> using <tt>args</tt><ins>, with <tt>m == get_allocator()</tt></ins>. The default <tt>construct</tt> in 
<tt>std::allocator</tt> will call <tt>::new((void*)p) T(args)</tt>, but specialized allocators may choose a 
different definition. &mdash; <i>end note</i> ]
</p></blockquote>
</li>

</ol>






<hr>
<h3><a name="2219"></a>2219. <tt><i>INVOKE</i></tt>-ing a pointer to member with a <tt>reference_wrapper</tt> as the object expression</h3>
<p><b>Section:</b> 20.9.2 [func.require] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-11-28 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.require">active issues</a> in [func.require].</p>
<p><b>View all other</b> <a href="lwg-index.html#func.require">issues</a> in [func.require].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The standard currently requires this to be invalid:
</p>
<blockquote><pre>
#include &lt;functional&gt;

struct X { int i; } x;
auto f = &amp;X::i;
auto t1 = std::ref(x);
int i = std::mem_fn(f)(t1);
</pre></blockquote>
<p>
The call expression on the last line is equivalent to <tt><i>INVOKE</i>(f, std::ref(x))</tt> 
which according to 20.9.2 [func.require]p1 results in the invalid expression <tt>(*t1).*f</tt> 
because <tt>reference_wrapper&lt;X&gt;</tt> is neither an object of type <tt>X</tt> nor a reference 
to an object of type <tt>X</tt> nor a reference to an object of a type derived from <tt>X</tt>.
</p>
<p>
The same argument applies to pointers to member functions, and if they don't work with <tt>INVOKE</tt> 
it becomes harder to do all sorts of things such as:
</p>
<blockquote><p>
<tt>call_once(o, &amp;std::thread::join, std::ref(thr))</tt>
</p></blockquote>
<p>
or
</p>
<blockquote><p>
<tt>async(&amp;std::list&lt;int&gt;::sort, std::ref(list));</tt>
</p></blockquote>
<p>
The definition of <tt><i>INVOKE</i></tt> should be extended to handle reference wrappers.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Review.
</p>
<p>
The wording seems accurate, but verbose.  If possible, we would like to define the kind of thing being
specified so carefully as one of a number of potential language constructs in a single place.  It is
also possible that this clause <i>is</i> that single place.
</p>

<p><i>[2013-04-18, Bristol]</i></p>


<p>Jonathan comments:</p>

<p>In the proposed resolution in the first bullet <tt>(t1.*f)</tt> is not valid if <tt>t1</tt> is a
<tt>reference_wrapper</tt>, so we probably need a separate bullet to handle the
<tt>reference_wrapper</tt> case.</p>

<p><i>[2014-02-14, Issaquah, Mike Spertus supplies wording]</i></p>


<p><strong>Previous resolution from Jonathan [SUPERSEDED]:</strong></p>

<blockquote class="note">

<p>This wording is relative to N3485.</p>

<ol>
<li><p>Edit 20.9.2 [func.require]:</p>
<blockquote><p>
Define <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> as follows:
</p>
<ul>
<li><p>
<tt>(t1.*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and 
<tt>t1</tt> is an object of type <tt>T</tt> or a reference to an object of type <del><tt>T</tt> or a reference 
to an object of a type derived from <tt>T</tt></del> <ins><tt>U</tt> or an object of type <tt>reference_wrapper&lt;U&gt;</tt> 
or a reference to an object of type <tt>reference_wrapper&lt;U&gt;</tt> where <tt>U</tt> is either the type 
<tt>T</tt> or a type derived from <tt>T</tt></ins>;
</p>
</li>

<li><p>
<tt>((*t1).*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and 
<tt>t1</tt> is not one of the types described in the previous item;
</p></li>

<li><p> 
<tt>t1.*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and <tt>t1</tt> 
is an object of type <tt>T</tt> or a reference to an object of type <del><tt>T</tt> or a reference to an object of a 
type derived from <tt>T</tt></del> <ins><tt>U</tt> or an object of type <tt>reference_wrapper&lt;U&gt;</tt> 
or a reference to an object of type <tt>reference_wrapper&lt;U&gt;</tt> where <tt>U</tt> is either the type 
<tt>T</tt> or a type derived from <tt>T</tt></ins>;
</p></li>

<li><p>
<tt>(*t1).*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and <tt>t1</tt> 
is not one of the types described in the previous item;
</p></li>

<li><p>
<tt>f(t1, t2, ..., tN)</tt> in all other cases.
</p></li>
</ul>

</blockquote>

</li>
</ol>

</blockquote>
 


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Edit 20.9.2 [func.require]:</p>
<blockquote><p>
Define <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> as follows:
</p>
<ul>
<li><p>
<tt>(t1.*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and 
<tt>t1</tt> is an object of type <tt>T</tt> or a reference to an object of type <tt>T</tt> or a reference 
to an object of a type derived from <tt>T</tt>;
</p>
</li>

<li><p>
<ins>
<tt>(t1.get().*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function
of class <tt>T</tt>
and <tt>t1</tt> is an object of type <tt>reference_wrapper&lt;U&gt;</tt> where <tt>U</tt>
is either the type <tt>T</tt> or a type derived from <tt>T</tt>.
</ins>
</p>
</li>

<li><p>
<tt>((*t1).*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and 
<tt>t1</tt> is not one of the types described in the previous item;
</p></li>



<li><p> 
<tt>t1.*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and <tt>t1</tt> 
is an object of type <tt>T</tt> or a reference to an object of type <tt>T</tt> or a reference to an object of a 
type derived from <tt>T</tt>;
</p></li>

<li><p>
<ins>
<tt>t1.get().*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a
class <tt>T</tt> and <tt>t1</tt> is an object of type <tt>reference_wrapper&lt;U&gt;</tt>
where <tt>U</tt> is either the type <tt>T</tt> or a type derived from <tt>T</tt>.
</ins>
</p></li>

<li><p>
<tt>(*t1).*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and <tt>t1</tt> 
is not one of the types described in the previous item;
</p></li>

<li><p>
<tt>f(t1, t2, ..., tN)</tt> in all other cases.
</p></li>
</ul>

</blockquote>

</li>
</ol>






<hr>
<h3><a name="2220"></a>2220. Under-specification of <tt>operator==</tt> for <tt>regex_token_iterator</tt></h3>
<p><b>Section:</b> 28.12.2.2 [re.tokiter.comp] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-11-21 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Consider the following example:
</p>
<blockquote><pre>
std::string str0("x");
std::regex rg0("a");
std::regex_token_iterator it0(str0.begin(), str0.end(), rg0, -1); // points at "x" in str0
std::string str1("x");
std::regex rg1("b");
std::regex_token_iterator it1(str1.begin(), str1.end(), rg1, -1); // points at "x" in str1
</pre></blockquote>
<p>
28.12.2.2 [re.tokiter.comp] p1 says that <tt>it0.operator==(it1)</tt> returns true "if 
<tt>*this</tt> and <tt>right</tt> are both suffix iterators and <tt>suffix == right.suffix</tt>"; both 
conditions are satisfied in this example. It does not say that they must both be iterators 
into the same sequence, nor does it say (as general iterator requirements do) that they must 
both be in the domain of <tt>==</tt> in order for the comparison to be meaningful. It's a 
simple statement: they're equal if the strings they point at compare equal. Given this being
a valid comparison, the obtained result of "true" looks odd.
<p/>
The problem is that for iterator values prior to the suffix iterator, equality means the same 
regular expression and the same matched sequence (both uses of "same" refer to identity, not equality); 
for the suffix iterator, equality means that the matched sequences compare equal.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2221"></a>2221. No formatted output operator for <tt>nullptr</tt></h3>
<p><b>Section:</b> 27.7.3 [output.streams] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2012-12-07 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
When I write 
</p>
<blockquote><pre>
std::cout &lt;&lt; nullptr &lt;&lt; std::endl;
</pre></blockquote>
<p>
I get a compilation error, "ambiguous overload for '<tt>operator&lt;&lt;</tt>' in '<tt>std::cout &lt;&lt; nullptr</tt>'". 
As far as I can tell, the compiler is right to issue that error. There are inserters for <tt>const void*</tt>, 
<tt>const char*</tt>, <tt>const signed char*</tt>, and <tt>const unsigned char*</tt>, and none for 
<tt>nullptr_t</tt>, so the expression really is ambiguous.
<p/>
<em>Proposed wording</em>:
<p/>
The obvious library solution is to add a <tt>nullptr_t</tt> overload, which would be defined something like
</p>
<blockquote><pre>
template&lt;class C, class T&gt;
basic_ostream&lt;C, T&gt;&amp; operator&lt;&lt;(basic_ostream&lt;C, T&gt;&amp; os, nullptr_t) 
{ 
  return os &lt;&lt; (void*) nullptr; 
}
</pre></blockquote>
<p>
We might also consider addressing this at a core level: add a special-case language rule that addresses all 
cases where you write <tt>f(nullptr)</tt> and <tt>f</tt> is overloaded on multiple pointer types. (Perhaps 
a tiebreaker saying that <tt>void*</tt> is preferred in such cases.)
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2223"></a>2223. <tt>shrink_to_fit</tt> effect on iterator validity</h3>
<p><b>Section:</b> 23.3.6.3 [vector.capacity] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Juan Soulie <b>Opened:</b> 2012-12-17 <b>Last modified:</b> 2014-05-02</p>
<p><b>View other</b> <a href="lwg-index-open.html#vector.capacity">active issues</a> in [vector.capacity].</p>
<p><b>View all other</b> <a href="lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
After the additions by <a href="lwg-defects.html#2033">2033</a>, it appears clear that the intended effect includes a reallocation and 
thus the potential effect on iterators should be explicitly added to the text in order to not contradict 
23.2.1 [container.requirements.general]/11, or at the very least, explicitly state that a reallocation may 
happen.
<p/>
Taking consistency with "reserve" into consideration, I propose:
</p>
<ul>
<li><p>
that the current "Remarks" are made its "Effect" instead, inserting "Reallocation happens at this point if and only 
if the function effectively reduces the capacity." after the note on non-bindingness.
</p>
</li>
<li><p>
adding a "Remarks" paragraph, similar to that of reserve: "Reallocation invalidates all the references, pointers, 
and iterators referring to the elements in the sequence."
</p></li>
</ul>
<p>
BTW, while we are at it, I believe the effect on iterators should also be explicitly stated in the other instance 
a reallocation may happen: 23.3.6.5 [vector.modifiers]/1 &mdash; even if obvious, it only contradicts 
23.2.1 [container.requirements.general]/11 implicitly. 
<p/>
I propose to also insert "Reallocation invalidates all the references, pointers, and iterators referring to the 
elements in the sequence." at the appropriate location in its "Remarks".
</p>

<p><i>[2012-12-19: Jonathan Wakely comments]</i></p>


<p>
The described problem also affects <tt>std::basic_string</tt> and <tt>std::deque</tt>.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Review.
</p>

<p><i>[2013-04-18, Bristol]</i></p>
 

<p>Daniel extends the P/R.</p>

<p>Rationale:</p>

<p>The wording in 21.4.4 [string.capacity] combined with 21.4.1 [string.require]
seems to say the necessary things. We cannot impose all requirements as we do for <tt>vector</tt>, because
we want to allow the short-string-optimization.</p>


<p><i>[2014-02-15 post-Issaquah session]</i></p>

<p>
STL: I think that <tt>shrink_to_fit</tt> should be a no-op when called twice.
</p>
<p>
STL: Do we ever define reallocation for <tt>deque</tt>? Nope, all mentions of "reallocation" are in <tt>vector</tt>.
     We define what it means in <tt>vector::reserve()</tt>, but not for <tt>deque</tt>.
</p>
<p>
STL: Oh duh, they define reallocate in the PR. But I think we can do better here.
</p>
<p>
STL: Optimally, deque shrinking just allocates a new map of pointers, and drops empty blocks, but preserves pointers/references to elements.
</p>
<p>
Alisdair: That's like unordered containers, invalidating only iterators.
</p>
<p>
Pablo: It doesn't make sense to reduce <tt>capacity()</tt> to <tt>size()</tt>, because <tt>deque</tt> doesn't have capacity!
</p>
<p>
STL: For <tt>vector</tt>, "effectively reduces the capacity" is unnecessary, the capacity there is observable.
</p>
<p>
STL: There is a strong reason to provide an optimal shrink to fit for <tt>deque</tt>, since only the library implementer can do this.
</p>
<p>
STL: The other thing I don't like the repeated definition of reallocation for <tt>vector</tt>, we define it once and use it in a bunch of places.
     At most we can lift it up to the <tt>vector</tt> synopsis.
</p>
<p>
STL: I'll write new wording.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3485.</p>

<ol>
<li><p>Keep 21.4.4 [string.capacity] around p14 <em>unchanged</em>, because we don't speak about
reallocations and we give the strong exception guarantee in 21.4.1 [string.require] (Invalidation
specification also at that place):</p>
<blockquote><pre>
void shrink_to_fit();
</pre>
<p>
-14- <i>Remarks</i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to 
<tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific 
optimizations. &mdash; <i>end note</i> ].
</p>
</blockquote>
</li>

<li><p>Edit 23.3.3.3 [deque.capacity] around p7 as indicated:</p>
<blockquote><pre>
void shrink_to_fit();
</pre>
<p>
-5- <i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.
<p/>
<ins>-?- <i>Effects</i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to 
<tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific 
optimizations. &mdash; <i>end note</i> ] Reallocation happens at this point if and only 
if the function effectively reduces the capacity. If an exception is thrown other than by the move constructor 
of a non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.</ins> 
<p/>
-6- <i>Complexity</i>: Linear in the size of the sequence.
<p/>
-7- <i>Remarks</i>: <del><tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to 
<tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific 
optimizations. &mdash; <i>end note</i> ] If an exception is thrown other than by the move constructor 
of a non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.</del><ins>Reallocation invalidates all 
the references, pointers, and iterators referring to the elements in the sequence.</ins>
</p>
</blockquote>
</li>

<li><p>Edit 23.3.6.3 [vector.capacity] around p7 as indicated:</p>
<blockquote><pre>
void shrink_to_fit();
</pre>
<p>
-7- <i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.
<p/>
<ins>-?- <i>Effects</i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to 
<tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific 
optimizations. &mdash; <i>end note</i> ] Reallocation happens at this point if and only 
if the function effectively reduces the capacity. If an exception is thrown other than by the move constructor 
of a non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.</ins> 
<p/>
-8- <i>Complexity</i>: Linear in the size of the sequence.
<p/>
-9- <i>Remarks</i>: <del><tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to 
<tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific 
optimizations. &mdash; <i>end note</i> ] If an exception is thrown other than by the move constructor 
of a non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.</del><ins>Reallocation invalidates all 
the references, pointers, and iterators referring to the elements in the sequence.</ins>
</p>
</blockquote>
</li>

<li><p>Edit 23.3.6.5 [vector.modifiers] p1 as indicated:</p>
<blockquote><pre>
iterator insert(const_iterator position, const T&amp; x);
iterator insert(const_iterator position, T&amp;&amp; x);
iterator insert(const_iterator position, size_type n, const T&amp; x);
template &lt;class InputIterator&gt;
iterator insert(const_iterator position, InputIterator first, InputIterator last);
iterator insert(const_iterator position, initializer_list&lt;T&gt;);
template &lt;class... Args&gt; void emplace_back(Args&amp;&amp;... args);
template &lt;class... Args&gt; iterator emplace(const_iterator position, Args&amp;&amp;... args);
void push_back(const T&amp; x);
void push_back(T&amp;&amp; x);
</pre>
<p>
-1- <i>Remarks</i>: Causes reallocation if the new size is greater than the old capacity. <ins>Reallocation 
invalidates all the references, pointers, and iterators referring to the elements in the sequence.</ins> If 
no reallocation happens, all the iterators and references before the insertion point remain valid. If an 
exception is thrown other than by the copy constructor, move constructor, assignment operator, or move 
assignment operator of <tt>T</tt> or by any <tt>InputIterator</tt> operation there are no effects. If an 
exception is thrown by the move constructor of a non-<tt>CopyInsertable</tt> <tt>T</tt>, the effects are unspecified.
</p>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2224"></a>2224. Ambiguous status of access to non-live objects</h3>
<p><b>Section:</b> 17.6.4.10 [res.on.objects] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Geoffrey Romer <b>Opened:</b> 2012-12-17 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#res.on.objects">issues</a> in [res.on.objects].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The standard currently does not discuss when library objects may be accessed, except in a non-normative 
note pertaining to synchronization in [res.on.objects], leaving it ambiguous whether single-threaded 
code can access a library object during its construction or destruction. For example, there is a 
reasonable question as to what happens if the deleter supplied to a <tt>unique_ptr</tt> transitively 
accesses the <tt>unique_ptr</tt> itself during <tt>unique_ptr</tt>'s destruction; a straightforward 
reading suggests that this is permitted, and that the deleter will see the <tt>unique_ptr</tt> still 
holding the originally stored pointer, but consensus on the LWG reflector indicates this was not the 
intent (see discussion beginning with 
<a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=33362">c++std-lib-33362</a>).
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
Geoffrey will provide an example that clearly highlights the issue.
</p>

<p><i>[2013-03-19 Geoffrey provides revised resolution and an example]</i></p>


<p>
I contend that the most straightforward reading of the current standard requires the following example code to print 
"good" (because <tt>~unique_ptr</tt> is not specified to modify the state of the internal pointer), but the consensus 
on the reflector was that its behavior should be undefined.
<p/>
This example also shows that, contrary to a comment in the telecon, the PR is not tautological. 12.7 [class.cdtor]/p4 
explicitly permits member function calls during destruction, so the behavior of this code is well-defined as far as 
the core language is concerned, despite the fact that it accesses a library object after the end of the object's 
lifetime. If we want this code to have undefined behavior, we need to specify that at the library level.
</p>

<blockquote><pre>
#include &lt;memory&gt;
#include &lt;iostream&gt;

class A;

struct B {
 std::unique_ptr&lt;A&gt; a;
};

struct A {
 B* b;
 ~A() {
   if (b-&gt;a.get() == this) {
     std::cout &lt;&lt; "good" &lt;&lt; std::endl;
   }
 }
};

int main() {
 B b;
 b.a.reset(new A);
 b.a-&gt;b = &amp;b;
}
</pre></blockquote>

<p>
Previous resolution:
</p>
<blockquote class="note">
<ol>
<li><p>Change the title of sub-clause 17.6.4.10 [res.on.objects] as indicated:</p>
<p><del>Shared objects and the library</del><ins>Library object access</ins> [res.on.objects]</p>
</li>

<li><p>Edit 17.6.4.10 [res.on.objects] p2 as indicated:</p>
<p>-2- <del>[<i>Note</i>: In particular, the program is required to ensure that completion of the constructor 
of any object of a class type defined in the standard library happens before any other member function 
invocation on that object and, unless otherwise specified, to ensure that completion of any member function 
invocation other than destruction on such an object happens before destruction of that object. This applies 
even to objects such as mutexes intended for thread synchronization. &mdash; <i>end note</i>]</del>
<ins>If an object of a standard library type is accessed outside of the object's lifetime (3.8 [basic.life]), 
the behavior is undefined unless otherwise specified.</ins></p>
</li>
</ol>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3485.</p>

<ol>
<li><p>Change the title of sub-clause 17.6.4.10 [res.on.objects] as indicated:</p>
<p><del>Shared objects and the library</del><ins>Library object access</ins> [res.on.objects]</p>
</li>

<li><p>Edit 17.6.4.10 [res.on.objects] p2 as indicated: <em>[<i>Editorial remark:</i> The motivation, is to 
be more precise about the meaning of "outside the object's lifetime" in the presence of threads &mdash; <i>end editorial 
remark</i>]</em></p>
<p>-2- <del>[<i>Note</i>: In particular, the program is required to ensure that completion of the constructor 
of any object of a class type defined in the standard library happens before any other member function 
invocation on that object and, unless otherwise specified, to ensure that completion of any member function 
invocation other than destruction on such an object happens before destruction of that object. This applies 
even to objects such as mutexes intended for thread synchronization. &mdash; <i>end note</i>]</del>
<ins>If an object of a standard library type is accessed, and the beginning of the object's lifetime 
(3.8 [basic.life]) does not happen before the access, or the access does not happen before the end 
of the object's lifetime, the behavior is undefined unless otherwise specified.</ins></p>
</li>
</ol>






<hr>
<h3><a name="2227"></a>2227. Stateful comparison objects in associative containers</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Juan Soulie <b>Opened:</b> 2012-12-19 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Table 102 in 23.2.4 [associative.reqmts]/8 states on expression <tt>a.key_comp()</tt> that it 
"returns the comparison object out of which a was constructed". At the same time, 
23.2.1 [container.requirements.general]/8 states (starting in the third line) that 
"...Any <tt>Compare</tt>, <tt>Pred</tt>, or <tt>Hash</tt> objects belonging to <tt>a</tt> and <tt>b</tt> 
shall be swappable and <em>shall be exchanged</em> by unqualified calls to non-member swap...". This is 
problematic for any compliant implementation, since once swapped the container cannot return the comparison 
object out of which it was constructed unless incurring in storing an otherwise needless object.
<p/>
The simple solution is to correct that statement in Table 102, but I believe this is part of a larger problem 
of underspecified behavior: The new standard has made an effort in regards to allocators and now fully 
specifies what happens to stateful allocator objects. It has even specified what happens to stateful <tt>hasher</tt> 
and <tt>key_equal</tt> members of unordered containers (they propagate), but it says nothing about stateful 
comparison objects of (ordered) associative containers, except for the statement in 
23.2.1 [container.requirements.general]/8 referred above and only related to <tt>swap</tt>.
<p/>
For example, it is unclear to me what is specified to happen on an assignment: should the comparison object 
be copied/moved along with the elements, or should the left-hand side object keep its own?
Maybe this has been intentionally left unspecified with the purpose of compatibility with C++98, which I 
understand it specified that comparison objects were kept for the entire life of the container (like allocators) 
&mdash; an unfortunate choice. But anyway, the segment of 23.2.1 [container.requirements.general] quoted 
above seems to break any possible backwards compatibility with C++98 in this regard.
<p/>
Therefore, taking into consideration consistency with how this is dealed with for unordered associative 
containers, I propose that Table 102 is modified as follows:
</p>
<ul>
<li>
<p>
The row for expression <tt>a.key_comp()</tt> is changed so that its "assertion/note pre-/post-condition" reads 
"Returns <tt>a</tt>'s comparison object."
</p>
</li>

<li>
<p>
A new row is added at the appropriate location (which I believe would be after "X(il)" row), with:
</p>

<blockquote>
<table border="1">
<caption>Table 102 &mdash; Associative container requirements (in addition to container)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td>
<tt>X(b)<br/>
X a(b)</tt>
</td>
<td>
<tt>X</tt>
</td>
<td>
Copy constructor. In addition to<br/>
the requirements of Table 96, copies<br/>
the comparison object.
</td>
<td>
Linear in <tt>b.size()</tt>
</td>
</tr>

<tr>
<td>
<tt>a = b</tt>
</td>
<td>
<tt>X&amp;</tt>
</td>
<td>
Copy assignment operator. In addition to<br/>
the requirements of Table 96, copies the<br/>
comparison object.
</td>
<td>
Linear in <tt>a.size()</tt> and <tt>b.size()</tt>
</td>
</tr>

</table>
</blockquote>

</li>
</ul>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Review.
</p>

<p><i>[2013-04-18, Bristol]</i></p>
 
<p>
STL: can't believe we don't specify this already. this is totally necessary
<p/>
Alisdair: how does it do this? copy construction? assignment?
<p/>
ALso need it for move.
<p/>
STL: we already specify this for constructing from a comparator, not during copy construction though.
<p/>
Jonathan: don't like wording, should say "<tt>key_compare</tt> is <tt>CopyConstructible</tt>. Uses <tt>b.key_comp()</tt> 
as a comparison object."
<p/>
STL: we get it right for unordered!
<p/>
Jonathan: can't wordsmith this now, but I think implementations do the right thing.
<p/>
Alisdair: not sure what right thing is for moves. also we say nothing about propagating allocators to functors.
</p>
<p>
Moved to Open.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3485.</p>

<ol>
<li><p>Change Table 102 as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 102 &mdash; Associative container requirements (in addition to container)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>X(il)</tt>
</td>
<td>
<tt></tt>
</td>
<td>
Same as <tt>X(il.begin(), il.end())</tt>.
</td>
<td>
same as <tt>X(il.begin(), il.end())</tt>.
</td>
</tr>

<tr>
<td>
<ins><tt>X(b)<br/>
X a(b)</tt></ins>
</td>
<td>
<tt></tt>
</td>
<td>
<ins>Copy constructor. In addition to<br/>
the requirements of Table 96, copies<br/>
the comparison object.</ins>
</td>
<td>
<ins>Linear in <tt>b.size()</tt></ins>
</td>
</tr>

<tr>
<td>
<ins><tt>a = b</tt></ins>
</td>
<td>
<ins><tt>X&amp;</tt></ins>
</td>
<td>
<ins>Copy assignment operator. In addition to<br/>
the requirements of Table 96, copies the<br/>
comparison object.</ins>
</td>
<td>
<ins>Linear in <tt>a.size()</tt> and <tt>b.size()</tt></ins>
</td>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>a.key_comp()</tt>
</td>
<td>
<tt>X::key_compare</tt>
</td>
<td>
<del>r</del><ins>R</ins>eturns <del>the</del><ins><tt>a</tt>'s</ins> comparison object<br/>
<del>out of which a was constructed.</del>
</td>
<td>
constant
</td>
</tr>


</table>
</blockquote>

</li>

</ol>






<hr>
<h3><a name="2228"></a>2228. Missing <em>SFINAE</em> rule in <tt>unique_ptr</tt> templated assignment</h3>
<p><b>Section:</b> 20.8.1.2.3 [unique.ptr.single.asgn] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Geoffrey Romer <b>Opened:</b> 2012-12-20 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#unique.ptr.single.asgn">issues</a> in [unique.ptr.single.asgn].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>

<p>
20.8.1.2.3 [unique.ptr.single.asgn]/5 permits <tt>unique_ptr</tt>'s templated assignment operator to participate 
in overload resolution even when incompatibilities between <tt>D</tt> and <tt>E</tt> will render the result ill-formed, 
but the corresponding templated copy constructor is removed from the overload set in those situations (see the third 
bullet point of 20.8.1.2.1 [unique.ptr.single.ctor]/19). This asymmetry is confusing, and presumably unintended; 
it may lead to situations where constructing one <tt>unique_ptr</tt> from another is well-formed, but assigning from 
the same <tt>unique_ptr</tt> would be ill-formed.
<p/>
There is a slight coupling between this and LWG <a href="lwg-active.html#2118">2118</a>, in that my PR for LWG <a href="lwg-active.html#2118">2118</a> incorporates 
equivalent wording in the specification of the templated assignment operator for the array specialization; the two PRs 
are logically independent, but if my PR for <a href="lwg-active.html#2118">2118</a> is accepted but the above PR is not, the discrepancy 
between the base template and the specialization could be confusing.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Review.
</p>
<p>
The wording looks good, but we want a little more time than the telecon permits to be truly comfortable.
We expect this issue to resolve fairly easily in Bristol.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3485.</p>
<ol>
<li><p>Revise 20.8.1.2.3 [unique.ptr.single.asgn] p5 as follows:</p>

<blockquote><pre>
template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u) noexcept;
</pre><blockquote>
<p>
-4- <i>Requires</i>: If <tt>E</tt> is not a reference type, assignment of the deleter from an rvalue of type <tt>E</tt> 
shall be well-formed and shall not throw an exception. Otherwise, <tt>E</tt> is a reference type and assignment of the
deleter from an lvalue of type <tt>E</tt> shall be well-formed and shall not throw an exception.
<p/>
-5- <i>Remarks</i>: This operator shall not participate in overload resolution unless:
</p>
<ul>
<li><p><tt>unique_ptr&lt;U, E&gt;::pointer</tt> is implicitly convertible to <tt>pointer</tt> and</p></li>
<li><p><tt>U</tt> is not an array type<del>.</del><ins>, and</ins></p></li>
<li><p><ins>either <tt>D</tt> is a reference type and <tt>E</tt> is the same type as <tt>D</tt>, or <tt>D</tt> is 
not a reference type and <tt>E</tt> is implicitly convertible to <tt>D</tt>.</ins></p></li>
</ul>
<p>
-6- <i>Effects</i>: Transfers ownership from <tt>u</tt> to <tt>*this</tt> as if by calling <tt>reset(u.release())</tt> 
followed by an assignment from <tt>std::forward&lt;E&gt;(u.get_deleter())</tt>.
<p/>
-7- <i>Returns</i>: <tt>*this</tt>.
</p>
</blockquote></blockquote>

</li>
</ol>





<hr>
<h3><a name="2230"></a>2230. &quot;<em>see below</em>&quot; for initializer-list constructors of unordered containers</h3>
<p><b>Section:</b> 23.5 [unord] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-01-06 <b>Last modified:</b> 2014-05-23</p>
<p><b>View all other</b> <a href="lwg-index.html#unord">issues</a> in [unord].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>unordered_map</tt> class definition in 23.5.4.1 [unord.map.overview] declares an
initializer-list constructor that says "see below":
</p>

<blockquote><pre>
unordered_map(initializer_list&lt;value_type&gt;,
    size_type = <em>see below</em>,
    const hasher&amp; hf = hasher(),
    const key_equal&amp; eql = key_equal(),
    const allocator_type&amp; a = allocator_type());
</pre></blockquote>

<p>
But that constructor isn't defined below. The same problem exists for the other unordered associative containers.
</p>

<p><i>[2013-09 Chicago]</i></p>

<p>
STL: ordered are also missing declarations, but issue is forthcoming
<p/>
Walter: how does adding a signature address issue? &mdash; nevermind 
<p/>
Jayson: in his wording, isn't he just dropping the <tt>size_type</tt>?
<p/> 
Walter: partial fix is to introduce the name
<p/>
Stefanus: explanation of requiring name because of n buckets 
<p/>
STL: solution for his issue satisfies both ordered and unordered and is simplier than provided wording 
<p/>
STL: patches general table instead 
<p/>
STL: proposes adding extra rows instead of extra declarations 
<p/>
Stefanus: clarify <tt>n</tt> in the synopsis 
<p/>
Walter: general rule, name is optional in declaration 
<p/>
Stefanus: how to proceed 
<p/>
Walter: significant overlap with forthcoming issue, suggestion to defer
</p>

<p><i>[2014-02-20 Re-open Deferred issues as Priority 4]</i></p>


<p><i>[2014-03-27 Jonathan improves proposed wording]</i></p>


<p><i>[2014-05-20 STL and Jonathan communicate]</i></p>


<p>
STL: With <a href="lwg-defects.html#2322">2322</a> resolved, is there anything left for this issue to fix?
<p/>
Jonathan: The synopsis still says "<em>see below</em>" and it's not immediately clear
that "<em>see below</em>" means "see the definition of a different constructor,
which defines the behaviour of this one due to a table defined much earlier".
</p>

<p><i>[2014-05-23 Library reflector vote]</i></p>

<p>
The issue has been identified as Tentatively Ready based on five votes in favour.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Edit 23.5.4.1 [unord.map.overview], class template <tt>unordered_map</tt> synopsis, as follows:</p>

<blockquote><pre>
[&hellip;]
unordered_map(initializer_list&lt;value_type&gt; <ins>il</ins>,
  size_type <ins>n</ins> = <em>see below</em>,
  const hasher&amp; hf = hasher(),
  const key_equal&amp; eql = key_equal(),
  const allocator_type&amp; a = allocator_type());
[&hellip;]
</pre></blockquote>
</li>

<li><p>Edit 23.5.4.2 [unord.map.cnstr] as follows:</p>
<blockquote><pre>
template &lt;class InputIterator&gt;
unordered_map(InputIterator f, InputIterator l,
  size_type n = <em>see below</em>,
  const hasher&amp; hf = hasher(),
  const key_equal&amp; eql = key_equal(),
  const allocator_type&amp; a = allocator_type());
<ins>unordered_map(initializer_list&lt;value_type&gt; il,
  size_type n = <em>see below</em>,
  const hasher&amp; hf = hasher(),
  const key_equal&amp; eql = key_equal(),
  const allocator_type&amp; a = allocator_type());</ins>
</pre><blockquote>
<p>
-3- <i>Effects</i>: Constructs an empty <tt>unordered_map</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is
implementation-defined. Then inserts elements from the range <tt>[f, l)</tt> <ins>for the first form, or from the range 
<tt>[il.begin(), il.end())</tt> for the second form</ins>. <tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Edit 23.5.5.1 [unord.multimap.overview], class template <tt>unordered_multimap</tt> synopsis, as follows:</p>

<blockquote><pre>
[&hellip;]
unordered_multimap(initializer_list&lt;value_type&gt; <ins>il</ins>,
  size_type <ins>n</ins> = <em>see below</em>,
  const hasher&amp; hf = hasher(),
  const key_equal&amp; eql = key_equal(),
  const allocator_type&amp; a = allocator_type());
[&hellip;]
</pre></blockquote>
</li>

<li><p>Edit 23.5.5.2 [unord.multimap.cnstr] as follows:</p>
<blockquote><pre>
template &lt;class InputIterator&gt;
unordered_multimap(InputIterator f, InputIterator l,
  size_type n = <em>see below</em>,
  const hasher&amp; hf = hasher(),
  const key_equal&amp; eql = key_equal(),
  const allocator_type&amp; a = allocator_type());
<ins>unordered_multimap(initializer_list&lt;value_type&gt; il,
  size_type n = <em>see below</em>,
  const hasher&amp; hf = hasher(),
  const key_equal&amp; eql = key_equal(),
  const allocator_type&amp; a = allocator_type());</ins>
</pre><blockquote>
<p>
-3- <i>Effects</i>: Constructs an empty <tt>unordered_multimap</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is
implementation-defined. Then inserts elements from the range <tt>[f, l)</tt> <ins>for the first form, or from the range 
<tt>[il.begin(), il.end())</tt> for the second form</ins>. <tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Edit 23.5.6.1 [unord.set.overview], class template <tt>unordered_set</tt> synopsis, as follows:</p>

<blockquote><pre>
[&hellip;]
unordered_set(initializer_list&lt;value_type&gt; <ins>il</ins>,
  size_type <ins>n</ins> = <em>see below</em>,
  const hasher&amp; hf = hasher(),
  const key_equal&amp; eql = key_equal(),
  const allocator_type&amp; a = allocator_type());
[&hellip;]
</pre></blockquote>
</li>

<li><p>Edit 23.5.6.2 [unord.set.cnstr] as follows:</p>
<blockquote><pre>
template &lt;class InputIterator&gt;
unordered_set(InputIterator f, InputIterator l,
  size_type n = <em>see below</em>,
  const hasher&amp; hf = hasher(),
  const key_equal&amp; eql = key_equal(),
  const allocator_type&amp; a = allocator_type());
<ins>unordered_set(initializer_list&lt;value_type&gt; il,
  size_type n = <em>see below</em>,
  const hasher&amp; hf = hasher(),
  const key_equal&amp; eql = key_equal(),
  const allocator_type&amp; a = allocator_type());</ins>
</pre><blockquote>
<p>
-3- <i>Effects</i>: Constructs an empty <tt>unordered_set</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is
implementation-defined. Then inserts elements from the range <tt>[f, l)</tt> <ins>for the first form, or from the range 
<tt>[il.begin(), il.end())</tt> for the second form</ins>. <tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Edit 23.5.7.1 [unord.multiset.overview], class template <tt>unordered_multiset</tt> synopsis, as follows:</p>

<blockquote><pre>
[&hellip;]
unordered_multiset(initializer_list&lt;value_type&gt; <ins>il</ins>,
  size_type <ins>n</ins> = <em>see below</em>,
  const hasher&amp; hf = hasher(),
  const key_equal&amp; eql = key_equal(),
  const allocator_type&amp; a = allocator_type());
[&hellip;]
</pre></blockquote>
</li>

<li><p>Edit 23.5.7.2 [unord.multiset.cnstr] as follows:</p>
<blockquote><pre>
template &lt;class InputIterator&gt;
unordered_multiset(InputIterator f, InputIterator l,
  size_type n = <em>see below</em>,
  const hasher&amp; hf = hasher(),
  const key_equal&amp; eql = key_equal(),
  const allocator_type&amp; a = allocator_type());
<ins>unordered_multiset(initializer_list&lt;value_type&gt; il,
  size_type n = <em>see below</em>,
  const hasher&amp; hf = hasher(),
  const key_equal&amp; eql = key_equal(),
  const allocator_type&amp; a = allocator_type());</ins>
</pre><blockquote>
<p>
-3- <i>Effects</i>: Constructs an empty <tt>unordered_multiset</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is
implementation-defined. Then inserts elements from the range <tt>[f, l)</tt> <ins>for the first form, or from the range 
<tt>[il.begin(), il.end())</tt> for the second form</ins>. <tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2233"></a>2233. <tt>bad_function_call::what()</tt> unhelpful</h3>
<p><b>Section:</b> 20.9.11.1 [func.wrap.badcall] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-01-05 <b>Last modified:</b> 2014-05-02</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
A strict reading of the standard implies <tt>std::bad_function_call{}.what()</tt> returns the same string as
<tt>std::exception{}.what()</tt> which doesn't help to know what happened if you catch an exception by reference 
to <tt>std::exception</tt>.
</p>

<p>
For consistency with <tt>bad_weak_ptr::what()</tt> it should return <tt>"bad_function_call"</tt>.
</p>

<p>
See <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=33515">c++std-lib-33515</a> for other details.
</p>

<p>
There was a considerable support on the reflector to instead change the specification of both <tt>bad_weak_ptr::what()</tt> 
and <tt>bad_function_call::what()</tt> to return an implementation-defined string instead.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
Consensus that we want consistency in how this is treated.  Less consensus on what the common
direction should be.
</p>
<p>
Alisdair to provide wording proposing that all string literals held by standard exception objects are
either unspecified, or implmentation defined.
</p>

<p><i>[2014-02-15 Issauqah]</i></p>

<p>
STL: I think it should be an implementation-defined NTBS, same on <tt>bad_weak_ptr</tt>. I will write a PR.
</p>

<p><i>[2014-03-27, STL provides improved wording]</i></p>


<p>
The new wording reflects better the general agreement of the committee, see also issue <a href="lwg-active.html#2376">2376</a> for similar wording.
</p>

<p><i>[2014-03-28 Library reflector vote]</i></p>

<p>
The issue has been identified as Tentatively Ready based on five votes in favour.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Edit 20.9.11.1.1 [func.wrap.badcall.const]:</p>
<blockquote><pre>
bad_function_call() noexcept;
</pre><blockquote>
<p>
-1- <i>Effects</i>: constructs a <tt>bad_function_call object</tt>.
<p/>
<ins>-?- <i>Postconditions</i>: <tt>what()</tt> returns an implementation-defined NTBS.</ins>
</p>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2234"></a>2234. <tt>assert()</tt> should allow usage in constant expressions</h3>
<p><b>Section:</b> 19.3 [assertions] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2013-01-12 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#assertions">active issues</a> in [assertions].</p>
<p><b>View all other</b> <a href="lwg-index.html#assertions">issues</a> in [assertions].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It is unclear from the current specification whether <tt>assert()</tt> expressions can be used in 
(potential) constant expressions. As an example consider the implementation of a <tt>constexpr</tt>
function:
</p>

<blockquote><pre>
#include &lt;cassert&gt;

template&lt;class T, unsigned N&gt;
struct array {
  T data[N];
  constexpr const T&amp; operator[](unsigned i) const {
    return assert(i &lt; N), data[i];
  }
};

int main() {
  constexpr array&lt;int, 3&gt; ai = {1, 2, 3};
  constexpr int i = ai[0];
  int j = ai[0];
  // constexpr int k = ai[5];
}
</pre></blockquote>

<p>
The first question is whether this program is guaranteed well-formed? A second question is whether is would guaranteed to be
ill-formed, if we uncomment the last code line in <tt>main()</tt>?
</p>

<p>
The wording in 19.3 [assertions] doesn't add anything significant to the C99 wording. From the C99 specification 
(7.2 p1 and 7.2.1.1 p2) we get already some valuable guarantees:
</p>

<ul>
<li><p>
The expression <tt>assert(e)</tt> is a <tt>void</tt> expression for all expressions <tt>e</tt> independent of 
the definition of <tt>NDEBUG</tt>.
</p></li>
<li><p>
If <tt>NDEBUG</tt> is defined, <tt>assert(e)</tt> is equivalent to the expression <tt>void()</tt>
(or anything that cannot be distinguished from that).
</p></li>
</ul>

<p>
The current wording does not yet <em>guarantee</em> that <tt>assert</tt> expressions can be used in constant expressions,
but all tested implementations (gcc, MSVC) would already support this use-case. It seems to me that this should be possible
without giving <tt>assert</tt> a special meaning for the core language.
<p/>
As a related comment it should be added, that there is a core language 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3444.html">proposal</a> 
that intents to relax some current constraints for <tt>constexpr</tt> functions and <tt>literal</tt> types. The most 
interesting one (making <tt>void</tt> a literal types and allowing for expression-statements) would simplify the motivating 
example implementation of <tt>operator[]</tt> to:
</p>
<blockquote><pre>
constexpr const T&amp; operator[](unsigned i) const {
  assert(i &lt; N);
  return data[i];
};
</pre></blockquote>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
We are still gaining experience with <tt>constexpr</tt> as a language feature, and there may
be work in Evolution that would help address some of these concerns.  Defer discussion until
we have a group familiar with any evolutionary direction.
</p>

<p><i>[2014-06-08, Daniel comments and suggests wording]</i></p>

<p>
After approval of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3652.html"/>N3652<a/>,
<tt>void</tt> is now a literal type and <tt>constexpr</tt> functions can contain multiple statements, so
this makes the guarantee that <tt>assert</tt> expressions are per-se <tt>constexpr</tt>-friendly even more
relevant. A possible wording form could be along the lines of:
</p>
<blockquote>
<p>
For every core constant expression <em>e</em> of scalar type that evaluates to <tt>true</tt> after being contextually 
converted to <tt>bool</tt>, the expression <tt>assert(<em>e</em>)</tt> shall be a prvalue core constant expression of type 
<tt>void</tt>.
</p>
</blockquote>
<p>
Richard Smith pointed out some weaknesses of this wording form, for example it would not guarantee to require
the following example to work:
</p>
<blockquote><pre>
constexpr void check(bool b) { assert(b); }
</pre></blockquote>
<p>
because <tt>b</tt> is not a core constant expression in this context.
<p/>
He suggested improvements that lead to the wording form presented below (any defects mine). 
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Introduce the following new definition to the existing list in 17.3 [definitions]: [<i>Drafting note</i>:
If LWG <a href="lwg-active.html#2296">2296</a> is accepted before this issue, the accepted wording for the new definition should be used instead 
&mdash; <i>end drafting note</i>]</p>

<blockquote>
<p>
<strong>constant subexpression</strong> [defns.const.subexpr]
<p/>
an expression whose evaluation as subexpression of a <em>conditional-expression</em> <em>CE</em> (5.16 [expr.cond]) 
would not prevent <em>CE</em> from being a core constant expression (5.19 [expr.const]).
</p>
</blockquote>
</li>

<li><p>Insert a new paragraph following 19.3 [assertions] p1 as indicated:</p>

<blockquote>
<p>
<ins>-?- An expression <tt>assert(<em>E</em>)</tt> is a constant subexpression ( [defns.const.subexpr]), if either</ins>
</p>
<ul>
<li><p><ins><tt>NDEBUG</tt> is defined at the point where <tt>assert(<em>E</em>)</tt> appears, or</ins></p></li>
<li><p><ins><tt><em>E</em></tt> contextually converted to <tt>bool</tt> (4 [conv]), is a constant subexpression 
that evaluates to the value <tt>true</tt>.</ins></p></li>
</ul>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="2236"></a>2236. <tt>kill_dependency</tt> unconditionally noexcept</h3>
<p><b>Section:</b> 29.2 [atomics.syn], 29.3 [atomics.order] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2013-01-19 <b>Last modified:</b> 2013-10-15</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.syn">issues</a> in [atomics.syn].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The "magic" <tt>kill_dependency</tt> function is a function without any constraints on the template parameter <tt>T</tt> 
and is specified as
</p>

<blockquote><pre>
template &lt;class T&gt;
T kill_dependency(T y) noexcept;
</pre><blockquote>
<p>
-14- <i>Effects</i>: The argument does not carry a dependency to the return value (1.10).
<p/>
-15- <i>Returns</i>: <tt>y</tt>.
</p>
</blockquote></blockquote>

<p>
I wonder whether the unconditional noexcept is really intended here:
Assume we have some type <tt>U</tt> that has a potentially throwing move
constructor (or it has a potentially throwing copy constructor and no
move constructor), for any "normal" function template with the same
signature and the same effects (modulo the dependency magic) this
would mean that it cannot safely be declared noexcept because of the
return statement being part of the complete function call affected by
noexcept (The by-value function argument is irrelevant in this
context). In other words it seems that a function call such as
</p>

<blockquote><pre>
struct S {
  ...
  S(const S&amp; r) { if(<em>some condition</em>) throw Something(); }
  ...
};

int main() {
  S s1 = ...;
  S s2 = std::kill_dependency(s1);
}
</pre></blockquote>

<p>
would be required to call <tt>std::terminate</tt> if the copy constructor of <tt>S</tt> throws during the return 
of <tt>std::kill_dependency</tt>.
<p/>
To require copy elision for this already magic function would look like a low-hanging fruit to solve this problem, 
but this case is not covered by current copy elision rules see 12.8 p31 b1:
<p/>
"&mdash; in a return statement in a function with a class return type, when the expression is the name of a non-volatile 
automatic object (other than a function or catch-clause parameter) with the same <em>cv</em>-unqualified type as the 
function return type, the copy/move operation can be omitted by constructing the automatic object directly into the
function's return value".
<p/>
Some options come into my mind:
</p>
<ol>
<li><p>
Make the exception-specification a constrained one in regard via <tt>std::is_nothrow_move_constructible</tt>:
</p>

<blockquote><pre>
template &lt;class T&gt;
T kill_dependency(T y) noexcept(<em>see below</em>);
</pre></blockquote>

<p>
This is similar to the approach taken for function templates such as std::swap.
</p>
</li>

<li><p>
Use perfect forwarding (This needs further wording to correct the effects):
</p>

<blockquote><pre>
template &lt;class T&gt;
T&amp;&amp; kill_dependency(T&amp;&amp; y) noexcept;
</pre></blockquote>
</li>

<li><p>
Impose constraints on the template arguments in regard to throwing exceptions while copying/moving.
</p></li>

<li><p>
Keep the state as it is but possibly add a note about a call of <tt>std::terminate</tt> in above scenario.
</p></li>
</ol>

<p>
A second problem is that the current wording is not clear whether it is well-defined to call the function with
types that are reference types, such as in the following example:
</p>

<blockquote><pre>
#include &lt;atomic&gt;

int main()
{
  int a = 12;
  int&amp; b = std::kill_dependency&lt;int&amp;&gt;(a);
}
</pre></blockquote>

<p>
It is unclear what kind of dependency is killed here. This is presumably a core language problem, but could
affect the possible resolutions of the problem.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2237"></a>2237. <tt>&lt;cuchar&gt;</tt> macros</h3>
<p><b>Section:</b> 21.8 [c.strings] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jason Merrill <b>Opened:</b> 2013-01-29 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#c.strings">active issues</a> in [c.strings].</p>
<p><b>View all other</b> <a href="lwg-index.html#c.strings">issues</a> in [c.strings].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Apparently C1X changes <tt>__STDC_UTF_16__</tt> and <tt>__STDC_UTF_32__</tt> from macros
defined in <tt>uchar.h</tt> (and reflected in C++ by Table 79) to be predefined by the compiler. 
Do we want to do the same?
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2238"></a>2238. Problematic iterator-pair constructor of containers</h3>
<p><b>Section:</b> 21.8 [c.strings] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Johannes Schaub <b>Opened:</b> 2013-02-02 <b>Last modified:</b> 2014-07-01</p>
<p><b>View other</b> <a href="lwg-index-open.html#c.strings">active issues</a> in [c.strings].</p>
<p><b>View all other</b> <a href="lwg-index.html#c.strings">issues</a> in [c.strings].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The non-explicit nature of the iterator-pair constructor of containers, such a
</p>

<blockquote><pre>
template &lt;class InputIterator&gt;
vector(InputIterator first, InputIterator last, const Allocator&amp; = Allocator());
</pre></blockquote>

<p>
can be selected in unexpected situations, leading to a hard runtime error, as demonstrated by the following example:
</p>

<blockquote><pre>
#include &lt;vector&gt;

void f(std::vector&lt;char&gt; v){ /* ... */}

int main() {
  f({"A", "B"});
}
</pre></blockquote>

<p>
The actually intended initializer-list constructor isn't feasible here, so the best match is the constructor template
</p>

<blockquote><pre>
template &lt;class InputIterator&gt;
vector(InputIterator first, InputIterator last, const Allocator&amp; = Allocator());
</pre></blockquote>

<p>
This compiles, but will result in code running amok. The potential trap (that cannot be easily detected by the
library implementation) could be reduced by making this constructor explicit. It would still have the effect to 
be selected here, but the code would be ill-formed, so the programmer gets a clear meassage here.
</p>

<p><i>[2014-06 Rapperswil]</i></p>

<p>
JW: can't fix this, don't want to touch this, Do The Right Thing clause has been a source of tricky issues. 
only really happens with string literals, that's the only way to create an array that isn't obviously an array
<p/>
GR: want to see paper
<p/>
AM: is it only string literals, or also UDLs?
<p/>
STL: maybe, but we don't need to deal with that. This is only a problem in a very specific case 
<p/>
Leave as Open. 
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2239"></a>2239. <tt>min/max/minmax</tt> requirements</h3>
<p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Juan Soulie <b>Opened:</b> 2013-01-26 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
25.4.7 [alg.min.max] requires type <tt>T</tt> in <tt>min</tt>, <tt>max</tt>, and <tt>minmax</tt> to be 
<tt>LessThanComparable</tt>, but I don't believe this should be required for the versions that take a <tt>Compare</tt> 
argument.
<p/>
Paragraphs 1 to 4 of 25.4 [alg.sorting] should apply anyway, although I'm not sure about <tt>Compare</tt> 
being required to induce a strict weak ordering here.
<p/>
Further, <tt>min</tt> and <tt>max</tt> also lack formal complexity guarantees.
</p>

<p><i>[2014-06-07 Daniel comments and provides wording]</i></p>


<p>
Certainly, the functions with <tt>Compare</tt> should not impose <tt>LessThanComparable</tt> requirements.
<p/>
In regard to the question whether a strict weak ordering should be required as implied by the <tt>Compare</tt>
requirements, I would like to point out that this is requirement is in fact needed, because the specification of 
the normative <i>Remarks</i> elements (e.g. "Returns the first argument when the arguments are equivalent.") do depend 
on the existence of a <em>equivalence relation</em> that can be relied on and this is also consistent with the same
strict weak ordering requirement that is indirectly imposed by the <tt>LessThanComparable</tt> requirement set for 
functions referring to <tt>operator&lt;</tt> (Let me note that the very same <tt>StrictWeakOrder</tt> language 
concept had intentionally been required for similar reasons during "concept-time" in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>).
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 25.4.7 [alg.min.max] as indicated:
</p>

<blockquote>
<pre>
template&lt;class T&gt; constexpr const T&amp; min(const T&amp; a, const T&amp; b);
template&lt;class T, class Compare&gt;
  constexpr const T&amp; min(const T&amp; a, const T&amp; b, Compare comp);
</pre>
<blockquote>
<p>
-1- <i>Requires</i>: <ins>For the first form, type <tt>T</tt> shall be</ins><del>Type <tt>T</tt> is</del> <tt>LessThanComparable</tt> 
(Table 18).
<p/>
-2- <i>Returns</i>: The smaller value.
<p/>
-3- <i>Remarks</i>: Returns the first argument when the arguments are equivalent.
<p/>
<ins>-?- <i>Complexity</i>: Exactly one comparison.</ins>
</p>
</blockquote>

<pre>
template&lt;class T&gt;
  constexpr T min(initializer_list&lt;T&gt; t);
template&lt;class T, class Compare&gt;
  constexpr T min(initializer_list&lt;T&gt; t, Compare comp);
</pre>
<blockquote>
<p>
-4- <i>Requires</i>: <tt>T</tt> <del>is <tt>LessThanComparable</tt> and</del><ins>shall be</ins> <tt>CopyConstructible</tt> and 
<tt>t.size() &gt; 0</tt>. <ins>For the first form, type <tt>T</tt> shall be <tt>LessThanComparable</tt>.</ins>
<p/>
-5- <i>Returns</i>: [&hellip;]
<p/>
-6- <i>Remarks</i>: [&hellip;]
<p/>
<ins>-?- <i>Complexity</i>: Exactly one comparison.</ins>
</p>
</blockquote>

<pre>
template&lt;class T&gt; constexpr const T&amp; max(const T&amp; a, const T&amp; b);
template&lt;class T, class Compare&gt;
  constexpr const T&amp; max(const T&amp; a, const T&amp; b, Compare comp);
</pre>
<blockquote>
<p>
-7- <i>Requires</i>: <ins>For the first form, type <tt>T</tt> shall be</ins><del>Type <tt>T</tt> is</del> <tt>LessThanComparable</tt> 
(Table 18).
<p/>
-8- <i>Returns</i>: [&hellip;]
<p/>
-9- <i>Remarks</i>: [&hellip;]
<p/>
<ins>-?- <i>Complexity</i>: Exactly one comparison.</ins>
</p>
</blockquote>

<pre>
template&lt;class T&gt;
  constexpr T max(initializer_list&lt;T&gt; t);
template&lt;class T, class Compare&gt;
  constexpr T max(initializer_list&lt;T&gt; t, Compare comp);
</pre>
<blockquote>
<p>
-10- <i>Requires</i>: <tt>T</tt> <del>is <tt>LessThanComparable</tt> and</del><ins>shall be</ins> <tt>CopyConstructible</tt> and 
<tt>t.size() &gt; 0</tt>. <ins>For the first form, type <tt>T</tt> shall be <tt>LessThanComparable</tt>.</ins>
<p/>
-11- <i>Returns</i>: [&hellip;]
<p/>
-12- <i>Remarks</i>: [&hellip;]
<p/>
<ins>-?- <i>Complexity</i>: Exactly one comparison.</ins>
</p>
</blockquote>

<pre>
template&lt;class T&gt; constexpr pair&lt;const T&amp;, const T&amp;&gt; minmax(const T&amp; a, const T&amp; b);
template&lt;class T, class Compare&gt;
  constexpr pair&lt;const T&amp;, const T&amp;&gt; minmax(const T&amp; a, const T&amp; b, Compare comp);
</pre>
<blockquote>
<p>
-13- <i>Requires</i>: <ins>For the first form, t</ins><del>T</del>ype <tt>T</tt> shall be <tt>LessThanComparable</tt> 
(Table 18).
<p/>
-14- <i>Returns</i>: [&hellip;]
<p/>
-15- <i>Remarks</i>: [&hellip;]
<p/>
-16- <i>Complexity</i>: Exactly one comparison.
</p>
</blockquote>

<pre>
template&lt;class T&gt;
  constexpr pair&lt;T, T&gt; minmax(initializer_list&lt;T&gt; t);
template&lt;class T, class Compare&gt;
  constexpr pair&lt;T, T&gt; minmax(initializer_list&lt;T&gt; t, Compare comp);
</pre>
<blockquote>
<p>
-17- <i>Requires</i>: <tt>T</tt> <del>is <tt>LessThanComparable</tt> and</del><ins>shall be</ins> <tt>CopyConstructible</tt> and 
<tt>t.size() &gt; 0</tt>. <ins>For the first form, type <tt>T</tt> shall be <tt>LessThanComparable</tt>.</ins>
<p/>
-18- <i>Returns</i>: [&hellip;]
<p/>
-19- <i>Remarks</i>: [&hellip;]
<p/>
-20- <i>Complexity</i>: At most <tt>(3/2) * t.size()</tt> applications of the corresponding predicate.
</p>
</blockquote>

</blockquote>
</li>

</ol>





<hr>
<h3><a name="2241"></a>2241. <tt>&lt;cstdalign&gt;</tt> and <tt>#define</tt> of <tt>alignof</tt></h3>
<p><b>Section:</b> 18.10 [support.runtime] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2013-02-14 <b>Last modified:</b> 2014-03-03</p>
<p><b>View other</b> <a href="lwg-index-open.html#support.runtime">active issues</a> in [support.runtime].</p>
<p><b>View all other</b> <a href="lwg-index.html#support.runtime">issues</a> in [support.runtime].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to 18.10 [support.runtime] p2:
</p>

<blockquote><p>
The contents of these headers are the same as the Standard C library headers [..], <tt>&lt;stdalign.h&gt;</tt>, [..]
</p></blockquote>

<p>
Since our base C standard is C99, which doesn't have a <tt>&lt;stdalign.h&gt;</tt>, the reference to a non-existing 
C header is irritating (In this context <tt>&lt;stdalign.h&gt;</tt> doesn't refer to the deprecated C++ header
<tt>&lt;stdalign.h&gt;</tt> described in D.5 [depr.c.headers]).
<p/>
Furthermore, it would be also important that it doesn not define a macro named <tt>alignof</tt>, which C11 also defines 
in this header. 
<p/>
Currently we only have the following guarantee as part of 18.10 [support.runtime] p7:
</p>

<blockquote><p>
The header <tt>&lt;cstdalign&gt;</tt> and the header <tt>&lt;stdalign.h&gt;</tt> shall not define a macro named 
<tt>alignas</tt>.
</p></blockquote>

<p>
It is unclear what the better strategy is: Striking the reference to <tt>&lt;stdalign.h&gt;</tt> in
18.10 [support.runtime] p2 or upgrading to C11 as new base C standard.
</p>

<p><i>[2014-02-15 Issaquah]</i></p>

<p>
STL: related to earlier issue on C4, <a href="lwg-active.html#2201">2201</a>, and now we get a C11 header
</p>
<p>
JY: find _Alignof as keyword C11 FDIS has four defines in stdalign.h
</p>
<p>
AM: need paper for C11 as base library we should really do that
</p>
<p>
STL: really need vendor input
</p>
<p>
STL: don't think we need to do anything right now not P1
</p>
<p>
AM: any objections to downscale to P2  (no objections)
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2242"></a>2242. <tt>[uninitialized_]copy_n()</tt> defect</h3>
<p><b>Section:</b> 25.3.1 [alg.copy], 20.7.12.2 [uninitialized.copy] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Sean Parent <b>Opened:</b> 2013-02-14 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.copy">issues</a> in [alg.copy].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>copy_n()</tt> and <tt>uninitialized_copy_n()</tt> only return the output iterator, and not the input iterator. 
Likely the interface was simply copied from the original STL. Unfortunately the interface in the original STL contains a bug.
<p/>
<tt>copy_n()</tt> and <tt>uninitialized_copy_n()</tt> must return the resulting input iterator as well as the output 
iterator (I would suggest returning a pair). Without this, there is no way to continue reading from an actual input 
iterator &mdash; and if it is really a forward iterator, it will cost <tt>n</tt> increments to get back to where you were.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2243"></a>2243. <tt>istream::putback</tt> problem</h3>
<p><b>Section:</b> 27.7.2.3 [istream.unformatted] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Juan Soulie <b>Opened:</b> 2013-03-01 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
<p><b>View all other</b> <a href="lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 27.7.2.3 [istream.unformatted] / 34, when describing <tt>putback</tt>, it says that "<tt>rdbuf-&gt;sputbackc()</tt>" 
is called. The problem are not the obvious typos in the expression, but the fact that it may lead to different 
interpretations, since nowhere is specified what the required argument to <tt>sputbackc</tt> is.
<p/>
It can be guessed to be "<tt>rdbuf()-&gt;sputbackc(c)</tt>", but "<tt>rdbuf()-&gt;sputbackc(char_type())</tt>" or 
just anything would be as conforming (or non-confoming) as the first guess.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2244"></a>2244. Issue on <tt>basic_istream::seekg</tt></h3>
<p><b>Section:</b> 27.7.2.3 [istream.unformatted] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Juan Soulie <b>Opened:</b> 2013-03-04 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
<p><b>View all other</b> <a href="lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
When issue <a href="lwg-defects.html#1445">1445</a> was resolved by adopting 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3168.htm">N3168</a>, it exposed the need to 
modify both overloads of <tt>basic_istream::seekg</tt> (by inserting "the function clears eofbit," after "except that"), 
but the fix applied to the text apparently forgets the second overload at 27.7.2.3 [istream.unformatted] p43.
</p>

<p><i>[2013-10-17: Daniel provides concrete wording]</i></p>


<p>
It seems that the tiny sentence "SIMILARLY for 27.7.1.3/43 (<tt>seekg</tt>)." had been overlooked. I agree that the wording needs to be
applied here as well.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Change 27.7.2.3 [istream.unformatted] p43 as indicated:</p>

<blockquote><pre>
basic_istream&lt;charT,traits&gt;&amp; seekg(off_type off, ios_base::seekdir dir);
</pre><blockquote>
<p>
-43- <i>Effects:</i> Behaves as an unformatted input function (as described in 27.7.2.3, paragraph 1), except
that <ins>the function first clears <tt>eofbit</tt>,</ins> it does not count the number of characters extracted<ins>,</ins> 
and does not affect the value returned by subsequent calls to <tt>gcount()</tt>. [&hellip;]
</p>
</blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="2245"></a>2245. <tt>packaged_task::reset()</tt> memory allocation</h3>
<p><b>Section:</b> 30.6.9.1 [futures.task.members] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-03-05 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.task.members">active issues</a> in [futures.task.members].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.task.members">issues</a> in [futures.task.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The effects of <tt>packaged_task::reset()</tt> result in memory allocation, but
don't allow a user to provide an allocator.
<p/>
<tt>packaged_task::reset()</tt> needs to be overloaded like so:
</p>

<blockquote><pre>
template&lt;class Alloc&gt;  
void reset(const Alloc&amp;);
</pre></blockquote>

<p>
Alternatively, the effects of <tt>reset()</tt> need to require the same allocator is used 
as at construction, which would require the constructor to store the allocator for later use.
<p/>
I like to remark that GCC at the moment uses the second option, i.e. the allocator passed to the constructor 
(if any) is used to create the new shared state, because this didn't require any change to the
interface.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2248"></a>2248. <tt>numeric_limits::is_iec559</tt> misnamed</h3>
<p><b>Section:</b> 18.3.2 [limits] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2013-03-08 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#limits">issues</a> in [limits].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
This member should probably be named "is_ieee754". Or at least the standard should explain that IEC-559 no longer exists, 
and that it's been superseded by IEEE-754.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2250"></a>2250. Follow-up On Library Issue 2207</h3>
<p><b>Section:</b> 20.6.1 [bitset.cons], 20.6.2 [bitset.members], 21.4.2 [string.cons], 21.4.6 [string.modifiers], 21.4.7 [string.ops] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Frank Birbacher <b>Opened:</b> 2013-04-18 <b>Last modified:</b> 2014-05-23</p>
<p><b>View all other</b> <a href="lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Similar to LWG <a href="lwg-defects.html#2207">2207</a> there are several other places where the "Requires" clause precludes the "Throws" condition. 
Searching for the <tt>out_of_range</tt> exception to be thrown, the following have been found (based on the working draft
N3485):
</p>

<ol>
<li><p>20.6.1 [bitset.cons] p3+4</p></li>
<li><p>20.6.2 [bitset.members] p13+14 (<tt>set</tt>)</p></li>
<li><p>20.6.2 [bitset.members] p19+20 (<tt>reset</tt>)</p></li>
<li><p>20.6.2 [bitset.members] p27+28 (<tt>flip</tt>)</p></li>
<li><p>20.6.2 [bitset.members] p41+42 (<tt>test</tt>)</p></li>
<li><p>21.4.2 [string.cons] p3+4</p></li>
<li><p>21.4.6.2 [string::append] p3+4</p></li>
<li><p>21.4.6.3 [string::assign] p4+5</p></li>
<li><p>21.4.6.4 [string::insert] p1+2, p5+6, p9+10 (partially)</p></li>
<li><p>21.4.6.5 [string::erase] p1+2</p></li>
<li><p>21.4.6.6 [string::replace] p1+2, p5+6, p9+10 (partially)</p></li>
<li><p>21.4.6.7 [string::copy] p1+2</p></li>
<li><p>21.4.7.8 [string::substr] p1+2</p></li>
</ol>

<p><i>[2013-10-15: Daniel provides wording]</i></p>


<p>
In addition to the examples mentioned in the discussion, a similar defect exists for <tt>thread</tt>'s <tt>join()</tt> 
and <tt>detach</tt> functions (see 30.3.1.5 [thread.thread.member]). The suggested wording applies a similar fix for these
as well.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Modify 20.6.1 [bitset.cons] as indicated: <em>[Editorial comment: The wording form used to ammend the 
<i>Throws</i> element is borrowed from a similar style used in 21.4.6.6 [string::replace] p10]</em></p>

<blockquote><pre>
template &lt;class charT, class traits, class Allocator&gt;
explicit
bitset(const basic_string&lt;charT, traits, Allocator&gt;&amp; str,
       typename basic_string&lt;charT, traits, Allocator&gt;::size_type pos = 0,
       typename basic_string&lt;charT, traits, Allocator&gt;::size_type n =
         basic_string&lt;charT, traits, Allocator&gt;::npos,
         charT zero = charT('0'), charT one = charT('1'));
</pre><blockquote>
<p>
<del>-3- <i>Requires:</i> <tt>pos &lt;= str.size()</tt>.</del>
<p/>
-4- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; str.size()</tt> <ins>or <tt>invalid_argument</tt> if an
invalid character is found (see below)</ins>.
<p/>
-5- <i>Effects:</i> Determines the effective length <tt>rlen</tt> of the initializing string as the smaller of <tt>n</tt> and 
<tt>str.size() - pos</tt>.
<p/>
The function then throws <tt>invalid_argument</tt> if any of the <tt>rlen</tt> characters in <tt>str</tt> beginning at position
<tt>pos</tt> is other than <tt>zero</tt> or <tt>one</tt>. The function uses <tt>traits::eq()</tt> to compare the character values.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 20.6.2 [bitset.members] as indicated:</p>

<blockquote><pre>
bitset&lt;N&gt;&amp; set(size_t pos, bool val = true);
</pre><blockquote>
<p>
<del>-13- <i>Requires:</i> <tt>pos</tt> is valid</del>
<p/>
-14- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit position.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
bitset&lt;N&gt;&amp; reset(size_t pos);
</pre><blockquote>
<p>
<del>-19- <i>Requires:</i> <tt>pos</tt> is valid</del>
<p/>
-20- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit position.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
bitset&lt;N&gt;&amp; flip(size_t pos);
</pre><blockquote>
<p>
<del>-27- <i>Requires:</i> <tt>pos</tt> is valid</del>
<p/>
-28- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit position.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
bool test(size_t pos) const;
</pre><blockquote>
<p>
<del>-41- <i>Requires:</i> <tt>pos</tt> is valid</del>
<p/>
-42- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit position.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

</li>

<li><p>Modify 21.4.2 [string.cons] as indicated:</p>

<blockquote><pre>
basic_string(const basic_string&amp; str,
             size_type pos, size_type n = npos,
             const Allocator&amp; a = Allocator());
</pre><blockquote>
<p>
<del>-3- <i>Requires:</i> <tt>pos &lt;= str.size()</tt></del>
<p/>
-4- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; str.size()</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 21.4.4 [string.capacity] as indicated:</p>

<blockquote><pre>
void resize(size_type n, charT c);
</pre><blockquote>
<p>
<del>-6- <i>Requires:</i> <tt>n &lt;= max_size()</tt></del>
<p/>
-7- <i>Throws:</i> <tt>length_error</tt> if <tt>n &gt; max_size()</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 21.4.6.2 [string::append] as indicated:</p>

<blockquote><pre>
basic_string&amp;
  append(const basic_string&amp; str, size_type pos, size_type n = npos);
</pre><blockquote>
<p>
<del>-3- <i>Requires:</i> <tt>pos &lt;= str.size()</tt></del>
<p/>
-4- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; str.size()</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 21.4.6.3 [string::assign] as indicated:</p>

<blockquote><pre>
basic_string&amp;
  assign(const basic_string&amp; str, size_type pos, 
         size_type n = npos);
</pre><blockquote>
<p>
<del>-5- <i>Requires:</i> <tt>pos &lt;= str.size()</tt></del>
<p/>
-6- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; str.size()</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 21.4.6.4 [string::insert] as indicated: <em>[Editorial note: The first change suggestion is also a bug fix
of the current wording, because (a) the function has parameter <tt>pos1</tt> but the semantics refers to <tt>pos</tt> and (b) 
it is possible that this function can throw <tt>length_error</tt>, see p10]</em></p>

<blockquote><pre>
basic_string&amp;
  insert(size_type pos<del>1</del>, const basic_string&amp; str);
</pre><blockquote>
<p>
<del>-1- <i>Requires:</i> <tt>pos &lt;= size()</tt>.</del>
<p/>
<del>-2- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; size()</tt>.</del>
<p/>
-3- <i>Effects:</i> <del>Calls</del><ins>Equivalent to:</ins> <tt><ins>return</ins> insert(pos, str.data(), str.size())<ins>;</ins></tt><del>.</del>
<p/>
<del>-4- <i>Returns:</i> <tt>*this</tt>.</del>
</p>
</blockquote></blockquote>

<blockquote><pre>
basic_string&amp;
  insert(size_type pos1, const basic_string&amp; str,
         size_type pos2, size_type n = npos);
</pre><blockquote>
<p>
<del>-5- <i>Requires:</i> <tt>pos1 &lt;= size()</tt> and <tt>pos2 &lt;= str.size()</tt>.</del>
<p/>
-6- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos1 &gt; size()</tt> or <tt>pos2 &gt; str.size()</tt>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
basic_string&amp;
  insert(size_type pos, const charT* s, size_type n);
</pre><blockquote>
<p>
-9- <i>Requires:</i> <tt>s</tt> points to an array of at least <tt>n</tt> elements of <tt>charT</tt> <del>and 
<tt>pos &lt;= size()</tt></del>.
<p/>
-10- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; size()</tt> or <tt>length_error</tt> if <tt>size() + n &gt; max_size()</tt>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
basic_string&amp;
  insert(size_type pos, const charT* s);
</pre><blockquote>
<p>
-13- <i>Requires:</i> <del><tt>pos &lt;= size()</tt> and</del> <tt>s</tt> points to an array of at least 
<tt>traits::length(s) + 1</tt> elements of <tt>charT</tt>.
<p/>
-14- <i>Effects:</i> Equivalent to <tt><ins>return</ins> insert(pos, s, traits::length(s))<ins>;</ins></tt><del>.</del>
<p/>
<del>-15- <i>Returns:</i> <tt>*this</tt>.</del>
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 21.4.6.5 [string::erase] as indicated:</p>

<blockquote><pre>
basic_string&amp; erase(size_type pos = 0, size_type n = npos);
</pre><blockquote>
<p>
<del>-1- <i>Requires:</i> <tt>pos &lt;= size()</tt></del>
<p/>
-2- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; size()</tt>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 21.4.6.6 [string::replace] as indicated: <em>[Editorial note: The first change suggestion is also a bug fix
of the current wording, because it is possible that this function can throw <tt>length_error</tt>, see p10]</em></p>

<blockquote><pre>
basic_string&amp;
  replace(size_type pos1, size_type n1,
          const basic_string&amp; str);
</pre><blockquote>
<p>
<del>-1- <i>Requires:</i> <tt>pos1 &lt;= size()</tt>.</del>
<p/>
<del>-2- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos1 &gt; size()</tt>.</del>
<p/>
-3- <i>Effects:</i> <del>Calls</del><ins>Equivalent to</ins> <tt><ins>return</ins> replace(pos1, n1, str.data(), str.size())<ins>;</ins></tt><del>.</del>
<p/>
<del>-4- <i>Returns:</i> <tt>*this</tt>.</del>
</p>
</blockquote></blockquote>

<blockquote><pre>
basic_string&amp;
  replace(size_type pos1, size_type n1,
          const basic_string&amp; str,
          size_type pos2, size_type n = npos);
</pre><blockquote>
<p>
<del>-5- <i>Requires:</i> <tt>pos1 &lt;= size()</tt> and <tt>pos2 &lt;= str.size()</tt>.</del>
<p/>
-6- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos1 &gt; size()</tt> or <tt>pos2 &gt; str.size()</tt>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
basic_string&amp;
  replace(size_type pos1, size_type n1, const charT* s, size_type n2);
</pre><blockquote>
<p>
-9- <i>Requires:</i> <del><tt>pos1 &lt;= size()</tt> and</del> <tt>s</tt> points to an array of at least <tt>n2</tt> elements 
of <tt>charT</tt>.
<p/>
-10- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos1 &gt; size()</tt> or <tt>length_error</tt> if the length of the resulting 
string would exceed <tt>max_size()</tt> (see below).
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
basic_string&amp;
  replace(size_type pos, size_type n, const charT* s);
</pre><blockquote>
<p>
-13- <i>Requires:</i> <del><tt>pos &lt;= size()</tt> and</del> <tt>s</tt> points to an array of at least 
<tt>traits::length(s) + 1</tt> elements of <tt>charT</tt>.
<p/>
-14- <i>Effects:</i> Equivalent to <tt><ins>return</ins> replace(pos, n, s, traits::length(s))<ins>;</ins></tt><del>.</del>
<p/>
<del>-15- <i>Returns:</i> <tt>*this</tt>.</del>
</p>
</blockquote></blockquote>

</li>

<li><p>Modify 21.4.6.7 [string::copy] as indicated:</p>

<blockquote><pre>
size_type copy(charT* s, size_type n, size_type pos = 0) const;
</pre><blockquote>
<p>
<del>-1- <i>Requires:</i> <tt>pos &lt;= size()</tt></del>
<p/>
-2- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; size()</tt>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 21.4.7.8 [string::substr] as indicated:</p>

<blockquote><pre>
basic_string substr(size_type pos = 0, size_type n = npos) const;
</pre><blockquote>
<p>
<del>-1- <i>Requires:</i> <tt>pos &lt;= size()</tt></del>
<p/>
-2- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; size()</tt>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 30.3.1.5 [thread.thread.member] as indicated:</p>

<blockquote><pre>
void join();
</pre><blockquote>
<p>
<del>-3- <i>Requires:</i> <tt>joinable()</tt> is true.</del>
<p/>
[&hellip;]
<p/>
-7- <i>Throws:</i> <tt>system_error</tt> when an exception is required (30.2.2).
<p/>
-8- <i>Error conditions:</i>
</p>
<ul>
<li><p>[&hellip;]</p></li>
<li><p><tt>invalid_argument</tt> &mdash; if the thread is not joinable.</p></li>
</ul>
</blockquote></blockquote>

<blockquote><pre>
void detach();
</pre><blockquote>
<p>
<del>-9- <i>Requires:</i> <tt>joinable()</tt> is true.</del>
<p/>
[&hellip;]
<p/>
-12- <i>Throws:</i> <tt>system_error</tt> when an exception is required (30.2.2).
<p/>
-13- <i>Error conditions:</i>
</p>
<ul>
<li><p>[&hellip;]</p></li>
<li><p><tt>invalid_argument</tt> &mdash; if the thread is not joinable.</p></li>
</ul>
</blockquote></blockquote>
</li>

</ol>





<hr>
<h3><a name="2251"></a>2251. C++ library should define <tt>ssize_t</tt></h3>
<p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2013-04-19 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#support.types">issues</a> in [support.types].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The C++ standard library defines <tt>size_t</tt>, a typedef for an implementation defined unsigned integer type 
that can represent the sizes of objects. The POSIX standard augments this with <tt>ssize_t</tt>, a typedef for a 
signed integer type that corresponds to <tt>size_t</tt>.
<p/>
The <tt>ssize_t</tt> typedef is useful &mdash; useful enough that the C++ standard even refers to it. (In a 
non-normative footnote in 27.5.2 [stream.types].)  Also, lots of OS vendors add it to their headers anyway, 
even though it isn't part of the C or C++ standards, because those vendors are trying to define headers that 
conform to multiple standards at once. We should make users' and implementers' lives easier by adding 
<tt>ssize_t</tt> to 18.2 [support.types].
</p>

<p><i>[2013-09-29, Suggested wording from Jayson Oldfather]</i></p>

<p> 
I decided to use the phrase to describe <tt>ssize_t</tt> below because of the text describing it in the 
<a href="http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html#tag_13_67">POSIX</a> standard. 
In it, it describes <tt>ssize_t</tt> with the value range of <tt>[-1,{SSIZE_MAX}]</tt>.
<tt>SSIZE_MAX</tt> is specified in the <a href="http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html#tag_13_24">POSIX</a> 
standard as a minimum value of <tt>_POSIX_SSIZE_MAX</tt>. This macro is referenced in the wording below.
</p>



<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Ammend 18.2 [support.types], Table 30 as indicated:
</p>

<blockquote>
<table border="1">
<caption>Table 30 &mdash; Header <tt>&lt;cstddef&gt;</tt> synopsis</caption>
<tr>
<th>Type</th>
<th>Name(s)</th>
</tr>

<tr>
<td>
<b>Macros:</b>
</td>
<td>
<tt>NULL offset_t</tt>
</td>
</tr>

<tr>
<td>
<b>Types:</b>
</td>
<td>
<tt>ptrdiff_t <ins>ssize_t</ins> size_t max_align_t nullptr_t</tt>
</td>
</tr>
</table>
</blockquote>

<p>Add the following paragraph to describe <tt>ssize_t</tt></p>
<blockquote><p><ins>
-?- The type <tt>ssize_t</tt> is an implementation-defined signed integer type that shall contain the minimum range 
<tt>[-1, {SSIZE_MAX}]</tt> where <tt>SSIZE_MAX</tt> is specified at a minimum of <tt>_POSIX_SSIZE_MAX</tt>.</ins>
</p></blockquote>
<p>Ammend p7 as follows:</p>
<blockquote><p>
-7- [<i>Note:</i> It is recommended that implementations choose types for <tt>ptrdiff_t<ins>, ssize_t,</ins></tt> and <tt>size_t</tt> whose integer conversion ranks &hellip;</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="2253"></a>2253. [arrays.ts] <tt>dynarray</tt> should state which container requirements aren't met</h3>
<p><b>Section:</b> X [dynarray.overview] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-04-23 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: arrays.ts</b></p>

<p>
X [dynarray.overview] p2 says:
</p>
<blockquote>
<p>
"Unless otherwise specified, all <tt>dynarray</tt> operations have the same requirements and semantics as specified in
23.2 [container.requirements]."
</p>
</blockquote>
<p>
Some differences from 23.2 [container.requirements] are not explicitly specified, including at
least the lack of a default constructor, copy assignment and <tt>swap</tt> member.
<p/>
The wording could be similar to 23.3.2.1 [array.overview] which says "An array satisfies all of the requirements 
of a container and of a reversible container (23.2 [container.requirements]), except that a default constructed 
array object is not empty and that <tt>swap</tt> does not have constant complexity."
</p>

<p><i>[2013-09 Chicago:]</i></p>

<p>
Move to Deferred. This feature will ship after C++14 and should be revisited then.
</p>

<p><i>[2014-06-06 pre-Rapperswil]</i></p>

<p>
This issue has been reopened as arrays-ts.
</p>

<p><i>[2014-06-16 Rapperswil]</i></p>

<p>
Move to Ready
</p>



<p><b>Proposed resolution:</b></p>

<ol>
<li><p>Add to X [dynarray.overview] p2:</p>
<p>
-2- <ins>A <tt>dynarray</tt> satisfies all of the requirements of a container and of a reversible container 
(23.2 [container.requirements]), except for default construction, assignment and <tt>swap</tt>.</ins> Unless 
otherwise specified, all <tt>dynarray</tt> operations have the same requirements and semantics as specified in 
23.2 [container.requirements].
</p>
</li>
</ol>






<hr>
<h3><a name="2254"></a>2254. [arrays.ts] Is <tt>dynarray</tt> an allocator-aware container?</h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-04-23 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: arrays.ts</b></p>

<p>
23.2.1 [container.requirements.general] p3 says:
</p>
<blockquote>
<p>
"All of the containers defined in this Clause and in (21.4) except <tt>array</tt> meet the additional requirements 
of an allocator-aware container, as described in Table 99."
</p>
</blockquote>
<p>
Is this true of <tt>dynarray</tt>?  I believe the answer must be no because <tt>dynarray</tt> has no <tt>allocator_type</tt>, 
and morally should be no, so that operations are defined in terms of <tt>std::allocator&lt;T&gt;</tt>, which p13 says
doesn't actually need to be used (which allows the elements to be default-initialized as is intended, rather than 
"default-inserted into the container" using an allocator.)
<p/>
The requirement that "each element is constructed with uses-allocator construction" provides roughly equivalent behaviour 
to the "<em>CopyInsertable into <tt>X</tt></em>" requirements for allocator-aware containers, allowing an allocator to 
control construction of the <tt>dynarray</tt> elements.
</p>

<p><i>[2013-09 Chicago]</i></p>

<p>
Move to Deferred. This feature will ship after C++14 and should be revisited then.
</p>

<p><i>[2014-06-06 pre-Rapperswill]</i></p>

<p>
This issue has been reopened as arrays-ts.
</p>



<p><b>Proposed resolution:</b></p>

<ol>
<li><p>Change to 23.2.1 [container.requirements.general] p13:</p>
<p>
-13- All of the containers defined in this Clause and in (21.4) except <tt>array</tt> <ins>and <tt>dynarray</tt></ins> 
meet the additional requirements of an allocator-aware container, as described in Table 99.
</p>
</li>
</ol>






<hr>
<h3><a name="2255"></a>2255. [arrays.ts] <tt>dynarray</tt> constructor ambiguity</h3>
<p><b>Section:</b> X [dynarray.cons] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-04-23 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: arrays.ts</b></p>

<p>
These constructors can interact badly::
</p>
<blockquote><pre>
template&lt;class Alloc&gt;
  dynarray(size_type c, const Alloc&amp; alloc);
dynarray(size_type c, const T&amp; v);
</pre></blockquote>
<p>
Unless the second argument is a value of exactly the type <tt>T</tt> you will get the first constructor, i.e. 
all of these will fail to compile:
</p>
<blockquote><pre>
dynarray&lt;long&gt; dlong(1, 1);   // 1 is not long
dynarray&lt;float&gt; dflt(1, 1.0);  // 1.0 is not float
dynarray&lt;int*&gt; dptr(1, nullptr);  // nullptr is not int*
dynarray&lt;void*&gt; doh(1, 0);  // 0 is not void*
</pre></blockquote>
<p>
The <tt>nullptr</tt> case is particularly annoying, a user trying to do the right thing by saying <tt>nullptr</tt> 
instead of <tt>NULL</tt> still gets the wrong result.
<p/>
The constructor taking an allocator requires that "<tt>Alloc</tt> shall meet the requirements for an Allocator" 
but doesn't actually say "shall not participate in overload resolution unless ..."
<p/>
I believe we have no precedent for using SFINAE to check "the requirements for an Allocator" because it's 
a pretty complicated set of requirements. We could say it shall not participate in overload resolution if <tt>Alloc</tt> 
is implicitly convertible to <tt>value_type</tt>.
<p/>
Alternatively, we could follow the same approach used by other types that can be constructed with an unconstrained 
allocator type and use <tt>std::allocator_arg_t</tt> as the first argument instead of adding an allocator after the 
other arguments.
</p>

<p><i>[2013-09 Chicago:]</i></p>

<p>
Move to Deferred. This feature will ship after C++14 and should be revisited then.
</p>

<p><i>[2014-06-06 pre-Rapperswil]</i></p>

<p>
This issue has been reopened as arrays-ts.
</p>

<p><i>[2014-06-16 Rapperswil]</i></p>

<p>
Move to Ready for alternative A
</p>

<strong>Previous resolution [SUPERSEDED]:</strong>
<p/>
<blockquote class="note"> 
<ol style="list-style-type:upper-alpha">
<li>
<p>
<em>Either</em> use the correct way to unambiguously call a constructor taking any type of allocator, i.e. change the 
constructors to take <tt>dynarray(std::allocator_arg_t, const Alloc&amp;, ...)</tt> by modifying both the synopsis
X [dynarray.overview] p2 and X [dynarray.cons] before p9 like so:</p>

<blockquote><pre>
template &lt;class Alloc&gt;
  dynarray(<ins>allocator_arg_t, const Alloc&amp; a, </ins>size_type c<del>, const Alloc&amp; alloc</del>);
template &lt;class Alloc&gt;
  dynarray(<ins>allocator_arg_t, const Alloc&amp; a, </ins>size_type c, const T&amp; v<del>, const Alloc&amp; alloc</del>);
template &lt;class Alloc&gt;
  dynarray(<ins>allocator_arg_t, const Alloc&amp; a, </ins>const dynarray&amp; d<del>, const Alloc&amp; alloc</del>);
template &lt;class Alloc&gt;
  dynarray(<ins>allocator_arg_t, const Alloc&amp; a, </ins>initializer_list&lt;T&gt;<del>, const Alloc&amp; alloc</del>);
</pre></blockquote>

</li>

<li><p><em>or</em> constrain the problematic constructor by adding a new paragraph to X [dynarray.cons]:</p>
<blockquote><pre>
template &lt;class Alloc&gt;
  dynarray(size_type c, const Alloc&amp; alloc);
template &lt;class Alloc&gt;
  dynarray(size_type c, const T&amp; v, const Alloc&amp; alloc);
template &lt;class Alloc&gt;
  dynarray(const dynarray&amp; d, const Alloc&amp; alloc);
template &lt;class Alloc&gt;
  dynarray(initializer_list&lt;T&gt;, const Alloc&amp; alloc);
</pre><blockquote>
<p>
-9- <i>Requires</i>: <tt>Alloc</tt> shall meet the requirements for an Allocator (17.6.3.5 [allocator.requirements]).
<p/>
-10- <i>Effects</i>: Equivalent to the preceding constructors except that each element is constructed with uses-allocator
construction (20.7.7.2 [allocator.uses.construction]).
<p/>
<ins>-?- <i>Remarks</i>: The first constructor shall not participate in overload resolution unless <tt>Alloc</tt> is not 
implicitly convertible to <tt>T</tt>.</ins>
</p>
</blockquote></blockquote>
</li>
</ol>
</blockquote>



<p><b>Proposed resolution:</b></p>

<ol>
<li>
<p>
Use the correct way to unambiguously call a constructor taking any type of allocator, i.e. change the 
constructors to take <tt>dynarray(std::allocator_arg_t, const Alloc&amp;, ...)</tt> by modifying both the synopsis
X [dynarray.overview] p2 and X [dynarray.cons] before p9 like so:</p>

<blockquote><pre>
template &lt;class Alloc&gt;
  dynarray(<ins>allocator_arg_t, const Alloc&amp; a, </ins>size_type c<del>, const Alloc&amp; alloc</del>);
template &lt;class Alloc&gt;
  dynarray(<ins>allocator_arg_t, const Alloc&amp; a, </ins>size_type c, const T&amp; v<del>, const Alloc&amp; alloc</del>);
template &lt;class Alloc&gt;
  dynarray(<ins>allocator_arg_t, const Alloc&amp; a, </ins>const dynarray&amp; d<del>, const Alloc&amp; alloc</del>);
template &lt;class Alloc&gt;
  dynarray(<ins>allocator_arg_t, const Alloc&amp; a, </ins>initializer_list&lt;T&gt;<del>, const Alloc&amp; alloc</del>);
</pre></blockquote>

</li>
</ol>






<hr>
<h3><a name="2256"></a>2256. On <tt>vector</tt> iterator invalidation</h3>
<p><b>Section:</b> 23.3.6.5 [vector.modifiers] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2013-04-29 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#vector.modifiers">active issues</a> in [vector.modifiers].</p>
<p><b>View all other</b> <a href="lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
23.3.6.5 [vector.modifiers]/p3 says:
</p>
<blockquote><pre>
iterator erase(const_iterator position);
iterator erase(const_iterator first, const_iterator last);
</pre>
<blockquote>
<p>
<i>Effects</i>: Invalidates iterators and references at or after the point of the erase.
</p>
</blockquote></blockquote>
<p>
Consider this example:
</p>
<blockquote><pre>
#include &lt;vector&gt;
#include &lt;cassert&gt;

int main()
{
  typedef std::vector&lt;int&gt; C;
  C c = {1, 2, 3, 4};
  C::iterator i = c.begin() + 1;
  C::iterator j = c.end() - 1;
  assert(*i == 2);
  assert(*j == 4);
  c.erase(c.begin());
  <span style="color:#C80000;font-weight:bold">assert(*i == 3); // Why is this not perfectly fine?!</span>
}
</pre></blockquote>
<p>
Why has the iterator <tt>i</tt> been invalidated? It still refers to a perfectly reasonable, fully constructed object. 
If <tt>vector::iterator</tt> were to be implemented as a pointer (which is legal), it is not possible for that last 
line to do anything but run fine.
<p/>
The iterator <tt>j</tt> on the other hand now points at end, and any iterators that may now point beyond <tt>end()</tt>, 
into uninitialized memory, are clearly invalid.
<p/>
But why do we say that an iterator that <em>must</em> point to a valid object is invalid? This looks to me like we 
simply got sloppy in our specification.
</p>


<p><b>Proposed resolution:</b></p>






<hr>
<h3><a name="2259"></a>2259. Issues in 17.6.5.5 rules for member functions</h3>
<p><b>Section:</b> 17.6.5.5 [member.functions] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2013-05-12 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#member.functions">issues</a> in [member.functions].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
17.6.5.5 [member.functions] p2 says:
</p>

<blockquote><p>
&quot;An implementation may declare additional non-virtual member function signatures within a class:
</p>
<ul>
<p>by adding arguments with default values to a member function signature; [Footnote: Hence, the address of a member 
function of a class in the C++ standard library has an unspecified type.] [<i>Note</i>: An implementation
may not add arguments with default values to virtual, global, or non-member functions. &mdash; <i>end note</i>]</p>
<p>by replacing a member function signature with default values by two or more member function signatures
with equivalent behavior; and</p>
<p>by adding a member function signature for a member function name.&quot;</p>
</ul>
</blockquote>

<ol>
<li>
<p>
This wording is not using the correct terminology. "by adding arguments with default values" presumably means 
"by adding parameters with default arguments", and likewise throughout.
</p>
</li>
<li>
<p>
This paragraph only allows an implementation to declare "additional" signatures, but the first bullet is talking 
about replacing a standard signature with one with additional parameters.
</p>
</li>
<li>
<p>
None of these bullets allows a member function with no <i>ref</i>-qualifier to be replaced by signatures with <i>ref</i>-qualifiers 
(a situation which was just discussed on std-proposals), and likewise for <i>cv</i>-qualifiers. Presumably that is 
not intentional, and such changes should be permissible.
</p>
</li>
</ol>

<p>
I think the first two items are probably editorial, since the intent is clear.
</p>

<p><i>[2013-12-11 Richard provides concrete wording]</i></p>

<p>
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

<ol>
<li><p>Merge 17.6.5.5 [member.functions]p2+3 as indicated:</p>

<blockquote>
<p>
-2- <del>An implementation may declare additional non-virtual member function signatures within a class:</del>
</p>
<ul>
<li><p>
<del>by adding arguments with default values to a member function signature;188 [<i>Note:</i> An implementation
may not add arguments with default values to virtual, global, or non-member functions. &mdash; <i>end note</i>]</del>
</p></li>
<li><p>
<del>by replacing a member function signature with default values by two or more member function signatures
with equivalent behavior; and</del>
</p></li>
<li><p>
<del>by adding a member function signature for a member function name.</del>
</p></li>
</ul>
<p>
<del>-3- A call to a member function signature described in the C++ standard library behaves as if the implementation
declares no additional member function signatures.[Footnote: A valid C++ program always calls the expected library 
member function, or one with equivalent behavior. An implementation may also define additional member functions 
that would otherwise not be called by a valid C++ program.]</del> <ins>For a non-virtual member function described 
in the C++ standard library, an implementation may declare a different set of member function signatures, provided 
that any call to the member function that would select an overload from the set of declarations described in this 
standard behaves as if that overload were selected. [<i>Note:</i> For instance, an implementation may add parameters 
with default values, or replace a member function with default arguments with two or more member functions with 
equivalent behavior, or add additional signatures for a member function name. &mdash; <i>end note</i>]</ins>
</p>

</blockquote>
</li>

</ol>





<hr>
<h3><a name="2260"></a>2260. Missing requirement for <tt>Allocator::pointer</tt></h3>
<p><b>Section:</b> 17.6.3.5 [allocator.requirements] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-05-14 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
For an allocator <tt>A&lt;T&gt;</tt> which defines <tt>A&lt;T&gt;::pointer</tt> to a class type,
i.e. not <tt>T*</tt>, I see no requirement that <tt>A&lt;T&gt;::pointer</tt> is convertible to
<tt>A&lt;U&gt;::pointer</tt>, even if <tt>T*</tt> is convertible to <tt>U*</tt>.  Such conversions are
needed in containers to convert from e.g. <tt>ListNodeBase*</tt> to <tt>ListNode&lt;T&gt;*</tt>.
</p>

<p>The obvious way to do such conversions appears to be
<tt>pointer_traits::pointer_to()</tt>, but that's ill-formed if the static
member function <tt>A&lt;T&gt;::pointer::pointer_to()</tt> doesn't exist and the
allocator requirements don't mention that function, so you need to
cast <tt>A&lt;T&gt;::pointer</tt> to <tt>A&lt;T&gt;::void_pointer</tt> then cast that to
<tt>A&lt;U&gt;::pointer</tt>.
</p>

<p>
Is converting via <tt>void_pointer</tt> really intended, or are we missing a requirement that 
<tt>pointer_traits&lt;A&lt;T&gt;::pointer&gt;::pointer_to()</tt> be well-formed?
</p>

<p>Proposed resolution:</p>

<p>Add to the Allocator requirements table the following requirement:</p>

<blockquote>
<p>
The expression <tt>pointer_traits&lt;XX::pointer&gt;::pointer_to(r)</tt> is well-defined.
</p>
</blockquote>

<p><i>[2013-09 Chicago]</i></p>

<p>
Pablo to come back with Proposed Wording
</p>


<p><b>Proposed resolution:</b></p>
<ol>
<li><p>
Edit Table 28 as indicated:
</p>

<blockquote>
<table border="1">
<caption>Table 28 &mdash; Allocator requirements (continued)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Default</th>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>static_cast&lt;X::const_pointer&gt;(z)</tt>
</td>
<td>
<tt>X::const_pointer</tt>
</td>
<td>
<tt>static_cast&lt;X::const_pointer&gt;(z) == q</tt>
</td>
<td>
&nbsp;
</td>
</tr>

<tr>
<td>
<ins><tt>pointer_traits&lt;X::pointer&gt;::pointer_to(r)</tt></ins>
</td>
<td>
<ins><tt>X::pointer</tt></ins>
</td>
<td>
&nbsp;
</td>
<td>
&nbsp;
</td>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

</table>
</blockquote>


</li>
</ol>





<hr>
<h3><a name="2261"></a>2261. Are containers required to use their '<tt>pointer</tt>' type internally?</h3>
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-05-14 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Is a container <tt>C</tt> only supposed to refer to allocated memory (blocks of
contiguous storage, nodes, etc.) through objects of type <tt>C::pointer</tt>
rather than <tt>C::value_type*</tt>?
</p>

<p>
I don't see anything explicitly requiring this, so a container could
immediately convert the result of <tt>get_allocator().allocate(1)</tt> to a
built-in pointer of type <tt>value_type*</tt> and only deal with the built-in
pointer until it needs to deallocate it again, but that removes most
of the benefit of allowing allocators to use custom pointer types.
</p>

<p><i>[2014-06-12, Jonathan comments]</i></p>

<p>
This issue is basically the same issue as LWG <a href="lwg-closed.html#1521">1521</a>, which agrees it's an issue, 
to be dealt with in the future, so I request that <a href="lwg-active.html#2261">2261</a> not be closed as a dup 
unless we reopen <a href="lwg-closed.html#1521">1521</a>.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2262"></a>2262. Requirement for <tt>unique_ptr&lt;T&gt;::get_deleter()(p)</tt> to be able to destroy the <tt>unique_ptr</tt></h3>
<p><b>Section:</b> 20.8.1.2 [unique.ptr.single] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Rob Desbois <b>Opened:</b> 2013-05-15 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#unique.ptr.single">active issues</a> in [unique.ptr.single].</p>
<p><b>View all other</b> <a href="lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
N3337 20.8.1.2.5 [unique.ptr.single.modifiers] contains 2 non-normative notes stating:
</p>

<blockquote>
<p>
[para 4]: &quot;The order of these operations is significant because the call to <tt>get_deleter()</tt> 
may destroy <tt>*this</tt>.&quot;
</p>
<p>
[para 5]: &quot;The postcondition does not hold if the call to <tt>get_deleter()</tt> destroys <tt>*this</tt> since 
<tt>this->get()</tt> is no longer a valid expression.&quot;
</p>
</blockquote>

<p>
It seems this wording was created to resolve <a href="lwg-defects.html#998">998</a> due to the possibility that a <tt>unique_ptr</tt> may be 
destroyed through deletion of its stored pointer where that directly or indirectly refers to the same <tt>unique_ptr</tt>. 
If <tt>unique_ptr</tt> is required to support circular references then it seems this must be normative text: an implementation 
is currently allowed to operate on <tt>*this</tt> after the assignment and deletion specified in para 4, since this is only 
'disallowed' by the non-normative note.
</p>

<p>I propose the following draft rewording:</p>

<p>
[para 4]: <i>Effects</i>: assigns <tt>p</tt> to the stored pointer, and then if the old value of the stored pointer, <tt>old_p</tt>, was not
equal to <tt>nullptr</tt>, calls <tt>get_deleter()(old_p)</tt>. <ins>No operation shall be performed after the call to 
<tt>get_deleter()(old_p)</tt> that requires <tt>*this</tt> to be valid, because the deletion may destroy <tt>*this</tt> if it is 
referred to directly or indirectly by the stored pointer.</ins> <del>[<i>Note:</i> The order of these operations is significant
because the call to <tt>get_deleter()</tt> may destroy <tt>*this</tt>. &mdash; <i>end note</i>]</del>
<p/>
[para 5]: <i>Postconditions</i>: <ins>If the call <tt>get_deleter()(old_p)</tt> destroyed <tt>*this</tt>, none. Otherwise,</ins> 
<tt>get() == p</tt>. <del>[<i>Note:</i> The postcondition does not hold if the call to <tt>get_deleter()</tt>
destroys <tt>*this</tt> since <tt>this->get()</tt> is no longer a valid expression. &mdash; <i>end note</i>]</del>
</p>

<p>
I expect it will also be necessary to amend the requirements for a deleter, so in addition:
</p>

<p>
20.8.1.2 [unique.ptr.single] [para 1]: The default type for the template parameter <tt>D</tt> is <tt>default_delete</tt>. 
A client-supplied template argument <tt>D</tt> shall be a function object type (20.10), lvalue-reference to function, or 
lvalue-reference to function object type for which, given a value <tt>d</tt> of type <tt>D</tt> and a value <tt>ptr</tt> of type 
<tt>unique_ptr&lt;T, D&gt;::pointer</tt>, the expression <tt>d(ptr)</tt> is valid and has the effect of disposing of the pointer 
as appropriate for that deleter. <ins>Where <tt>D</tt> is not an lvalue reference type, <tt>d(ptr)</tt> shall be valid if <tt>ptr</tt> 
refers directly or indirectly to the invoking <tt>unique_ptr</tt> object.</ins>
</p>

<p><i>[2013-10-05, Stephan T. Lavavej comments and provides alternative wording]</i></p>

<p>
In Chicago, we determined that the original proposed change to 20.8.1.2 [unique.ptr.single]/1 was insufficient, because 
<tt>d</tt> might be a reference to a deleter functor that's destroyed during self-destruction.
<p/>
We believed that 20.8.1.2.5 [unique.ptr.single.modifiers]/4 was already sufficiently clear. The Standard occasionally prevents 
implementations of <tt>X</tt> from doing various things, through the principle of "nothing allows <tt>X</tt> to fail in that situation".  
For example, <tt>v.push_back(v[0])</tt> is required to work for non-empty vectors because nothing allows that to fail. In this case, 
the intent to allow self-destruction is already clear.
<p/>
Additionally, we did not believe that 20.8.1.2.5 [unique.ptr.single.modifiers]/5 had to be changed. The current note is slightly 
squirrely but it does not lead to confusion for implementers or users.
</p>

<p>
Previous resolution from Rob Desbois:
</p>
<blockquote class="note">
<ol>
<li>
<p>
Edit 20.8.1.2 [unique.ptr.single] p1 as indicated:
</p>
<blockquote><p>
The default type for the template parameter <tt>D</tt> is <tt>default_delete</tt>. 
A client-supplied template argument <tt>D</tt> shall be a function object type (20.10), lvalue-reference to function, or 
lvalue-reference to function object type for which, given a value <tt>d</tt> of type <tt>D</tt> and a value <tt>ptr</tt> of type 
<tt>unique_ptr&lt;T, D&gt;::pointer</tt>, the expression <tt>d(ptr)</tt> is valid and has the effect of disposing of the pointer 
as appropriate for that deleter. <ins>Where <tt>D</tt> is not an lvalue reference type, <tt>d(ptr)</tt> shall be valid if <tt>ptr</tt> 
refers directly or indirectly to the invoking <tt>unique_ptr</tt> object.</ins>
</p></blockquote>
</li>

<li>
<p>
Edit 20.8.1.2.5 [unique.ptr.single.modifiers] p4+5 as indicated:
</p>
<blockquote><pre>
void reset(pointer p = pointer()) noexcept;
</pre><blockquote>
<p>
-3- <i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well formed, shall have well-defined behavior,
and shall not throw exceptions.
<p/>
-4- <i>Effects:</i> assigns <tt>p</tt> to the stored pointer, and then if the old value of the stored pointer, <tt>old_p</tt>, was not
equal to <tt>nullptr</tt>, calls <tt>get_deleter()(old_p)</tt>. <ins>No operation shall be performed after the call to 
<tt>get_deleter()(old_p)</tt> that requires <tt>*this</tt> to be valid, because the deletion may destroy <tt>*this</tt> if it is 
referred to directly or indirectly by the stored pointer.</ins> <del>[<i>Note:</i> The order of these operations is significant
because the call to <tt>get_deleter()</tt> may destroy <tt>*this</tt>. &mdash; <i>end note</i>]</del>
<p/>
-5- <i>Postconditions:</i> <ins>If the call <tt>get_deleter()(old_p)</tt> destroyed <tt>*this</tt>, none. Otherwise,</ins> 
<tt>get() == p</tt>. <del>[<i>Note:</i> The postcondition does not hold if the call to <tt>get_deleter()</tt>
destroys <tt>*this</tt> since <tt>this->get()</tt> is no longer a valid expression. &mdash; <i>end note</i>]</del>
</p>
</blockquote></blockquote>
</li>
</ol>

</blockquote>



<p><b>Proposed resolution:</b></p>

<p>This wording is relative to N3691.</p>

<ol>
<li>
<p>
Edit 20.8.1.2 [unique.ptr.single] p1 as indicated:
</p>
<blockquote><p>
The default type for the template parameter <tt>D</tt> is <tt>default_delete</tt>. 
A client-supplied template argument <tt>D</tt> shall be a function object type (20.10), lvalue-reference to function, or 
lvalue-reference to function object type for which, given a value <tt>d</tt> of type <tt>D</tt> and a value <tt>ptr</tt> of type 
<tt>unique_ptr&lt;T, D&gt;::pointer</tt>, the expression <tt>d(ptr)</tt> is valid and has the effect of disposing of the pointer 
as appropriate for that deleter. <ins><tt>d(ptr)</tt> shall be valid even if it triggers the destruction of <tt>d</tt> or (if 
<tt>D</tt> is an lvalue reference to function object type) the function object that <tt>d</tt> refers to.</ins>
</p></blockquote>
</li>
</ol>






<hr>
<h3><a name="2264"></a>2264. [arrays.ts] <tt>std::dynarray</tt> defines its initializer-list constructor in terms of a non-existent constructor</h3>
<p><b>Section:</b> X [dynarray], 23.2 [container.requirements] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Povilas Kanapickas <b>Opened:</b> 2013-05-22 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: arrays.ts</b></p>

<p>
<tt>std::dynarray</tt> member listing at X [dynarray.overview] includes this constructor:
</p>

<blockquote><pre>
dynarray(initializer_list&lt;T&gt;);
</pre></blockquote>

<p>
Also, X [dynarray.overview] p. 2 says:
</p>

<blockquote><p>
Unless otherwise specified, all <tt>dynarray</tt> operations have the same requirements and semantics as specified in 23.2.
</p></blockquote>

<p>
The constructor in question isn't mentioned in X [dynarray.cons] or anywhere else. This means requirements from 
23.2 [container.requirements] apply. However, Table 100 in 23.2.3 [sequence.reqmts] says:
</p>

<blockquote><p>
<tt>X(il)</tt> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Equivalent to <tt>X(il.begin(), il.end())</tt>      
</p></blockquote>

<p>
<tt>std::dynarray</tt> does not provide this constructor.
</p>

<p>
The proposed resolution below adds the missing constructor and a complementary constructor with an allocator parameter. 
The new constructors, differently from the rest of containers, accept iterators that have forward iterator category. This 
is needed because the size requirements must be known in order to allocate appropriately-sized storage.
<p/>
An alternative resolution could be to properly specify the initializer-list constructor.
</p>

<p><i>[2013-09 Chicago:]</i></p>

<p>
Move to Deferred. This feature will ship after C++14 and should be revisited then.
</p>

<p><i>[2014-06-06 pre-Rapperswill]</i></p>

<p>
This issue has been reopened as arrays-ts.
</p>



<p><b>Proposed resolution:</b></p>

<ol>
<li><p>Add the following to the <tt>std::dynarray</tt> synopsis at X [dynarray.overview]:</p>

<blockquote><pre>
namespace std {
  template &lt;class T&gt;
  class dynarray {
    [&hellip;]
    <i>// 23.3.4.2 construct/copy/destroy:</i>
    [&hellip;]
    <ins>template &lt;class ForwardIterator&gt;</ins>
    <ins>dynarray(ForwardIterator first, ForwardIterator last);</ins>
    <ins>template &lt;class ForwardIterator, class Alloc&gt;</ins>
    <ins>dynarray(ForwardIterator first, ForwardIterator last, const Alloc&amp; alloc);</ins>
    [&hellip;]
  };
}
</pre></blockquote>
</li>

<li><p>Add the following to X [dynarray.cons] after p. 8:</p>

<blockquote><pre>
<ins>template &lt;class ForwardIterator&gt;
dynarray(ForwardIterator first, ForwardIterator last);</ins>
</pre><blockquote>
<p>
<ins>-?-  <i>Requires:</i> <tt>T</tt> shall meet the <tt>CopyConstructible</tt> requirements.</ins>
<p/>
<ins>-?-  <i>Effects:</i> Allocates storage for <tt>distance(first, last)</tt> elements.
The <tt>distance(first, last)</tt> elements of the dynarray are direct-initialized (8.5 [dcl.init]) with the 
corresponding elements from the range <tt>[first,last)</tt>. May or may not invoke the global <tt>operator new</tt>.</ins>
<p/>
<ins>-?-  <i>Complexity:</i> <tt>distance(first, last)</tt>.</ins>
<p/>
<ins>-?-  <i>Throws:</i> <tt>std::bad_array_length</tt> when the size requested is larger than implementable, <tt>std::bad_alloc</tt> 
when there is insufficient memory.</ins>
</p>
</blockquote></blockquote>
</li>

<li><p>Add the following to the list of constructors at X [dynarray.cons] before p. 9:</p>
</li>

<blockquote><pre>
template &lt;class Alloc&gt;
dynarray(size_type c, const Alloc&amp; alloc);
template &lt;class Alloc&gt;
dynarray(size_type c, const T&amp; v, const Alloc&amp; alloc);
template &lt;class Alloc&gt;
dynarray(const dynarray&amp; d, const Alloc&amp; alloc);
template &lt;class Alloc&gt;
dynarray(initializer_list&lt;T&gt;, const Alloc&amp; alloc);
<ins>template &lt;class ForwardIterator, class Alloc&gt;
dynarray(ForwardIterator first, ForwardIterator last, const Alloc&amp; alloc);</ins>
</pre></blockquote>
</ol>






<hr>
<h3><a name="2265"></a>2265. 29.3p9 appears to rule out some acceptable executions</h3>
<p><b>Section:</b> 29.3 [atomics.order] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Brian Demsky <b>Opened:</b> 2013-06-17 <b>Last modified:</b> 2013-10-15</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.order">issues</a> in [atomics.order].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I believe that the following variation on IRIW should admit executions in
which <tt>c1 = d1 = 5</tt> and <tt>c2 = d2 = 0</tt>.  If this is allowed, then what is sequence of
program evaluations for 29.3 [atomics.order] p9 that justifies the store to <tt>z</tt>?  It seems that
29.3 [atomics.order] p9 should not allow this execution because one of the stores to <tt>x</tt> or <tt>y</tt> has
to appear earlier in the sequence, each of the <tt>fetch_adds</tt> reads the previous load in the thread (and thus must 
appear later in the sequence), and 29.3 [atomics.order] p9 states that each load must read from the last prior 
assignment in the sequence.
</p>

<blockquote><pre>
atomic_int x;
atomic_int y;
atomic_int z;
int c1, c2, d1, d2;

static void a(void* obj)
{
  atomic_store_explicit(&amp;x, 5, memory_order_relaxed); 
}

static void b(void* obj)
{
  atomic_store_explicit(&amp;y, 5, memory_order_relaxed); 
}

static void c(void* obj)
{
  c1 = atomic_load_explicit(&amp;x, memory_order_relaxed);
  // this could also be an atomic load if the address depends on c1:
  c2 = atomic_fetch_add_explicit(&amp;y, c1, memory_order_relaxed);  
}

static void d(void* obj)
{
  d1 = atomic_load_explicit(&amp;y, memory_order_relaxed);
  d2 = atomic_fetch_add_explicit(&amp;x, d1, memory_order_relaxed); 
}

int user_main(int argc, char** argv)
{
  thrd_t t1, t2, t3, t4;

  atomic_init(&amp;x, 0);
  atomic_init(&amp;y, 0);

  printf("Main thread: creating 4 threads\n");
  thrd_create(&amp;t1, (thrd_start_t)&amp;a, NULL);
  thrd_create(&amp;t2, (thrd_start_t)&amp;b, NULL);
  thrd_create(&amp;t3, (thrd_start_t)&amp;c, NULL);
  thrd_create(&amp;t4, (thrd_start_t)&amp;d, NULL);

  thrd_join(t1);
  thrd_join(t2);
  thrd_join(t3);
  thrd_join(t4);
  printf("c1=%d c2=%d\n",c1,c2);
  printf("d1=%d d2=%d\n",d1,d2);

  // Can this store write 1000 (i.e., c1=d1=5, c2=d2=0)?
  atomic_store(&amp;z, (c1+d1)*100+c2+d2);

  printf("Main thread is finished\n");

  return 0;
}
</pre></blockquote>

<p>
It seems that the easiest fix is to allow a load in 29.3 [atomics.order] p9 to read from any prior
store in the evaluation order.
<p/>
That said, I would personally advocate the following:
It seems to me that C/C++ atomics are in a bit of different situation than Java
because:
</p>
<ol>
<li><p>People are expected to use relaxed C++ atomics in potentially racy
situations, so it isn't clear that semantics as complicated as the JMM's
causality would be sane.
</p></li>
<li><p>People who use C/C++ atomics are likely to be experts and use them in a
very controlled fashion. I would be really surprised if compilers would find
any real wins by optimizing the use of atomics.
</p></li>
</ol>
<p>
Why not do something like:
<p/>
There is satisfaction DAG of all program evaluations. Each evaluation
observes the values of variables as computed by some prior assignment in
the DAG.
<p/>
There is an edge <tt>x-&gt;y</tt> between two evaluations <tt>x</tt> and <tt>y</tt> if:
</p>
<ol>
<li><p>the evaluation <tt>y</tt> observes a value computed by the evaluation <tt>x</tt> or
</p></li>
<li><p>the evaluation <tt>y</tt> is an atomic store, the evaluation <tt>x</tt> is an atomic load, and
there is a condition branch c that may depend (intrathread dependence) on <tt>x</tt>
and <tt>x-sb-&gt;c</tt> and <tt>c-sb-&gt;y</tt>.
</p></li>
</ol>
<p>
This seems to allow reordering of relaxed atomics that processors do without
extra fence instructions, allows most reorderings by the compiler, and gets
rid of satisfaction cycles.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2266"></a>2266. <tt>vector</tt> and <tt>deque</tt> have incorrect <tt>insert</tt> requirements</h3>
<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Ahmed Charles <b>Opened:</b> 2013-05-17 <b>Last modified:</b> 2014-05-23</p>
<p><b>View other</b> <a href="lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
<p><b>View all other</b> <a href="lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to Table 100 in n3485 23.2.3 [sequence.reqmts]/4 the notes for the expression <tt>a.insert(p,i,j)</tt>
say:
</p>

<blockquote><p>
<i>Requires:</i> <tt>T</tt> shall be <tt>EmplaceConstructible</tt>
into <tt>X</tt> from <tt>*i</tt>. For <tt>vector</tt>, if the iterator
does not meet the forward iterator requirements (24.2.5), <tt>T</tt> shall also be
<tt>MoveInsertable</tt> into <tt>X</tt> and <tt>MoveAssignable</tt>.
<p/>
Each iterator in the range <tt>[i,j)</tt> shall be dereferenced exactly once.
<p/>
<i>pre:</i> <tt>i</tt> and <tt>j</tt> are not iterators into <tt>a</tt>.
<p/>
Inserts copies of elements in <tt>[i, j)</tt> before <tt>p</tt>
</p></blockquote>

<p>
There are two problems with that wording: First, the special constraints for <tt>vector</tt>, that are expressed to be valid for
forward iterators only, are necessary for all iterator categories. Second, the same special constraints are needed for <tt>deque</tt>, too. 
</p>

<p><i>[2013-10-05, Stephan T. Lavavej comments and provides alternative wording]</i></p>

<p>
In Chicago, we determined that the original proposed resolution was correct, except that it needed additional requirements.  
When <tt>vector</tt> <tt>insert(p, i, j)</tt> is called with input-only iterators, it can't know how many elements will be inserted, 
which is obviously problematic for insertion anywhere other than at the end. Therefore, implementations typically append elements 
(geometrically reallocating), followed by <tt>rotate()</tt>. Given forward+ iterators, some implementations append and 
<tt>rotate()</tt> when they determine that there is sufficient capacity. Additionally, <tt>deque</tt> <tt>insert(p, i, j)</tt> is 
typically implemented with prepending/appending, with a possible call to <tt>reverse()</tt>, followed by a call to <tt>rotate()</tt>.  
Note that <tt>rotate()</tt>'s requirements are strictly stronger than <tt>reverse()</tt>'s.
<p/>
Therefore, when patching Table 100, we need to add <tt>rotate()</tt>'s requirements. Note that this does not physically affect code 
(implementations were already calling <tt>rotate()</tt> here), and even in Standardese terms it is barely noticeable &mdash; if an 
element is <tt>MoveInsertable</tt> and <tt>MoveAssignable</tt> then it is almost certainly <tt>MoveConstructible</tt> and swappable.  
However, this patch is necessary to be strictly correct.
</p>

<p>
Previous resolution from Ahmed Charles:
</p>
<blockquote class="note">
<ol>
<li><p>Change Table 100 as indicated:</p>
<blockquote>
<table border="1">
<caption>Table 100 &mdash; Sequence container requirements (in addition to container) (continued)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>a.insert(p,i,j)</tt>
</td>
<td>
<tt>iterator</tt>
</td>
<td>
<i>Requires:</i> <tt>T</tt> shall be <tt>EmplaceConstructible</tt>
into <tt>X</tt> from <tt>*i</tt>. For <tt>vector</tt> <ins>and <tt>deque</tt></ins>, <del>if the iterator
does not meet the forward iterator requirements (24.2.5),</del> <tt>T</tt> shall also be
<tt>MoveInsertable</tt> into <tt>X</tt> and <tt>MoveAssignable</tt>.<br/>
Each iterator in the range <tt>[i,j)</tt> shall be dereferenced exactly once.<br/>
<i>pre:</i> <tt>i</tt> and <tt>j</tt> are not iterators into <tt>a</tt>.<br/>
Inserts copies of elements in <tt>[i, j)</tt> before <tt>p</tt>
</td>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>

</table>
</blockquote>

</li>
</ol>
</blockquote>

<p><i>[2014-02-15 post-Issaquah session : move to Tentatively Ready]</i></p>

<p>
Pablo: We might have gone too far with the fine-grained requirements. Typically these things come in groups.
</p>
<p>
Alisdair: I think the concepts folks assumed we would take their guidance.
</p>
<p>
Move to Tentatively Ready.
</p>



<p><b>Proposed resolution:</b></p>

<ol>
<li><p>Change Table 100 as indicated:</p>
<blockquote>
<table border="1">
<caption>Table 100 &mdash; Sequence container requirements (in addition to container) (continued)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>a.insert(p,i,j)</tt>
</td>
<td>
<tt>iterator</tt>
</td>
<td>
<i>Requires:</i> <tt>T</tt> shall be <tt>EmplaceConstructible</tt> into <tt>X</tt><br/> 
from <tt>*i</tt>. For <tt>vector</tt> <ins>and <tt>deque</tt></ins>, <del>if the iterator</del><br/>
<del>does not meet the forward iterator requirements (24.2.5),</del> <tt>T</tt> shall also be<br/>
<tt>MoveInsertable</tt> into <tt>X</tt><ins>, <tt>MoveConstructible</tt>,</ins><br/> 
<del>and</del> <tt>MoveAssignable</tt><ins>, and swappable (17.6.3.2 [swappable.requirements])</ins>.<br/>
Each iterator in the range <tt>[i,j)</tt> shall be dereferenced exactly once.<br/>
<i>pre:</i> <tt>i</tt> and <tt>j</tt> are not iterators into <tt>a</tt>.<br/>
Inserts copies of elements in <tt>[i, j)</tt> before <tt>p</tt>
</td>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>

</table>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="2267"></a>2267. <tt>partial_sort_copy</tt> underspecified for ranges of two different types</h3>
<p><b>Section:</b> 25.4.1.4 [partial.sort.copy] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Matt Austern  <b>Opened:</b> 2013-06-26 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The signature of this function is:
</p>

<blockquote><pre>
template&lt;class InputIterator, class RandomAccessIterator&gt;
RandomAccessIterator
partial_sort_copy(InputIterator first, InputIterator last,
                  RandomAccessIterator result_first,
                  RandomAccessIterator result_last);

</pre></blockquote>

<p>
(and the usual overload for an explicitly provided comparison function). The standard says nothing about requirements 
in the case where the input type (<tt>iterator_traits&lt;InputIterator&gt;::value_type</tt>) and the output type 
(<tt>iterator_traits&lt;RandomAccessIterator&gt;::value_type</tt>) are different.
<p/>
Presumably the input type must be convertible to the output type. What's less clear is what the requirements are on 
the comparison operator. Does the algorithm only perform comparisons on two values of the output type, or does it also 
perform comparisons on values of the input type, or might it even perform heterogeneous comparisons?
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2269"></a>2269. Container iterators and argument-dependent lookup</h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2013-06-26 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider the following code snippet:
</p>

<blockquote><pre>
#include &lt;vector&gt;
#include &lt;algorithm&gt;

int main() {
  std::vector&lt;int&gt; v1(100, 3);
  std::vector&lt;int&gt; v2(100);
  copy(v1.begin(), v1.end(), v2.begin());
}
</pre></blockquote>

<p>
It compiles without error on my desktop. Is it required to? I can't find evidence from the standard that it is. 
In my test <tt>std::copy</tt> was found by argument-dependent lookup because the implementation I used made 
<tt>std::vector&lt;int&gt;::iterator</tt> a user-defined type defined in namespace <tt>std</tt>. But the standard 
only requires <tt>std::vector&lt;int&gt;::iterator</tt> to be an implementation specified random access iterator 
type. I can't find anything requiring it to be a user-defined type at all (and in fact there are reasonable implementation 
where it isn't), let alone a user defined type defined in a specific namespace.
</p>

<p>
Since the defining namespace of container iterators is visible to users, should the standard say anything about what 
that namespace is?
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2273"></a>2273. <tt>regex_match</tt> ambiguity</h3>
<p><b>Section:</b> 28.11.2 [re.alg.match] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2013-07-14 <b>Last modified:</b> 2014-07-01</p>
<p><b>View all other</b> <a href="lwg-index.html#re.alg.match">issues</a> in [re.alg.match].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
28.11.2 [re.alg.match] p2 in describing regex_match says:
</p>
<blockquote>
<p>
-2-  <i>Effects:</i> Determines whether there is a match between the regular expression <tt>e</tt>, and all of 
the character sequence <tt>[first,last)</tt>. The parameter <tt>flags</tt> is used to control how the expression 
is matched against the character sequence. Returns true if such a match exists, false otherwise.
</p>
</blockquote>

<p>
It has come to my attention that different people are interpreting the first sentence of p2 in different ways:
</p>

<ol>
<li><p>
If a search of the input string using the regular expression <tt>e</tt> matches the entire input string, 
<tt>regex_match</tt> should return true.
</p></li>
<li><p>
Search the input string using the regular expression <tt>e</tt>. Reject all matches that do not match the 
entire input string. If a such a match is found, return true.
</p></li>
</ol>

<p>
The difference between these two subtly different interpretations is found using the following ECMAScript example:
</p>

<blockquote><pre>
std::regex re("Get|GetValue");
</pre></blockquote>

<p>
Using <tt>regex_search</tt>, this <tt>re</tt> can never match the input string <tt>"GetValue"</tt>, because ECMA 
specifies that alternations are ordered, not greedy. As soon as <tt>"Get"</tt> is matched in the left alternation, 
the matching algorithm stops.
<p/>
Using definition 1, <tt>regex_match</tt> would return false for an input string of <tt>"GetValue"</tt>.
<p/>
However definition 2 alters the grammar and appears equivalent to augmenting the regex with a trailing <tt>'$'</tt>, 
which is an anchor that specifies, reject any matches which do not come at the end of the input sequence.
So, using definition 2, <tt>regex_match</tt> would return true for an input string of <tt>"GetValue"</tt>.
<p/>
My opinion is that it would be strange to have <tt>regex_match</tt> return true for a <tt>string/regex</tt> 
pair that <tt>regex_search</tt> could never find. I.e. I favor definition 1.
<p/>
John Maddock writes:
<p/>
The intention was always that <tt>regex_match</tt> would reject any match candidate which didn't match the entire 
input string. So it would find <tt>GetValue</tt> in this case because the <tt>"Get"</tt> alternative had already 
been rejected as not matching. Note that the comparison with ECMA script is somewhat moot, as ECMAScript defines 
the regex grammar (the bit we've imported), it does not define anything like <tt>regex_match</tt>, nor do we import 
from ECMAScript the behaviour of that function. So IMO the function should behave consistently regardless of the 
regex dialect chosen. Saying "use awk regexes" doesn't cut it, because that changes the grammar in other ways.
<p/>
(John favors definition 2).
<p/>
We need to clarify 28.11.2 [re.alg.match]/p2 in one of these two directions.
</p>

<p><i>[2014-06-21, Rapperswil]</i></p>

<p>
AM: I think there's a clear direction and consensus we agree with John Maddock's position, and if noone else 
thinks we need the other function I won't ask for it.
<p/>
Marshall Clow and STL to draft.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2274"></a>2274. Does <tt>map::operator[]</tt> value-initialize or default-insert a missing element?</h3>
<p><b>Section:</b> 23.4.4.3 [map.access], 23.5.4.3 [unord.map.elem] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Andrzej Krzemie&#324;ski <b>Opened:</b> 2013-07-16 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#map.access">issues</a> in [map.access].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Suppose that I provide a custom allocator for type <tt>int</tt>, that renders value 1 rather than 0 in default-insertion:
</p>
<blockquote>
<pre>
struct Allocator1 : std::allocator&lt;int&gt;
{
  using super = std::allocator&lt;int&gt;;

  template&lt;typename Up, typename... Args&gt;
  void construct(Up* p, Args&amp;&amp;... args)
  { super::construct(p, std::forward&lt;Args&gt;(args)...); }

  template&lt;typename Up&gt;
  void construct(Up* p)
  { ::new((void*)p) Up(1); }
};
</pre>
</blockquote>

<p>
Now, if I use this allocator with <tt>std::map</tt>, and I use <tt>operator[]</tt> to access a not-yet-existent value, 
what value of the <tt>mapped_type</tt> should be created? 0 (value-initialization) or 1 (default-insertion):
</p>

<blockquote>
<pre>
map&lt;string, int, less&lt;string&gt;, Allocator1&gt; map;
cout &lt;&lt; map["cat"];
</pre>
</blockquote>

<p>
N3960 is not very clear. 23.4.4.3 [map.access] in para 1 says:
</p>
<blockquote>
<p>
"If there is no key equivalent to <tt>x</tt> in the map, inserts <tt>value_type(x, T())</tt> into the map."
</p>
</blockquote>
<p>
So, it requires value-initialization.
<p/>
But para 2 says:
</p>
<blockquote>
<p>
"<tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt> into <tt>*this</tt>."
</p>
</blockquote>
<p>
This implies default-insertion, because if not, why the requirement. Also similar functions like 
<tt>vector::resize</tt> already require default-insertion wherever they put <tt>DefaultInsertable</tt> requirements.
<p/>
Not to mention that default-insertion is more useful, because it allows custom allocators to "override" the 
default value of <tt>mapped_type</tt>.
</p>

<p><i>[2013-09 Chicago]</i></p>

<p>
Alisdair: Matters only for POD or trivial types 
<p/>
Marshall: issue might show up elsewhere other than <tt>map&lt;&gt;</tt> 
<p/>
Alisdair: initialize elements in any containers &mdash; by calling construct on allocator traits 
<p/>
Marshall: existing wording is clear 
<p/>
Alisdair: main concern is difference in wording, discusses default initialization 
<p/>
Nico: different requirement needed 
<p/>
Alisdair: gut is issue is NAD, brings up <tt>DefaultInsertable</tt> definition &mdash; discusses definition 
<p/>
Nico: why do we have the requirement? 
<p/>
Alisdair: other containers have this requirement 
<p/>
Marshall: this applies to many other containers 
<p/>
Nico: <tt>deque&lt;&gt;</tt> in particular 
<p/>
Alisdair: discusses allocator construct 
<p/>
Alisdair: wording raises concerns that aren't said in existing standard 
<p/>
Nico: sees no benefit to change 
<p/>
Marshall: leery of change 
<p/>
Alisdair: can be made clearer; might need to add note to <tt>DefaultInsertable</tt>; borderline editorial, 
comfortable without note, willing to wait until other issues arise. close issue as NAD
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Change 23.4.4.3 [map.access] p1+p5 as indicated:</p>

<blockquote>
<pre>
T&amp; operator[](const key_type&amp; x);
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> If there is no key equivalent to <tt>x</tt> in the map, inserts <del><tt>value_type(x, T())</tt> 
into the map</del><ins>into the map a value with <tt>key_type</tt> initialized using expression <tt>x</tt> and <tt>mapped_type</tt> 
initialized by default-insertion</ins>.
<p/>
-2- <i>Requires:</i> <tt>key_type</tt> shall be <tt>CopyInsertable</tt> and <tt>mapped_type</tt> shall be 
<tt>DefaultInsertable</tt> into <tt>*this</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
T&amp; operator[](key_type&amp;&amp; x);
</pre>
<blockquote>
<p>
-5- <i>Effects:</i> If there is no key equivalent to <tt>x</tt> in the map, inserts 
<del><tt>value_type(std::move(x), T())</tt> into the map</del><ins>into the map a value with <tt>key_type</tt> 
initialized using expression <tt>std::move(x)</tt> and <tt>mapped_type</tt> initialized by default-insertion</ins>.
<p/>
-6- <i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt> into <tt>*this</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 23.5.4.3 [unord.map.elem] p2 as indicated:</p>

<blockquote>
<pre>
mapped_type&amp; operator[](const key_type&amp; k);
mapped_type&amp; operator[](key_type&amp;&amp; k);
</pre>
<blockquote>
<p>
-1- <i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt> into <tt>*this</tt>. 
For the first operator, <tt>key_type</tt> shall be <tt>CopyInsertable</tt> into <tt>*this</tt>. For the second 
operator, <tt>key_type</tt> shall be <tt>MoveConstructible</tt>.
<p/>
-2- <i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an element whose key is equivalent to 
<tt>k</tt>, the first operator inserts <del>the value <tt>value_type(k, mapped_type())</tt></del><ins>a value with 
<tt>key_type</tt> initialized using expression <tt>x</tt> and <tt>mapped_type</tt> initialized by default-insertion</ins> 
and the second operator inserts <del>the value <tt>value_type(std::move(k), mapped_type())</tt></del><ins>a value 
with <tt>key_type</tt> initialized using expression <tt>std::move(x)</tt> and <tt>mapped_type</tt> initialized by 
default-insertion</ins>.
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2276"></a>2276. Missing requirement on <tt>std::promise::set_exception</tt></h3>
<p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-07-30 <b>Last modified:</b> 2013-10-15</p>
<p><b>View all other</b> <a href="lwg-index.html#futures">issues</a> in [futures].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The standard does not specify the behaviour of this program:
</p>

<blockquote><pre>
#include &lt;future&gt;
#include &lt;cassert&gt;

struct NonTrivial
{
  NonTrivial() : init(true) { }
  ~NonTrivial() { assert(init); }
  bool init;
};

int main()
{
  std::promise&lt;NonTrivial&gt; p;
  auto f = p.get_future();
  p.set_exception(std::exception_ptr());
  f.get();
}
</pre></blockquote>

<p>
The standard doesn't forbid making the state ready with a null
<tt>exception_ptr</tt>, so what should <tt>get()</tt> return?  There's no stored
exception to throw, but it can't return a value because none was initialized.
<p/>
A careful reading of the standard shows 30.6.4 [futures.state] p8 says
"A shared state is <em>ready</em> only if it holds a value or an exception
ready for retrieval." One can infer from the fact that <tt>set_exception()</tt>
makes the state ready that it must store a value or exception, so
cannot store "nothing", but that isn't explicit.
<p/>
The <tt>promise::set_exception()</tt> and <tt>promise::set_exception_at_thread_exit()</tt> 
members should require <tt>p != nullptr</tt> or should state the type of exception thrown 
if <tt>p</tt> is null.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2277"></a>2277. [arrays.ts] <tt>&lt;dynarray&gt;</tt> is missing in 24.7/1</h3>
<p><b>Section:</b> 24.7 [iterator.range] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Cassio Neri <b>Opened:</b> 2013-07-31 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all other</b> <a href="lwg-index.html#iterator.range">issues</a> in [iterator.range].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: arrays.ts</b></p>

<p>
Section 24.7 [iterator.range] p1 specifies header files that, in addition to
<tt>&lt;iterator&gt;</tt>, make available the function templates in 24.7
(<tt>begin</tt>, <tt>end</tt>, etc.) but it fails to mention
<tt>&lt;dynarray&gt;</tt>. This seems to be just an oversight.
</p>

<p><i>[2013-09 Chicago:]</i></p>

<p>
Move to Deferred. This feature will ship after C++14 and should be revisited then. 
</p>

<p><i>[2014-06-06 pre-Rapperswill]</i></p>

<p>
This issue has been reopened as arrays-ts.
</p>



<p><b>Proposed resolution:</b></p>

<p>This wording is relative to N3691.</p>

<ol>
<li><p>Modify 24.7 [iterator.range] p1 as indicated:</p>

<blockquote><p>
-1- In addition to being available via inclusion of the <tt>&lt;iterator&gt;</tt> header, the function templates in 24.7 are
available when any of the following headers are included: <tt>&lt;array&gt;</tt>, <tt>&lt;deque&gt;</tt>, 
<ins><tt>&lt;dynarray&gt;</tt>,</ins>
<tt>&lt;forward_list&gt;</tt>, <tt>&lt;list&gt;</tt>, <tt>&lt;map&gt;</tt>, <tt>&lt;regex&gt;</tt>, 
<tt>&lt;set&gt;</tt>, <tt>&lt;string&gt;</tt>, <tt>&lt;unordered_map&gt;</tt>, <tt>&lt;unordered_set&gt;</tt>, 
and <tt>&lt;vector&gt;</tt>.
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="2286"></a>2286. <tt>stringbuf::underflow()</tt> underspecified</h3>
<p><b>Section:</b> 27.8.2.4 [stringbuf.virtuals] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Sergey Zubkov <b>Opened:</b> 2013-08-29 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 27.8.2.4 [stringbuf.virtuals]/1, <tt>basic_stringbuf::underflow()</tt> is specified to unconditionally 
return <tt>traits::eof()</tt> when a read position is not available.
<p/>
The semantics of <tt>basic_stringbuf</tt> require, and existing libraries implement it so that this function makes 
a read position available if possible to do so, e.g. if some characters were inserted into the stream since the 
last call to <tt>overflow()</tt>, resulting in <tt>pptr() &gt; egptr()</tt>. Compare to the conceptually similar 
D.7.1.3 [depr.strstreambuf.virtuals]/15.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>

<li><p>Change 27.8.2.4 [stringbuf.virtuals] as indicated:</p>

<blockquote>
<pre>
int_type underflow();
</pre><blockquote>
<p>
-1- <i>Returns:</i> If the input sequence has a read position available <ins>or the function makes a read position available 
(as described below)</ins>, returns <tt>traits::to_int_type(*gptr())</tt>. Otherwise, returns <tt>traits::eof()</tt>. Any 
character in the underlying buffer which has been initialized is considered to be part of the input sequence.
<p/>
<ins>-?- The function can make a read position available only if <tt>(mode &amp; ios_base::in) != 0</tt> and if the write 
next pointer <tt>pptr()</tt> is not null and is greater than the current read end pointer <tt>egptr()</tt>. To make a read 
position available, the function alters the read end pointer <tt>egptr()</tt> to equal <tt>pptr()</tt>.</ins>
</p>
</blockquote></blockquote>
</li>

</ol>





<hr>
<h3><a name="2289"></a>2289. <tt>constexpr</tt> guarantees of defaulted functions still insufficient</h3>
<p><b>Section:</b> 20.3.2 [pairs.pair], 20.4.2.1 [tuple.cnstr], 20.12.5 [time.duration] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2013-09-09 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#pairs.pair">issues</a> in [pairs.pair].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
During the acceptance of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3471.html">N3471</a> and
some similar <tt>constexpr</tt> papers, specific wording was added to <tt>pair</tt>, <tt>tuple</tt>, and other templates
that were intended to impose implementation constraints that ensure that the observable <tt>constexpr</tt> "character"
of a defaulted function template is solely determined by the required expressions of the user-provided types when instantiated,
for example:
</p>

<blockquote><p>
The defaulted move and copy constructor, respectively, of pair shall be a <tt>constexpr</tt> function if and only if
all required element-wise initializations for copy and move, respectively, would satisfy the requirements for
a <tt>constexpr</tt> function.
</p></blockquote>

<p>
This wording doesn't require enough, especially since the core language via CWG 1358 does now support <tt>constexpr</tt>
function template instantiations, even if such function cannot appear in a constant expression (as specified in 5.19 [expr.const]) 
or as a constant initializer of that object (as specified in 3.6.2 [basic.start.init]). The wording should be 
improved and should require valid uses in constant expressions and as constant initializers instead.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Change 20.3.2 [pairs.pair] p2 as indicated:</p>

<blockquote>
<p>
-2- <del>The defaulted move and copy constructor, respectively, of pair shall be a <tt>constexpr</tt> function if and only if
all required element-wise initializations for copy and move, respectively, would satisfy the requirements for
a <tt>constexpr</tt> function</del><ins>An invocation of the move or copy constructor of <tt>pair</tt> shall be a constant expression 
(5.19 [expr.const]) if all required element-wise initializations would be constant expressions. An invocation of the 
move or copy constructor of <tt>pair</tt> shall be a constant initializer for that <tt>pair</tt> object (3.6.2 [basic.start.init])
if all required element-wise initializations would be constant initializers for the respective subobjects</ins>.
</p>
</blockquote>
</li>

<li><p>Change 20.4.2.1 [tuple.cnstr] p2 as indicated:</p>

<blockquote>
<p>
-2- <del>The defaulted move and copy constructor, respectively, of <tt>tuple</tt> shall be a <tt>constexpr</tt> function if 
and only if all required element-wise initializations for copy and move, respectively, would satisfy the requirements for
a <tt>constexpr</tt> function. The defaulted move and copy constructor of <tt>tuple&lt;&gt;</tt> shall be <tt>constexpr</tt> 
functions</del><ins>An invocation of the move or copy constructor of <tt>tuple</tt> shall be a constant expression (5.19 [expr.const])
if all required element-wise initializations would be constant expressions. An invocation of the move or copy constructor of 
<tt>tuple</tt> shall be a constant initializer for that <tt>tuple</tt> object (3.6.2 [basic.start.init]) if all 
required element-wise initializations would be constant initializers for the respective subobjects. An invocation of the 
move or copy constructor of <tt>tuple&lt;&gt;</tt> shall be a constant expression, or a constant initializer for that 
<tt>tuple&lt;&gt;</tt> object, respectively, if the function argument would be constant expression</ins>.
</p>
</blockquote>
</li>

<li><p>Change 20.12.5 [time.duration] p7 as indicated:</p>

<blockquote>
<p>
-7- <i>Remarks:</i> <del>The defaulted copy constructor of duration shall be a <tt>constexpr</tt> function if and only if
the required initialization of the member <tt>rep_</tt> for copy and move, respectively, would satisfy the
requirements for a <tt>constexpr</tt> function.</del><ins>An invocation of the copy constructor of <tt>duration</tt> shall 
be a constant expression (5.19 [expr.const]) if the required initialization of the member <tt>rep_</tt> would be a constant expression.
An invocation of the copy constructor of <tt>duration</tt> shall be a constant initializer for that <tt>duration</tt> object 
(3.6.2 [basic.start.init]) if the required initialization of the member <tt>rep_</tt> would be constant initializers 
for this subobject</ins>.
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2290"></a>2290. Top-level "SFINAE"-based constraints should get a separate definition in Clause 17</h3>
<p><b>Section:</b> 20.10 [meta] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2013-09-02 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all other</b> <a href="lwg-index.html#meta">issues</a> in [meta].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current library specification uses at several places wording that is intended to refer to
core language template deduction failure at the top-level of expressions (aka "SFINAE"), for example:
</p>

<blockquote><p>
The expression <tt>declval&lt;T&gt;() = declval&lt;U&gt;()</tt> is well-formed when treated as an unevaluated operand (Clause 5). 
Access checking is performed as if in a context unrelated to <tt>T</tt> and <tt>U</tt>. Only the validity of the immediate context 
of the assignment expression is considered. [<i>Note:</i> The compilation of the expression can result in side effects 
such as the instantiation of class template specializations and function template specializations, the generation of
implicitly-defined functions, and so on. Such side effects are not in the "immediate context" and can result in the program
being ill-formed. &mdash; <i>end note</i>]
</p></blockquote>

<p>
Similar wording can be found in the specification of <tt>result_of</tt>, <tt>is_constructible</tt>, and <tt>is_convertible</tt>,
being added to resolve an NB comment by LWG <a href="lwg-defects.html#1390">1390</a> and <a href="lwg-defects.html#1391">1391</a> through 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">N3142</a>.
<p/>
This wording is necessary to limit speculative compilations needed to implement these traits, but it is also lengthy and repetitive.
</p>

<p><i>[2014-05-19, Daniel suggests a descriptive term]</i></p>

<p>
<b>constrictedly well-formed expression</b>:
<p/>
An expression <em>e</em> depending on a set of types <tt>A1</tt>, ..., <tt>An</tt> which is well-formed when treated as 
an unevaluated operand (Clause 5). Access checking is performed as if in a context unrelated to <tt>A1</tt>, ..., 
<tt>An</tt>. Only the validity of the immediate context of <em>e</em> is considered. [<i>Note:</i> The compilation of 
the expression can result in side effects such as the instantiation of class template specializations and function 
template specializations, the generation of implicitly-defined functions, and so on. Such side effects are not in the 
"immediate context" and can result in the program being ill-formed. &mdash; <i>end note</i>]
</p>

<p><i>[2014-05-20, Richard and Jonathan suggest better terms]</i></p>

<p>
Richard suggested "locally well-formed"
<p/>
Jonathan suggested "contextually well-formed" and then "The expression ... is valid in a contrived argument
deduction context"
</p>

<p><i>[2014-06-07, Daniel comments and improves wording]</i></p>

<p>
The 2014-05-19 suggestion did only apply to expressions, but there are two important examples that are not expressions, but instead
are involving an <em>object definition</em> (<tt>std::is_constructible</tt>) and a <em>function definition</em> 
(<tt>std::is_convertible</tt>), respectively, instead. Therefore I suggest to rephrase the usage of "expression" into "program 
construct" in the definition of Jonathan's suggestion of "valid in a contrived argument deduction context".
<p/>
I would like to point out that given the new definition of "valid in a contrived argument deduction context", there are several other 
places of the Library specification that could take advantage of this wording to improve the existing specification, such as 
20.9.11.2 [func.wrap.func] p2, most functions in 20.7.8.2 [allocator.traits.members], and the <tt>**Insertable</tt>, 
<tt>EmplaceConstructible</tt>, and <tt>Erasable</tt> definitions in 23.2.1 [container.requirements.general], but given that
these are not fully described in terms of the aforementioned wording <em>yet</em>, I would recommend to fix them by a separate issue 
once the committee has agreed on following the suggestion presented by this issue.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Add the following new definition to 17.3 [definitions] as indicated:</p>

<p>
<ins><b>valid in a contrived argument deduction context</b> [defns.valid.contr.context]</ins>
<p/>
<ins>A program construct <em>c</em> depending on a set of types <tt>A1</tt>, ..., <tt>An</tt>, and treated as 
an unevaluated operand (Clause 5) when <em>c</em> is an expression, which is well-formed. 
Access checking is performed as if in a context unrelated to <tt>A1</tt>, ..., <tt>An</tt>. 
Only the validity of the immediate context (14.8.2 [temp.deduct]) of <em>c</em> is considered. 
[<i>Note:</i> The compilation of <em>c</em> can result in side effects such as the instantiation of class template 
specializations and function template specializations, the generation of implicitly-defined functions, and so on. 
Such side effects are not in the "immediate context" and can result in the program being ill-formed. &mdash; 
<i>end note</i>].</ins>
</p>
</li>

<li><p>Change Table 49 ("Type property predicates") as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 49 &mdash; Type property predicates</caption>
<tr>
<th align="center">Template</th>
<th align="center">Condition</th>
<th align="center">Preconditions</th>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>template &lt;class T, class U&gt;<br/>
struct is_assignable;</tt>
</td>

<td>
The expression
<tt>declval&lt;T&gt;() =<br/>
declval&lt;U&gt;()</tt> is <ins>valid in a<br/>
contrived argument deduction context<br/>
([defns.valid.contr.context]) for types<br/>
<tt>T</tt> and <tt>U</tt>.</ins>
<del>well-formed when treated<br/>
as an unevaluated operand<br/>
(Clause 5). Access<br/>
checking is performed as if<br/>
in a context unrelated to <tt>T</tt><br/>
and <tt>U</tt>. Only the validity of<br/>
the immediate context of<br/>
the assignment expression<br/>
is considered. [<i>Note</i>: The<br/>
compilation of the<br/>
expression can result in<br/>
side effects such as the<br/>
instantiation of class<br/>
template specializations<br/>
and function template<br/>
specializations, the<br/>
generation of<br/>
implicitly-defined<br/>
functions, and so on. Such<br/>
side effects are not in the<br/>
"immediate context" and<br/>
can result in the program<br/>
being ill-formed. &mdash; end<br/>
note]</del>
</td>

<td align="center">
[&hellip;]
</td>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>

</table>
</blockquote>

</li>

<li><p>Change 20.10.4.3 [meta.unary.prop] p7 as indicated:</p>

<blockquote><p>
-7- Given the following function prototype:
</p>
<blockquote><pre>
template &lt;class T&gt;
  add_rvalue_reference_t&lt;T&gt; create() noexcept;
</pre></blockquote>
<p>
the predicate condition for a template specialization <tt>is_constructible&lt;T, Args...&gt;</tt> shall be satisfied
if and only if the following variable definition <del>would be well-formed</del> for some invented 
variable <tt>t</tt> <ins>would be valid in a contrived argument deduction context ([defns.valid.contr.context]) for 
types <tt>T</tt> and <tt>Args...</tt></ins>:
</p>
<blockquote><pre>
T t(create&lt;Args&gt;()...);
</pre></blockquote>
<p>
[<i>Note</i>: These tokens are never interpreted as a function declaration. &mdash; <i>end note</i>] <del>Access checking is
performed as if in a context unrelated to <tt>T</tt> and any of the <tt>Args</tt>. Only the validity of the immediate context
of the variable initialization is considered. [<i>Note</i>: The evaluation of the initialization can result in side
effects such as the instantiation of class template specializations and function template specializations, the
generation of implicitly-defined functions, and so on. Such side effects are not in the "immediate context"
and can result in the program being ill-formed. &mdash; <i>end note</i>]</del>
</p>
</blockquote>
</li>

<li><p>Change Table 57 ("Other transformations") as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 57 &mdash; Other transformations</caption>
<tr>
<th align="center">Template</th>
<th align="center">Condition</th>
<th align="center">Comments</th>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>template &lt;class Fn, class... ArgTypes&gt;<br/>
struct result_of&lt;Fn(ArgTypes...)&gt;;</tt>
</td>

<td align="center">
[&hellip;]
</td>

<td>
If the expression<br/>
<tt><i>INVOKE</i>(declval&lt;Fn&gt;(),<br/>
declval&lt;ArgTypes&gt;()...)</tt> is<br/>
<ins>valid in a contrived argument deduction<br/>
context ([defns.valid.contr.context]) for types<br/>
<tt>Fn</tt> and <tt>ArgTypes...</tt></ins>
<del>well<br/>
formed when treated as an<br/>
unevaluated operand (Clause 5)</del>, the<br/>
member typedef type shall name the<br/>
type<br/>
<tt>decltype(<i>INVOKE</i>(declval&lt;Fn&gt;(),<br/>
declval&lt;ArgTypes&gt;()...))</tt>;<br/>
otherwise, there shall be no member<br/>
type. <del>Access checking is performed as<br/>
if in a context unrelated to <tt>Fn</tt> and<br/>
<tt>ArgTypes</tt>. Only the validity of the<br/>
immediate context of the expression is<br/>
considered. [<i>Note</i>: The compilation of<br/>
the expression can result in side<br/>
effects such as the instantiation of<br/>
class template specializations and<br/>
function template specializations, the<br/>
generation of implicitly-defined<br/>
functions, and so on. Such side effects<br/>
are not in the "immediate context"<br/>
and can result in the program being<br/>
ill-formed. &mdash; <i>end note</i>]</del>
</td>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>

</table>
</blockquote>

</li>

<li><p>Change 20.10.6 [meta.rel] p4 as indicated:</p>

<blockquote><p>
-4- Given the following function prototype:
</p>
<blockquote><pre>
template &lt;class T&gt;
  add_rvalue_reference_t&lt;T&gt; create() noexcept;
</pre></blockquote>
<p>
the predicate condition for a template specialization <tt>is_convertible&lt;From, To&gt;</tt> shall be satisfied if and
only if the return expression in the following code would be <del>well-formed</del><ins>valid in a contrived argument 
deduction context ([defns.valid.contr.context]) for types <tt>To</tt> and <tt>From</tt></ins>, including any implicit conversions
to the return type of the function:
</p>
<blockquote><pre>
To test() {
  return create&lt;From&gt;();
}
</pre></blockquote>
<p>
[<i>Note</i>: This requirement gives well defined results for reference types, <tt>void</tt> types, array types, and
function types. &mdash; <i>end note</i>] <del>Access checking is performed as if in a context unrelated to <tt>To</tt> 
and <tt>From</tt>. Only the validity of the immediate context of the expression of the return-statement (including conversions to
the return type) is considered. [<i>Note</i>: The evaluation of the conversion can result in side effects such as
the instantiation of class template specializations and function template specializations, the generation of
implicitly-defined functions, and so on. Such side effects are not in the "immediate context" and can result
in the program being ill-formed. &mdash; <i>end note</i>]</del>
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2292"></a>2292. Find a better phrasing for "shall not participate in overload resolution"</h3>
<p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2013-09-03 <b>Last modified:</b> 2014-02-10</p>
<p><b>View all other</b> <a href="lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The C++14 CD has 25 sections including the phrase "X shall not
participate in overload resolution ...". Most of these uses are double
negatives, which are hard to interpret. "shall not ... unless" tends
to be the easiest to read, since the condition is true when the
function is available, but we also have a lot of "if X is not Y, then
Z shall not participate", which actually means "You can call Z if X is
Y." The current wording is also clumsy and long-winded. We should find
a better and more concise phrasing.
<p/>
As an initial proposal, I'd suggest using "X is enabled if and only if Y" in prose
and adding an "<i>Enabled If:</i> ..." element to 17.5.1.4 [structure.specifications].
<p/>
Daniel:
<p/>
I suggest to name this new specification element for 17.5.1.4 [structure.specifications]
as "<i>Template Constraints:</i>" instead, because the mentioned wording form was intentionally provided 
starting with LWG <a href="lwg-defects.html#1237">1237</a> to give implementations more freedom to realize the 
concrete constraints. Instead of the original <tt>std::enable_if</tt>-based specifications
we can use better forms of "SFINAE" constraints today and it eases the path to possible language-based
constraints in the future.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2294"></a>2294. <tt>&lt;cstdlib&gt;</tt> should declare <tt>abs(double)</tt></h3>
<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2013-09-04 <b>Last modified:</b> 2014-02-13</p>
<p><b>View other</b> <a href="lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
<p><b>View all other</b> <a href="lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
&hellip; and <tt>abs(float)</tt> and <tt>abs(long double)</tt>. And <tt>&lt;cmath&gt;</tt> should declare 
<tt>abs(int)</tt>, <tt>abs(long)</tt>, and <tt>abs(long long)</tt>.
<p/>
As things currently stand, this program is illegal:
</p>
<blockquote><pre>
#include &lt;cstdlib&gt;

int main() {
  double d = -1.23;
  double dd = std::abs(d);
  return 0;
}
</pre></blockquote>
<p>
The call is ambiguous because of the various integer overloads, that's because <tt>&lt;cstdlib&gt;</tt> provides 
<tt>abs(int)</tt> but not <tt>abs(double)</tt>.
<p/>
This lead one commenter on Stackoverflow to state that <tt>abs</tt> is dangerous, and to recommend using <tt>fabs</tt> instead.
<p/>
In general, it makes sense to declare overloaded functions that take user-defined types in the same header as the 
definition of the user-defined types; it isn't necessary to declare all of the overloads in the same place. But 
here we're not dealing with any user-defined types; we're dealing with builtin types, which are always defined; 
all of the overloads should be defined in the same place, to avoid mysterious problems like the one in the code above.
<p/>
The standard library has six overloads for <tt>abs</tt>:
</p>
<blockquote><pre>
int abs(int);  // &lt;cstdlib&gt;
long abs(long); // &lt;cstdlib&gt;
long long abs(long long); // &lt;cstdlib&gt;

float abs(float); // &lt;cmath&gt;
double abs(double); // &lt;cmath&gt;
long double abs(long double); // &lt;cmath&gt;
</pre></blockquote>
<p>
These should all be declared in both headers.
<p/>
I have no opinion on <tt>&lt;stdlib.h&gt;</tt> and <tt>&lt;math.h&gt;</tt>.
</p>

<p><i>[2013-09 Chicago]</i></p>

<p>
This issue is related to LWG <a href="lwg-active.html#2192">2192</a>
<p/>
Move to open
</p>

<p><i>[2014-02-13 Issaquah &mdash; Nicolai Josuttis suggest wording]</i></p>




<p><b>Proposed resolution:</b></p>

<ol>
<li><p>Edit 26.8 [c.math] after p7 as indicated:</p>

<blockquote><p>
-6- In addition to the <tt>int</tt> versions of certain math functions in <tt>&lt;cstdlib&gt;</tt>, C++ adds <tt>long</tt> and <tt>long long</tt>
overloaded versions of these functions, with the same semantics.
<p/>
-7- The added signatures are:
</p>
<blockquote><pre>
long abs(long);                    <i>// labs()</i>
long long abs(long long);          <i>// llabs()</i>
ldiv_t div(long, long);            <i>// ldiv()</i>
lldiv_t div(long long, long long); <i>// lldiv()</i>
</pre></blockquote>
<p>
<ins>-?- To avoid ambiguities, C++ also adds the following overloads of <tt>abs()</tt> to <tt>&lt;cstdlib&gt;</tt>,
with the semantics defined in <tt>&lt;cmath&gt;</tt>:</ins>
</p>
<blockquote><pre>
<ins>float abs(float);
double abs(double);
long double abs(long double);</ins>
</pre></blockquote>
<p>
<ins>-?- To avoid ambiguities, C++ also adds the following overloads of <tt>abs()</tt> to <tt>&lt;cmath&gt;</tt>,
with the semantics defined in <tt>&lt;cstdlib&gt;</tt>:</ins>
</p>
<blockquote><pre>
<ins>int abs(int);
long abs(long);
long long abs(long long);</ins>
</pre></blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2295"></a>2295. Locale name when the provided <tt>Facet</tt> is a <tt>nullptr</tt></h3>
<p><b>Section:</b> 22.3.1.2 [locale.cons] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Juan Soulie <b>Opened:</b> 2013-09-04 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
22.3.1.2 [locale.cons] p14 ends with:
</p>
<blockquote><p>
"[&hellip;] If <tt>f</tt> is null, the resulting object is a copy of <tt>other</tt>."
</p></blockquote>
<p>
but the next line p15 says: 
</p>
<blockquote><p>
"<i>Remarks:</i> The resulting locale has no name."
</p></blockquote>
<p>
But both can't be true when <tt>other</tt> has a name and <tt>f</tt> is null.
<p/>
I've tried it on two implementations (MSVC,GCC) and they are inconsistent with each other on this.
</p>
<p>
Daniel Kr&uuml;gler:
<p/>
As currently written, the <i>Remarks</i> element applies unconditionally for all cases and thus should
"win". The question arises whether the introduction of this element by LWG <a href="lwg-closed.html#424">424</a> had actually intended
to change the previous <i>Note</i> to a <i>Remarks</i> element. In either case the wording should be improved
to clarify this special case.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2296"></a>2296. <tt>std::addressof</tt> should be <tt>constexpr</tt></h3>
<p><b>Section:</b> 20.7.12.1 [specialized.addressof] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daryle Walker <b>Opened:</b> 2013-09-08 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all other</b> <a href="lwg-index.html#specialized.addressof">issues</a> in [specialized.addressof].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I'm writing a function that needs to be <tt>constexpr</tt> and I wanted to take the address of its input. I was 
thinking of using <tt>std::addressof</tt> to be safe, but it isn't currently <tt>constexpr</tt>. A 
<a href="http://en.cppreference.com/w/cpp/memory/addressof">sample implementation</a> 
couldn't be <tt>constexpr</tt> under the C++11 rules, though.
<p/>
Daniel Kr&uuml;gler:
<p/>
Indeed the core language clarified by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1312">CWG 1312</a> 
and by <a href="www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1384">CWG 1384</a>, that such emulations of <tt>std::addressof</tt>
implementations are not valid in constant expressions, therefore it seems more like a defect than a feature request to ask for 
the guarantee that <tt>std::addressof</tt> is a <tt>constexpr</tt> function. It should be added that a similar requirement
already exists for <tt>offsetof</tt> indirectly via the C99 standard as of 7.17 p3:
</p>
<blockquote>
<p>
The macros are [&hellip;]
</p>
<blockquote><pre>
offsetof(type, member-designator)
</pre></blockquote>
<p>
which expands to an integer constant expression that has type <tt>size_t</tt> [&hellip;]
</p>
</blockquote>

<p>
combined with the noted property in C++11 that:
</p>

<blockquote><p>
"<tt>offsetof</tt> is required to work as specified even if unary <tt>operator&amp;</tt> 
is overloaded for any of the types involved"
</p></blockquote>

<p>
Therefore implementations should already be able without heroic efforts to realize this functionality by
some intrinsic. The wording needs at least to ensure that for any lvalue core constant expression <tt><em>e</em></tt>
the expression <tt>std::addressof(<em>e</em>)</tt> is a core constant expression.
</p>

<p><i>[2013-09 Chicago]</i></p>

<p>
</p>

<p><i>[2014-06-08, Daniel improves wording]</i></p>

<p>
It has been ensured that the wording is in sync with the recent working paper and the usage of "any" has been
improved to say "every" instead (the fix is similar to that applied by LWG <a href="lwg-defects.html#2150">2150</a>).
</p>

<p>
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<ol>
<li><p>Change header <tt>&lt;memory&gt;</tt> synopsis, 20.7.2 [memory.syn] as indicated:</p>

<blockquote><pre>
namespace std {
  [&hellip;]
  <i>// 20.7.12 [specialized.algorithms], specialized algorithms:</i>
  template &lt;class T&gt; <ins>constexpr</ins> T* addressof(T&amp; r) noexcept;
  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Change 20.7.12.1 [specialized.addressof] as indicated:</p>

<blockquote><pre>
template &lt;class T&gt; <ins>constexpr</ins> T* addressof(T&amp; r) noexcept;
</pre><blockquote>
<p>
-1- <i>Returns:</i> The actual address of the object or function referenced by <tt>r</tt>, even in the presence of an
overloaded <tt>operator&amp;</tt>.
<p/>
<ins>-?- <i>Remarks:</i> For every lvalue core constant expression <tt><em>e</em></tt> (5.19 [expr.const]), the expression 
<tt>std::addressof(<em>e</em>)</tt> is a core constant expression.</ins>
</p>
</blockquote>
</blockquote>

</li>
</ol>
</blockquote>

<p><i>[2014-06-09, further improvements]</i></p>

<p>
A new wording form is now used similar to the approach used by LWG <a href="lwg-active.html#2234">2234</a>, which
is a stricter way to impose the necessary implementation requirements.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Introduce the following new definition to the existing list in 17.3 [definitions]: [<i>Drafting note</i>:
If LWG <a href="lwg-active.html#2234">2234</a> is accepted before this issue, the accepted wording for the new definition should be used instead
&mdash; <i>end drafting note</i>]</p>

<blockquote>
<p>
<strong>constant subexpression</strong> [defns.const.subexpr]
<p/>
an expression whose evaluation as subexpression of a <em>conditional-expression</em> <em>CE</em> (5.16 [expr.cond]) 
would not prevent <em>CE</em> from being a core constant expression (5.19 [expr.const]).
</p>
</blockquote>
</li>

<li><p>Change header <tt>&lt;memory&gt;</tt> synopsis, 20.7.2 [memory.syn] as indicated:</p>

<blockquote><pre>
namespace std {
  [&hellip;]
  <i>// 20.7.12 [specialized.algorithms], specialized algorithms:</i>
  template &lt;class T&gt; <ins>constexpr</ins> T* addressof(T&amp; r) noexcept;
  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Change 20.7.12.1 [specialized.addressof] as indicated:</p>

<blockquote><pre>
template &lt;class T&gt; <ins>constexpr</ins> T* addressof(T&amp; r) noexcept;
</pre><blockquote>
<p>
-1- <i>Returns:</i> The actual address of the object or function referenced by <tt>r</tt>, even in the presence of an
overloaded <tt>operator&amp;</tt>.
<p/>
<ins>-?- <i>Remarks:</i> An expression <tt>std::addressof(<em>E</em>)</tt> is a constant subexpression ( [defns.const.subexpr]), 
if <tt><em>E</em></tt> is an lvalue constant subexpression.</ins>
</p>
</blockquote>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="2302"></a>2302. Passing null pointer to placement new</h3>
<p><b>Section:</b> 18.6.1.3 [new.delete.placement] <b>Status:</b> <a href="lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> Marc Glisse <b>Opened:</b> 2013-09-12 <b>Last modified:</b> 2014-05-02</p>
<p><b>View other</b> <a href="lwg-index-open.html#new.delete.placement">active issues</a> in [new.delete.placement].</p>
<p><b>View all other</b> <a href="lwg-index.html#new.delete.placement">issues</a> in [new.delete.placement].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively NAD">Tentatively NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Based on <a href="http://stackoverflow.com/questions/17571103/passing-null-pointer-to-placement-new">this discussion</a> 
and as discussed in <a href="http://accu.org/cgi-bin/wg21/message?wg=core&amp;msg=23998">c++std-core-23998</a> and
<a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=34442">c++std-lib-34442</a>, calling placement new currently forces the 
compiler to check if the pointer is null before initializing the object (a non-negligible cost). It seems many people were not 
aware of this and they consider it a user error to pass a null pointer to it.
<p/>
Proposed resolution: for <tt>operator new</tt> and <tt>operator new[]</tt>, add:
</p>
<blockquote><p>
<i>Requires:</i> <tt>ptr</tt> shall not be a null pointer.
</p></blockquote>

<p><i>[2014-02-15 post-Issaquah session : move to Tentatively NAD]</i></p>

<p>
AJM to supply the rationale...
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Change 18.6.1.3 [new.delete.placement] as indicated:</p>

<blockquote>
<pre>
void* operator new(std::size_t size, void* ptr) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Requires:</i> <tt>ptr</tt> shall not be a null pointer.</ins>
<p/>
-2- <i>Returns:</i> <tt>ptr</tt>.
<p/>
-3- <i>Remarks:</i> Intentionally performs no other action.
<p/>
-4- [<i>Example:</i> This can be useful for constructing an object at a known address:
</p><blockquote><pre>
void* place = operator new(sizeof(Something));
Something* p = new (place) Something();
</pre></blockquote>
<p>
&mdash; <i>end example</i>]
</p>
</blockquote>
</blockquote>
<blockquote>
<pre>
void* operator new[](std::size_t size, void* ptr) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Requires:</i> <tt>ptr</tt> shall not be a null pointer.</ins>
<p/>
-5- <i>Returns:</i> <tt>ptr</tt>.
<p/>
-6- <i>Remarks:</i> Intentionally performs no other action.
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2303"></a>2303. Explicit instantiation of <tt>std::vector&lt;UserType&gt;</tt> broken?</h3>
<p><b>Section:</b> 18.6.1.3 [new.delete.placement] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2013-09-18 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#new.delete.placement">active issues</a> in [new.delete.placement].</p>
<p><b>View all other</b> <a href="lwg-index.html#new.delete.placement">issues</a> in [new.delete.placement].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The library gives explicit permission in 17.6.4.2.1 [namespace.std] p2 that user code may explicitly instantiate
a library template provided that the instantiations depend on at least one user-defined type:
</p>

<blockquote><p>
A program may explicitly instantiate a template defined in the standard library only if the declaration
depends on the name of a user-defined type and the instantiation meets the standard library requirements
for the original template.
</p></blockquote>

<p>
But it seems that the C++11 library is not specified in a way that guarantees such an instantiation to be well-formed
if the minimum requirements of the library is not satisfied. 
<p/>
For example, in general, the first template parameter of <tt>std::vector</tt> is not required to be 
<tt>DefaultConstructible</tt> in general, but due to the split of the single C++03 member function
with default argument
</p>
<blockquote><pre>
void resize(size_type sz, T c = T());
</pre></blockquote>
<p>
into
</p>
<blockquote><pre>
void resize(size_type sz);
void resize(size_type sz, const T&amp; c);
</pre></blockquote>
<p>
the effect is now that for a type <tt>ND</tt> that is not <tt>DefaultConstructible</tt>, such as
</p>
<blockquote><pre>
struct NP { 
  NP(int); 
};
</pre></blockquote>
<p>
the explicit instantiation of <tt>std::vector&lt;ND&gt;</tt> is no longer well-formed, because the attempt to
instantiate the single-argument overload of <tt>resize</tt> cannot not succeed, because this function imposes
the <tt>DefaultInsertable</tt> requirements and given the default allocator this effectively requires
<tt>DefaultConstructible</tt>.
</p>
<p>
But <tt>DefaultConstructible</tt> is not the only point, what about <tt>CopyConstructible</tt> versus
<tt>MoveConstructible</tt> alone? It turns out that currently the second <tt>resize</tt> overload
would fail during an explicit instantiation for a type like
</p>
<blockquote><pre>
struct MO { 
  MO() = default; 
  MO(MO&amp;&amp;) = default; 
};
</pre></blockquote>
<p>
because it imposes <tt>CopyInsertable</tt> requirements that end up being equivalent to the <tt>CopyConstructible</tt>
requirements for the default allocator.
<p/>
Technically a library can solve these issues: For special member functions by defining them in some base class, for others
by transforming them effectively into a function template due to the great feature of default template arguments for
function templates (At the very moment the validity of the latter approach depends on a resolution of core language issue
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1635">CWG 1635</a>, though). E.g. the here mentioned 
<tt>resize</tt> functions of <tt>std::vector</tt> could be prevented from instantiation by defining them like this 
with an implementation:
</p>
<blockquote><pre>
template&lt;class = void&gt;
void resize(size_type sz) { [&hellip;] }
template&lt;class = void&gt;
void resize(size_type sz, const T&amp; c) { [&hellip;] }
</pre></blockquote>
<p>
In this case, these functions could also be defined in a base class, but the latter approach won't work in all cases.
<p/>
Basically such an implementation is required to constrain all member functions that are not covered by the general
requirements imposed on the actual library template parameters. I tested three different C++11 library implementations
and but none could instantiate for example <tt>std::list</tt>, <tt>std::vector</tt>, or <tt>std::deque</tt> with
value types that are not <tt>DefaultConstructible</tt> or only <tt>MoveConstructible</tt>. 
<p/>

<p/>
This issue is raised to clarify the current situation in regard to the actual requirements imposed on user-provided
types that are used to explicitly instantiate Library-provided templates. For example, the current Container requirements
impose very little requirements on the actual value type and it is unclear to which extend library implementations have
to respect that. 
<p/>
The minimum solution of this issue should be to at least realize that there is no fundamental requirement on 
<tt>DefaultConstructible</tt> for value types of library containers, because we have since C++03 the general
statement of 17.6.3.1 [utility.arg.requirements] ("In general, a default constructor is not required.").
It is unclear whether <tt>CopyConstructible</tt> should be required for an explicit instantiation request, but
given the careful introduction of move operations in the library it would seem astonishing that a
<tt>MoveConstructible</tt> type wouldn't suffice for value types of the container types.
<p/>
In any case I can envision at least two approaches to solve this issue:
</p>
<ol>
<li>
<p>
As indicated in LWG <a href="lwg-active.html#2292">2292</a>, those function could get an explicit "<i>Template Constraints:</i>"
element, albeit this promises more than needed to solve this issue.
</p>
</li>
<li>
<p>
The library could introduce a completely new element form, such as "<i>Instantiation Constraints:</i>" that
would handle this situation for explicit instantiation situations. This would allow for simpler techniques
to solve the issue when explicit instantiation is required compared to the first bullet, because it would not 
(necessarily) guarantee SFINAE-friendly expression-wellformedness, such as inspecting the expression 
<tt>std::declval&lt;std::vector&lt;ND&gt;&amp;&gt;.resize(0)</tt> in an unevaluated context.
</p>
</li>
</ol>

<p>
It should be noted that the 2013-08-27 comment to LWG <a href="lwg-defects.html#2193">2193</a> could be resolved by a similar solution
as indicated in this issue here.
</p>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2307"></a>2307. Should the Standard Library use <tt>explicit</tt> only when necessary?</h3>
<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Zhihao Yuan <b>Opened:</b> 2013-09-26 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#containers">issues</a> in [containers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="lwg-defects.html#2193">2193</a> yields <tt>explicit</tt> for default ctors to allow <tt>{}</tt>, but not for
all cases of uniform initialization. For example:
</p>
<blockquote><pre>
explicit vector(size_type count, const Allocator&amp; alloc = Allocator());
</pre></blockquote>
<p>
This prevents <tt>{n, alloc()}</tt>. Although this use is relatively rare,
but the behavior is inconsistent with that of
</p>
<blockquote><pre>
vector(size_type count, const T&amp; value, const Allocator&amp; alloc = Allocator());
</pre></blockquote>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2309"></a>2309. <tt>mutex::lock()</tt> should not throw <tt>device_or_resource_busy</tt></h3>
<p><b>Section:</b> 30.4.1.2 [thread.mutex.requirements.mutex] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2013-09-27 <b>Last modified:</b> 2014-06-19</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.mutex.requirements.mutex">issues</a> in [thread.mutex.requirements.mutex].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As discussed during the Chicago meeting in 
<a href="http://wiki.edg.com/twiki/bin/view/Wg21chicago2013/ThursdayMorningMinutes#LWG_2135_revisited">SG1</a>
the only reasonable reasons for throwing <tt>device_or_resource_busy</tt> seem to be:
</p>
<ul>
<li><p>
The thread currently already holds the mutex, the mutex is not recursive, and the implementation detects this.
In this case <tt>resource_deadlock_would_occur</tt> should be thrown.
</p></li>
<li><p>
Priority reasons. At least <tt>std::mutex</tt> (and possibly all standard mutex types)
should not be setup this way, otherwise we have real problems with <tt>condition_variable::wait()</tt>.
</p></li>
</ul>

<p><i>[2014-06-17 Rapperswil]</i></p>

<p>
Detlef provides wording
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 30.4.1.2 [thread.mutex.requirements.mutex] as indicated:</p>

<blockquote><p>
-13- <i>Error conditions</i>:
</p>
<ul>
<li><p><tt>operation_not_permitted</tt> &mdash; if the thread does not have the privilege to perform the operation.</p></li>
<li><p><tt>resource_deadlock_would_occur</tt> &mdash; if the implementation detects that a deadlock would occur.</p></li>
<li><p><del><tt>device_or_resource_busy</tt> &mdash; if the mutex is already locked and blocking is not possible.</del></p></li>
</ul>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2310"></a>2310. Public <em>exposition only</em> member in <tt>std::array</tt></h3>
<p><b>Section:</b> 23.3.2.1 [array.overview] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-09-30 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
23.3.2.1 [array.overview] shows <tt>std::array</tt> with an "exposition only" data member, <tt>elems</tt>.
<p/>
The wording in 17.5.2.3 [objects.within.classes] that defines how
"exposition only" is used says it applies to private members, but
<tt>std::array::elems</tt> (or its equivalent) must be public in order for
<tt>std::array</tt> to be an aggregate.
<p/>
If the intention is that <tt>std::array::elems</tt> places requirements on the
implementation to provide "equivalent external behavior" to a public
array member, then 17.5.2.3 [objects.within.classes] needs to cover public
members too, or some other form should be used in 23.3.2.1 [array.overview].
</p>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2312"></a>2312. <tt>tuple</tt>'s constructor constraints need to be phrased more precisely</h3>
<p><b>Section:</b> 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider the following code:
</p>
<blockquote><pre>
void meow(tuple&lt;long, long&gt;) { puts("Two"); }

void meow(tuple&lt;long, long, long&gt;) { puts("Three"); }

tuple&lt;int, int, int&gt; t(0, 0, 0);

meow(t);
</pre></blockquote>
<p>
This should compile and print "Three" because <tt>tuple&lt;long, long&gt;</tt>'s constructor from 
<tt>const tuple&lt;int, int, int&gt;&amp;</tt> should remove itself from overload resolution.  
Implementations sensibly do this, but the Standard doesn't actually say it!
<p/>
In this case, <tt>Types</tt> is "<tt>long, long</tt>" and <tt>UTypes</tt> is "<tt>int, int, int</tt>". 20.4.2.1 [tuple.cnstr]/3 
says "let <tt>i</tt> be in the range <tt>[0,sizeof...(Types))</tt> in order", which is <tt>[0, 2)</tt>.  Then /17 says 
"<i>Remark:</i> This constructor shall not participate in overload resolution unless <tt>const Ui&amp;</tt> is implicitly 
convertible to <tt>Ti</tt> for all <tt>i</tt>." Interpreted literally, this is true!  /15 says 
"<i>Requires:</i> <tt>sizeof...(Types) == sizeof...(UTypes)</tt>." but requiring the sizes to be identical doesn't help.  
Only the special phrase "shall not participate in overload resolution unless" mandates SFINAE/<tt>enable_if</tt> machinery.
<p/>
The wording that we need is almost available in the <i>Requires</i> paragraphs, except that the <i>Requires</i> paragraphs say 
"<tt>is_constructible</tt>" while the Remark paragraphs say "is implicitly convertible", which is the correct thing for the SFINAE 
constraints to check. My proposed resolution is to unify the <i>Requires</i> and <i>Remark</i> paragraphs, after which there 
will be no need for <i>Requires</i> (when a constructor participates in overload resolution if and only if <tt>X</tt> is true, 
then there's no need for it to <i>Require</i> that <tt>X</tt> is true).
<p/>
Note: 20.10.4.3 [meta.unary.prop]/6 specifies <tt>is_constructible&lt;To, From&gt;</tt> and 20.10.6 [meta.rel]/4 specifies 
<tt>is_convertible&lt;From, To&gt;</tt>. Both are specified in terms of 
"<tt>template &lt;class T&gt; typename add_rvalue_reference&lt;T&gt;::type create();</tt>".  
Therefore, passing <tt>From</tt> and <tt>From&amp;&amp;</tt> is equivalent, regardless of whether <tt>From</tt> is an object type, 
an lvalue reference, or an rvalue reference.
<p/>
Also note that 20.4.2.1 [tuple.cnstr]/3 defines <tt>T0</tt> and <tt>T1</tt> so we don't need to repeat their definitions.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Edit 20.4.2.1 [tuple.cnstr] as indicated:</p>

<blockquote><pre>
template &lt;class... UTypes&gt;
  explicit constexpr tuple(UTypes&amp;&amp;... u);
</pre><blockquote>
<p>
<del>-8- <i>Requires:</i> <tt>sizeof...(Types) == sizeof...(UTypes)</tt>. <tt>is_constructible&lt;Ti, Ui&amp;&amp;&gt;::value</tt> is true
for all <i>i</i>.</del>
<p/>
[&hellip;]
<p/>
-10- <i>Remark:</i> This constructor shall not participate in overload resolution unless <del>each type in <tt>UTypes</tt> is
implicitly convertible to its corresponding type in <tt>Types</tt></del><ins><tt>sizeof...(Types) == sizeof...(UTypes)</tt> and 
both <tt>is_constructible&lt;Ti, Ui&gt;::value</tt> and <tt>is_convertible&lt;Ui, Ti&gt;::value</tt> are true for all <i>i</i></ins>.
</p>
</blockquote>
<p>
[&hellip;]
</p>
</blockquote>
<blockquote><pre>
template &lt;class... UTypes&gt;
  constexpr tuple(const tuple&lt;UTypes...&gt;&amp; u);
</pre><blockquote>
<p>
<del>-15- <i>Requires:</i> <tt>sizeof...(Types) == sizeof...(UTypes)</tt>. <tt>is_constructible&lt;Ti, const Ui&amp;&gt;::value</tt> is true
for all <i>i</i>.</del>
<p/>
[&hellip;]
<p/>
-17- <i>Remark:</i> This constructor shall not participate in overload resolution unless <del><tt>const Ui&amp;</tt> is implicitly
convertible to <tt>Ti</tt></del><ins><tt>sizeof...(Types) == sizeof...(UTypes)</tt> and 
both <tt>is_constructible&lt;Ti, const Ui&amp;&gt;::value</tt> and <tt>is_convertible&lt;const Ui&amp;, Ti&gt;::value</tt> are 
true</ins> for all <i>i</i>.
</p>
</blockquote>
</blockquote>
<blockquote><pre>
template &lt;class... UTypes&gt;
  constexpr tuple(tuple&lt;UTypes...&gt;&amp;&amp; u);
</pre><blockquote>
<p>
<del>-18- <i>Requires:</i> <tt>sizeof...(Types) == sizeof...(UTypes)</tt>. <tt>is_constructible&lt;Ti, Ui&amp;&amp;&gt;::value</tt> is true
for all <i>i</i>.</del>
<p/>
[&hellip;]
<p/>
-20- <i>Remark:</i> This constructor shall not participate in overload resolution unless <del>each type in <tt>UTypes</tt> is
implicitly convertible to its corresponding type in <tt>Types</tt></del><ins><tt>sizeof...(Types) == sizeof...(UTypes)</tt> and 
both <tt>is_constructible&lt;Ti, Ui&gt;::value</tt> and <tt>is_convertible&lt;Ui, Ti&gt;::value</tt> are true for all <i>i</i></ins>.
</p>
</blockquote>
</blockquote>
<blockquote><pre>
template &lt;class U1, class U2&gt; constexpr tuple(const pair&lt;U1, U2&gt;&amp; u);
</pre><blockquote>
<p>
<del>-21- <i>Requires:</i> <tt>sizeof...(Types) == 2</tt>. <tt>is_constructible&lt;T0, const U1&amp;&gt;::value</tt> is true for the first
type <tt>T0</tt> in Types and <tt>is_constructible&lt;T1, const U2&amp;&gt;::value</tt> is true for the second type <tt>T1</tt> in
<tt>Types</tt>.</del>
<p/>
[&hellip;]
<p/>
-23- <i>Remark:</i> This constructor shall not participate in overload resolution unless <del><tt>const U1&amp;</tt> is implicitly
convertible to <tt>T0</tt> and <tt>const U2&amp;</tt> is implicitly convertible to <tt>T1</tt></del><ins><tt>sizeof...(Types) == 2 
&amp;&amp; is_constructible&lt;T0, const U1&amp;&gt;::value &amp;&amp; is_constructible&lt;T1, const U2&amp;&gt;::value &amp;&amp; 
is_convertible&lt;const U1&amp;, T0&gt;::value &amp;&amp; is_convertible&lt;const U2&amp;, T1&gt;::value</tt> is true</ins>.
</p>
</blockquote>
</blockquote>
<blockquote><pre>
template &lt;class U1, class U2&gt; constexpr tuple(pair&lt;U1, U2&gt;&amp;&amp; u);
</pre><blockquote>
<p>
<del>-24- <i>Requires:</i> <tt>sizeof...(Types) == 2</tt>. <tt>is_constructible&lt;T0, U1&amp;&amp;&gt;::value</tt> is true for the first
type <tt>T0</tt> in Types and <tt>is_constructible&lt;T1, U2&amp;&amp;&gt;::value</tt> is true for the second type <tt>T1</tt> in
<tt>Types</tt>.</del>
<p/>
[&hellip;]
<p/>
-26- <i>Remark:</i> This constructor shall not participate in overload resolution unless <del><tt>U1</tt> is implicitly convertible
to <tt>T0</tt> and <tt>U2</tt> is implicitly convertible to <tt>T1</tt></del><ins><tt>sizeof...(Types) == 2
&amp;&amp; is_constructible&lt;T0, U1&gt;::value &amp;&amp; is_constructible&lt;T1, U2&gt;::value &amp;&amp; 
is_convertible&lt;U1, T0&gt;::value &amp;&amp; is_convertible&lt;U2, T1&gt;::value</tt> is true</ins>.
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2318"></a>2318. <tt>basic_string</tt>'s wording has confusing relics from the copy-on-write era</h3>
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
<p><b>View all other</b> <a href="lwg-index.html#basic.string">issues</a> in [basic.string].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
21.4.4 [string.capacity]/8 specifies <tt>basic_string::resize(n, c)</tt> with:
</p>
<blockquote><p>
<i>Effects:</i> Alters the length of the string designated by <tt>*this</tt> as follows:
</p>
<ul>
<li><p>
If <tt>n &lt;= size()</tt>, the function replaces the string designated by <tt>*this</tt> with a string of length <tt>n</tt> whose 
elements are a copy of the initial elements of the original string designated by <tt>*this</tt>.
</p>
</li>
<li><p>
If <tt>n &gt; size()</tt>, the function replaces the string designated by <tt>*this</tt> with a string of length <tt>n</tt> whose 
first <tt>size()</tt> elements are a copy of the original string designated by <tt>*this</tt>, and whose remaining elements are all 
initialized to <tt>c</tt>.
</p>
</li>
</ul>
</blockquote>
<p>
This wording is a relic of the copy-on-write era. In addition to being extremely confusing, it has undesirable implications.  
Saying "replaces the string designated by <tt>*this</tt> with a string of length <tt>n</tt> whose elements are a copy" suggests 
that the trimming case can reallocate. Reallocation during trimming should be forbidden, like <tt>vector</tt>.
<p/>
At least 7 paragraphs are affected: 21.4.4 [string.capacity]/8, 21.4.6.2 [string::append]/9, 
21.4.6.3 [string::assign]/3 and /10, 21.4.6.4 [string::insert]/11, 21.4.6.5 [string::erase]/4, and 
21.4.6.6 [string::replace]/11 say "replaces the string [designated/controlled] by <tt>*this</tt>". (21.4.6.7 [string::copy]/3 
is different &mdash; it "replaces the string designated by <tt>s</tt>".)
<p/>
Of the affected paragraphs, <tt>resize()</tt> and <tt>erase()</tt> are the most important to fix because they should forbid 
reallocation during trimming.
</p>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2319"></a>2319. <tt>basic_string</tt>'s move constructor should not be <tt>noexcept</tt></h3>
<p><b>Section:</b> 21.4.2 [string.cons] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-03-03</p>
<p><b>View other</b> <a href="lwg-index-open.html#string.cons">active issues</a> in [string.cons].</p>
<p><b>View all other</b> <a href="lwg-index.html#string.cons">issues</a> in [string.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In debugging implementations, containers (including <tt>basic_string</tt>) may need to own dynamically allocated helper objects at 
all times, including in their default-constructed and moved-from states. This means that their default constructors and move 
constructors may throw exceptions. Therefore, the Standard should not mark them as <tt>noexcept</tt>. (Other implementations will 
still be permitted to add <tt>noexcept</tt>.)
</p>

<p><i>[2014-02, Issaquah : move to Ready]</i></p>

<p>
The issue discussion was highly controversial: The arguments in favour was that implementations exist that always need to allocate
memory even for the move operations (similar as for some other containers) and that this cleans up an inconsistency between <tt>std::string</tt>
and other container types. Counter arguments were that potentially throwing move operations reduce much of the advantages of move-support,
e.g. in <tt>vector&lt;string&gt;</tt>.
</p>
<p>
straw poll: accept wording in the issue<br/>
SF 4 WF 4 N 0 WA 1 SA 1 
</p>
<p>
straw poll: 14 or 17?<br/>
C++14: 4 C++17: 4 
</p>
<p>
Move to Ready for C++17, as too close to 14 DIS without strong consensus.
</p>
<p>
It was suggested to introduce a special library vocabulary that specifies a "normative encouragement to not throw exceptions" for 
functions like these. 
</p>
<p>
NJ: I offer to write a proposal to add encouragement for not throwing ... "<tt>noexcept</tt> in italics means should not throw" 
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>In 21.4 [basic.string]/5, class template <tt>basic_string</tt> synopsis, and 21.4.2 [string.cons]/2 
change as indicated:</p>

<blockquote><pre>
basic_string(basic_string&amp;&amp; str) <del>noexcept</del>;
</pre></blockquote>
</li>

<li><p>Edit 21.4.2 [string.cons]/17 as indicated:</p>

<blockquote><pre>
basic_string(const basic_string&amp; str, const Allocator&amp; alloc);
basic_string(basic_string&amp;&amp; str, const Allocator&amp; alloc);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
<del>-17- <i>Throws:</i> The second form throws nothing if <tt>alloc == str.get_allocator()</tt>.</del>.
</p>
</blockquote>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="2321"></a>2321. Moving containers should (usually) be required to preserve iterators</h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-02-14</p>
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
23.2.1 [container.requirements.general]/10 says that unless otherwise specified, "no <tt>swap()</tt> function invalidates 
any references, pointers, or iterators referring to the elements of the containers being swapped. [<i>Note:</i> The <tt>end()</tt> 
iterator does not refer to any element, so it may be invalidated. &mdash; <i>end note</i>]". However, move constructors and move 
assignment operators aren't given similar invalidation guarantees. The guarantees need several exceptions, so I do not believe 
that blanket language like /11 "Unless otherwise specified (either explicitly or by defining a function in terms of other functions), 
invoking a container member function or passing a container as an argument to a library function shall not invalidate iterators to, 
or change the values of, objects within that container." is applicable.
</p>

<p><i>[2014-02-13 Issaquah]</i></p>

<p>
General agreeement on intent, several wording nits and additional paragraphs to hit.
</p>

<p>
STL to provide updated wording.  Move to Open.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>In 23.2.1 [container.requirements.general]/10 change as indicated:</p>

<blockquote><p>
-10- Unless otherwise specified (see 23.2.4.1, 23.2.5.1, 23.3.3.4, and 23.3.7.5) all container types defined in this
Clause meet the following additional requirements:
</p>
<ul>
<li><p>
[&hellip;]
</p></li>
<li><p>
no copy constructor or assignment operator of a returned iterator throws an exception.
</p></li>
<li><p>
<ins>no move constructor (or move assignment operator when 
<tt>allocator_traits&lt;allocator_type&gt;::propagate_on_container_move_assignment::value</tt> is true) of a container 
(except for <tt>array</tt>) invalidates any references, pointers, or iterators referring to the elements of the source container. 
[<i>Note:</i> The <tt>end()</tt> iterator does not refer to any element, so it may be invalidated. &mdash; <i>end note</i>]</ins>
</p></li>
<li><p>
no <tt>swap()</tt> function throws an exception.
</p></li>
<li><p>
no <tt>swap()</tt> function invalidates any references, pointers, or iterators referring to the elements of the
containers being swapped. [<i>Note:</i> The <tt>end()</tt> iterator does not refer to any element, so it may be
invalidated. &mdash; <i>end note</i>]
</p></li>
</ul>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="2325"></a>2325. <tt>minmax_element()</tt>'s behavior differing from <tt>max_element()</tt>'s should be noted</h3>
<p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
25.4.7 [alg.min.max]/23 says that <tt>max_element()</tt> finds the <em>first</em> biggest element, while /25 says that 
<tt>minmax_element()</tt> finds the <em>last</em> biggest element. This significant difference is unusual &mdash; it means that 
<tt>minmax_element(args)</tt> is not equivalent to <tt>make_pair(min_element(args), max_element(args))</tt>, whereas the other 
major "two for one" algorithm <tt>equal_range(args)</tt> is equivalent to <tt>make_pair(lower_bound(args), upper_bound(args))</tt>.  
<tt>minmax_element()</tt>'s behavior is intentional &mdash; it is a fundamental consequence of the <tt>3N/2</tt> algorithm &mdash; 
but the Standardese does not draw attention to this in any way. This wording came from LWG <a href="lwg-defects.html#715">715</a>'s resolution (which 
changed the semantics but didn't mention it), citing CLRS for the algorithm &mdash; but CLRS doesn't mention the behavior for 
equivalent elements! The wording here deeply confused me (as an STL maintainer fixing an incorrect implementation) until I walked 
through the algorithm by hand and figured out the fundamental reason. It would be really nice for the Standard to provide a hint 
that something magical is happening here.
</p>

<p><i>[2014-06-06 Library reflector vote]</i></p>

<p>
The issue has been identified as Tentatively Ready based on six votes in favour.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Add a footnote to 25.4.7 [alg.min.max]/25 as indicated:</p>

<blockquote><pre>
template&lt;class ForwardIterator&gt;
  pair&lt;ForwardIterator, ForwardIterator&gt;
    minmax_element(ForwardIterator first, ForwardIterator last);
template&lt;class ForwardIterator, class Compare&gt;
  pair&lt;ForwardIterator, ForwardIterator&gt;
    minmax_element(ForwardIterator first, ForwardIterator last, Compare comp);
</pre><blockquote>
<p>
-25- <i>Returns:</i> <tt>make_pair(first, first)</tt> if <tt>[first,last)</tt> is empty, otherwise <tt>make_pair(m, M)</tt>, where
<tt>m</tt> is the first iterator in <tt>[first,last)</tt> such that no iterator in the range refers to a smaller element,
and where <tt>M</tt> is the last iterator <ins>[Footnote: This behavior intentionally differs from <tt>max_element()</tt>.]</ins> 
in <tt>[first,last)</tt> such that no iterator in the range refers to a larger element.
</p>
</blockquote></blockquote>
</li>

</ol>






<hr>
<h3><a name="2326"></a>2326. <tt>uniform_int_distribution&lt;unsigned char&gt;</tt> should be permitted</h3>
<p><b>Section:</b> 26.5.1.1 [rand.req.genl] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
26.5.1.1 [rand.req.genl]/1 says: "Throughout this subclause 26.5, the effect of instantiating a template [...] that has a 
template type parameter named <tt>IntType</tt> is undefined unless the corresponding template argument is <i>cv</i>-unqualified 
and is one of <tt>short</tt>, <tt>int</tt>, <tt>long</tt>, <tt>long long</tt>, <tt>unsigned short</tt>, <tt>unsigned int</tt>, 
<tt>unsigned long</tt>, or <tt>unsigned long long</tt>."  26.5.8.2.1 [rand.dist.uni.int] specifies 
<tt>template&lt;class IntType = int> class uniform_int_distribution</tt>, so this forbids 
<tt>uniform_int_distribution&lt;char/signed char/unsigned char&gt;</tt>.
<p/>
I am not aware of anything in <tt>&lt;random&gt;</tt> that works with 16-bit integers but fails with 8-bit integers, so I suspect 
that <tt>IntType</tt> and <tt>UIntType</tt> could simply be extended to permit the <tt>char</tt> family. Alternatively, this 
change could be limited to <tt>uniform_int_distribution</tt> alone, where it is definitely safe. A <tt>&lt;random&gt;</tt> expert 
should decide which change is best.
</p>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2328"></a>2328. Rvalue stream extraction should use perfect forwarding</h3>
<p><b>Section:</b> 27.7.2.6 [istream.rvalue] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-05-02</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
27.7.2.6 [istream.rvalue] declares <tt>operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;&amp; is, T&amp; x)</tt>.  
However, 27.7.2.2.3 [istream::extractors]/7 declares <tt>operator&gt;&gt;(basic_istream&lt;charT,traits&gt;&amp; in, charT* s)</tt>, 
plus additional overloads for <tt>unsigned char*</tt> and <tt>signed char*</tt>. This means that 
"<tt>return_rvalue_istream() &gt;&gt; &amp;arr[0]</tt>" won't compile, because <tt>T&amp;</tt> won't bind to the rvalue <tt>&amp;arr[0]</tt>.
</p>

<p><i>[2014-02-12 Issaquah : recategorize as P3]</i></p>


<p>
Jonathan Wakely: Bill was certain the change is right, I think so with less certainty
</p>

<p>
Jeffrey Yaskin: I think he's right, hate that we need this
</p>

<p>
Jonathan Wakely: is this the security issue Jeffrey raised on lib reflector?
</p>

<p>
Move to P3
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Edit 27.7.1 [iostream.format.overview], header <tt>&lt;istream&gt;</tt> synopsis, as indicated:</p>

<blockquote><pre>
namespace std {
  [&hellip;]
  template &lt;class charT, class traits, class T&gt;
    basic_istream&lt;charT, traits&gt;&amp;
    operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;&amp; is, T&amp;<ins>&amp;</ins> x);
}
</pre></blockquote>
</li>

<li><p>Edit 27.7.2.6 [istream.rvalue] as indicated:</p>

<blockquote><pre>
template &lt;class charT, class traits, class T&gt;
  basic_istream&lt;charT, traits&gt;&amp;
  operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;&amp; is, T&amp;<ins>&amp;</ins> x);
</pre><blockquote>
<p>
-1- <i>Effects:</i> <tt>is &gt;&gt;<del>x</del> <ins>std::forward&lt;T&gt;(x)</ins></tt>
<p/>
-2- <i>Returns:</i> <tt>is</tt>
</p>
</blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="2331"></a>2331. <tt>regex_constants::collate</tt>'s effects are inaccurately summarized</h3>
<p><b>Section:</b> 28.5.1 [re.synopt] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-05-23</p>
<p><b>View all other</b> <a href="lwg-index.html#re.synopt">issues</a> in [re.synopt].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The table in 28.5.1 [re.synopt]/1 says that <tt>regex_constants::collate</tt> "Specifies that character ranges of the form 
"<tt>[a-b]</tt>" shall be locale sensitive.", but 28.13 [re.grammar]/14 says that it affects individual character comparisons 
too.
</p>

<p><i>[2012-02-12 Issaquah : recategorize as P3]</i></p>


<p>
Marshall Clow: 28.13/14 only applies to ECMAScript
</p>

<p>
All: we're unsure
</p>

<p>
Jonathan Wakely: we should ask John Maddock
</p>

<p>
Move to P3
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>In 28.5.1 [re.synopt]/1, Table 138 &mdash; "<tt>syntax_option_type</tt> effects", change as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 138 &mdash; <tt>syntax_option_type</tt> effects</caption>
<tr>
<th align="center">Element</th>
<th align="center">Effect(s) if set</th>
</tr>

<tr>
<td colspan="2" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>collate</tt>
</td>
<td>
Specifies that character <del>ranges of the form "<tt>[a-b]</tt>"</del><ins>comparisons and character range comparisons</ins> 
shall be locale sensitive.
</td>
</tr>

<tr>
<td colspan="2" align="center">
<tt>&hellip;</tt>
</td>
</tr>

</table>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2334"></a>2334. <tt>atomic</tt>'s default constructor requires "uninitialized" state even for types with non-trivial default-constructor</h3>
<p><b>Section:</b> 29.6.5 [atomics.types.operations.req] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2013-10-03 <b>Last modified:</b> 2014-05-23</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.types.operations.req">issues</a> in [atomics.types.operations.req].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to 29.6.5 [atomics.types.operations.req] p4,
</p>
<blockquote><pre>
A ::A () noexcept = default;
</pre><blockquote>
<p>
<i>Effects:</i> leaves the atomic object in an uninitialized state. [<i>Note:</i> These semantics ensure compatibility
with <tt>C</tt>. &mdash; <i>end note</i>]
</p>
</blockquote></blockquote>
<p>
This implementation requirement is OK for POD types, like <tt>int</tt>, but 29.5 [atomics.types.generic] p1
intentionally allows template arguments of <tt>atomic</tt> with a non-trivial default constructor ("The type of the template argument 
<tt>T</tt> shall be trivially copyable (3.9)"), so this wording can be read in a way that makes the behaviour of the following code
undefined:
</p>
<blockquote><pre>
#include &lt;atomic&gt;
#include &lt;iostream&gt;

struct S {
  S() noexcept : v(42) {}
  int v;
};

int main() {
  std::atomic&lt;S&gt; as; // Default-initialization
  std::cout &lt;&lt; as.load().v &lt;&lt; std::endl; // ?
}
</pre></blockquote>
<p>
For a user-defined emulation of <tt>atomic</tt> the expected outcome would be defined and the program would output "42",
but existing implementations differ and the result value is a "random number" for at least one implementation. This seems
very surprising to me.
<p/>
To realize that seemingly existing requirement, an implementation is either required to violate normal language rules internally
or to perform specific bit-randomization-techniques after the normal default-initialization that called the default constructor
of <tt>S</tt>.
<p/>
According to my understanding, the non-normative note in 29.6.5 [atomics.types.operations.req] p4 is intended to
refer to types that are valid <tt>C</tt>-types, but the example type <tt>S</tt> is not such a type.
<p/>
To make the mental model of <tt>atomic</tt>'s default constructor more intuitive for user-code, I suggest to clarify the wording
to have the effects of default-initialization instead. The current state seems more like an unintended effect of imprecise
language used here and has some similarities to wording that was incorrectly used to specify <tt>atomic_flag</tt> initialization 
as described by LWG <a href="lwg-defects.html#2159">2159</a>.
</p>

<p><i>[2014-05-17, Daniel comments and provides alternative wording]</i></p>


<p>
The current wording was considered controversial as expressed by reflector discussions. To me, the actual problem is not newly
introduced by that wording, but instead is already present in basically all paragraphs specifying semantics of atomic types,
since the wording never clearly distinguishes the value of the actual atomic type <i>A</i> and the value of the "underlying",
corresponding non-atomic type <i>C</i>. The revised proposed wording attempts to improve the current ambiguity of these two
kinds of values.
</p>

<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
<p/>
<blockquote class="note">
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Modify 29.6.5 [atomics.types.operations.req] p4 as indicated: <em>[Editorial note: There is no exposition-only
member in <tt>atomic</tt>, which makes it a bit hard to specify what actually is initialized, but the usage of the term "value" 
seems consistent with similar wording used to specify the effects of the atomic <tt>load</tt> functions]</em></p>

<blockquote><pre>
A ::A () noexcept = default;
</pre><blockquote>
<p>
-4- <i>Effects:</i> <del>leaves the atomic object in an uninitialized state</del><ins>The value of the atomic object
is default-initialized (8.5 [dcl.init])</ins>. [<i>Note:</i> These semantics ensure compatibility
with <tt>C</tt>. &mdash; <i>end note</i>]
</p>
</blockquote></blockquote>
</li>

</ol>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Modify 29.6.5 [atomics.types.operations.req] p2 as indicated: <em>[Editorial note: This is a near-to editorial
change not directly affecting this issue, but <tt>atomic_address</tt> does no longer exist and the pointed to definition is
relevant in the context of this issue resolution.]</em>
</p>
<blockquote>
<p>
-2- In the following operation definitions:
</p>
<ul>
<li><p>an <i>A</i> refers to one of the atomic types.</p></li>
<li><p>a <i>C</i> refers to its corresponding non-atomic type. <del>The <tt>atomic_address</tt> atomic type corresponds to the
<tt>void*</tt> non-atomic type.</del></p></li>
<li><p>[&hellip;]</p></li>
</ul>
</blockquote>
</li>

<li><p>Modify 29.6.5 [atomics.types.operations.req] p4 and the following as indicated: <em>[Editorial note: There 
is no exposition-only member in <tt>atomic</tt>, which makes it a bit hard to specify what actually is initialized, but 
the introductory wording of 29.6.5 [atomics.types.operations.req] p2 b2 defines: "a <i>C</i> refers to its 
corresponding non-atomic type." which helps to specify the semantics in terms of "the <i>C</i> value referred to by the 
atomic object"]</em></p>

<blockquote>
<pre>
<i>A</i>::<i>A</i>() noexcept = default;
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> <del>leaves the atomic object in an uninitialized state</del><ins>Default-initializes (8.5 [dcl.init]) 
the <i>C</i> value referred to by the atomic object</ins>. [<i>Note:</i> These semantics ensure compatibility with <tt>C</tt>. 
&mdash; <i>end note</i>]
</p>
</blockquote>

<pre>
constexpr <i>A</i>::<i>A</i>(<i>C</i> desired) noexcept;
</pre>
<blockquote>
<p>
-5- <i>Effects:</i> <ins>Direct-i</ins><del>I</del>nitializes the <ins><i>C</i> value referred to by the atomic</ins> object 
with the value <tt>desired</tt>. Initialization is not an atomic operation (1.10). [&hellip;]
<p/>
[&hellip;]
</p>
</blockquote>

<pre>
void atomic_init(volatile <i>A</i>* object, <i>C</i> desired) noexcept;
void atomic_init(<i>A</i>* object, <i>C</i> desired) noexcept;
</pre>
<blockquote>
<p>
-8- <i>Effects:</i> Non-atomically initializes <ins>the <i>C</i> value referred to by</ins> <tt>*object</tt> with value 
<tt>desired</tt>. [&hellip;]
</p>
</blockquote>

<pre>
void atomic_store(volatile <i>A</i>* object, <i>C</i> desired) noexcept;
[&hellip;]
void <i>A</i>::store(<i>C</i> desired, memory_order order = memory_order_seq_cst) noexcept;
</pre>
<blockquote>
<p>
-9- [&hellip;]
<p/>
-10- <i>Effects:</i> Atomically replaces the <ins><i>C</i></ins> value pointed to by 
<tt>object</tt> or by <tt>this</tt> with the value of <tt>desired</tt>. [&hellip;]
<p/>
[&hellip;]
</p>
</blockquote>

<pre>
<i>C</i> atomic_load(const volatile <i>A</i>* object) noexcept;
[&hellip;]
<i>C</i> <i>A</i>::load(memory_order order = memory_order_seq_cst) const noexcept;
</pre>
<blockquote>
<p>
-13- [&hellip;]
<p/>
-14- [&hellip;]
<p/>
-15- <i>Returns:</i> Atomically returns the <ins><i>C</i></ins> value pointed to by <tt>object</tt> or by <tt>this</tt>.
<p/>
[&hellip;]
</p>
</blockquote>

<pre>
<i>C</i> atomic_exchange(volatile <i>A</i>* object, C desired) noexcept;
[&hellip;]
<i>C</i> <i>A</i>::exchange(C desired, memory_order order = memory_order_seq_cst) noexcept;
</pre>
<blockquote>
<p>
-18- <i>Effects</i>: Atomically replaces the <ins><i>C</i></ins> value pointed to by <tt>object</tt> or by <tt>this</tt> with <tt>desired</tt>. [&hellip;]
<p/>
-19- <i>Returns:</i> Atomically returns the <ins><i>C</i></ins> value pointed to by <tt>object</tt> or by <tt>this</tt> 
immediately before the effects.
<p/>
[&hellip;]
</p>
</blockquote>

<pre>
<i>C</i> atomic_fetch_key(volatile <i>A</i>* object, <i>M</i> operand) noexcept;
[&hellip;]
<i>C</i> <i>A</i>::fetch_key(<i>M</i> operand, memory_order order = memory_order_seq_cst) noexcept;
</pre>
<blockquote>
<p>
-28- <i>Effects</i>: Atomically replaces the <ins><i>C</i></ins> value pointed to by <tt>object</tt> or by <tt>this</tt> with 
the result of the computation applied to the <ins><i>C</i></ins> value pointed to by <tt>object</tt> or by <tt>this</tt> and 
the given <tt>operand</tt>. [&hellip;]
<p/>
-29- <i>Returns:</i> Atomically<del>,</del> <ins>returns</ins> the <ins><i>C</i></ins> value pointed to by <tt>object</tt>
or by <tt>this</tt> immediately before the effects.
<p/>
[&hellip;]
</p>
</blockquote>

</blockquote>
</li>

<li><p>Modify 29.7 [atomics.flag] p5 and the following as indicated:</p>

<blockquote>
<pre>
bool atomic_flag_test_and_set(volatile atomic_flag* object) noexcept;
[&hellip;]
bool atomic_flag::test_and_set(memory_order order = memory_order_seq_cst) noexcept;
</pre>
<blockquote>
<p>
-5- <i>Effects</i>: Atomically sets the <ins>bool</ins> value pointed to by <tt>object</tt> or by <tt>this</tt> to <tt>true</tt>. 
[&hellip;]
<p/>
-6- <i>Returns</i>: Atomically<del>,</del> <ins>returns</ins> the <ins>bool</ins> value <del>of the</del><ins>pointed 
to by</ins> <tt>object</tt> <ins>or by <tt>this</tt></ins> immediately before the effects.
</p>
</blockquote>

<pre>
void atomic_flag_clear(volatile atomic_flag* object) noexcept;
[&hellip;]
void atomic_flag::clear(memory_order order = memory_order_seq_cst) noexcept;
</pre>
<blockquote>
<p>
-7- [&hellip;]
<p/>
-8- <i>Effects</i>: Atomically sets the <ins>bool</ins> value pointed to by <tt>object</tt> or by <tt>this</tt> to <tt>false</tt>. 
[&hellip;]
</p>
</blockquote>

</blockquote>

</li>
</ol>





<hr>
<h3><a name="2335"></a>2335. <tt>array&lt;array&lt;int, 3&gt;, 4&gt;</tt> should be layout-compatible with <tt>int[4][3]</tt></h3>
<p><b>Section:</b> 23.3.2 [array] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2013-10-04 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#array">issues</a> in [array].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In order to replace some uses of C arrays with <tt>std::array</tt>, we need it
to be possible to cast from a <tt>std::array&lt;&gt;</tt> to an equivalent C array.
Core wording doesn't appear to be in quite the right state to allow
casting, but if we specify that appropriate types are
layout-compatible, we can at least write:
</p>
<blockquote><pre>
union {
  array&lt;array&lt;array&lt;int, 2&gt;, 3&gt;, 4&gt; arr;
  int carr[4][3][2];
};
</pre></blockquote>
<p>
to view memory as the other type: C++14 CD [class.mem]p18.
</p>
I believe it's sufficient to add "<tt>array&lt;T, N&gt;</tt> shall be
layout-compatible (3.9 [basic.types]) with <tt>T[N]</tt>." to 
23.3.2.1 [array.overview], but we might also need some extension to 
9.2 [class.mem] to address the possibility of layout-compatibility 
between struct and array types.
<p>
I checked that libc++ on MacOS already implements this, although it
would be good for someone else to double-check; I haven't checked any
other standard libraries.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2336"></a>2336. <tt>is_trivially_constructible/is_trivially_assignable</tt> traits are always false</h3>
<p><b>Section:</b> 20.10.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2013-10-01 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 20.10.4.3 [meta.unary.prop] we have traits to allow testing for triviality of specific operations, such as
<tt>is_trivially_constructible</tt> and <tt>is_trivially_assignable</tt> (and their derived forms), which are specified
in terms of the following initialization and assignment, respectively:
</p>
<blockquote><pre>
T t(create&lt;Args&gt;()...);

declval&lt;T&gt;() = declval&lt;U&gt;()
</pre></blockquote>
<p>
The wording that describes the way how triviality is deduced, is in both cases of the same form:
</p>
<blockquote><p>
[&hellip; ] and the variable definition/assignment, as defined by <tt>is_constructible/is_assignable</tt>, is known
to call no operation that is not trivial (3.9, 12).
</p></blockquote>
<p>
The problematic part of this wording is that both definitions are specified in terms of an "object construction" function
<tt>create</tt> or <tt>declval</tt>, respectively, (The former being a conceptual function, the latter being a library function), 
but for none of these functions we can assume that they could be considered as trivial &mdash; only special member functions can 
have this property and none of these is one. This problem became obvious, when the similar issue LWG <a href="lwg-defects.html#2298">2298</a> 
in regard to <tt>is_nothrow_constructible</tt> was opened.
<p/>
A possible approach to solve this specification problem is to make a blanket statement for sub-clause 20.10.4.3 [meta.unary.prop]
that these helper functions are considered trivial for the purpose of defining these traits.
<p/>
Using this kind of wording technique can also be used to get rid of the additional helper function template <tt>create</tt>, which
is currently needed for the <tt>is_convertible</tt> and the <tt>is_constructible</tt> traits, because both traits are specified in
terms of contexts where technically the corresponding "object construction" function would be considered as odr-used. This is problematic,
because these traits are defined in terms of well-formed code and odr-using <tt>declval</tt> would make the program ill-formed (see
20.2.5 [declval]). So extending above blanket statement to consider <tt>std::declval&lt;T&gt;()</tt> as not odr-used
in the context of the corresponding trait definition would allow for replacing <tt>create</tt> by <tt>declval</tt>.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Add a new paragraph after 20.10.4.3 [meta.unary.prop] p3 as indicated: <em>[Editorial note: The first change in
20.10.4.3 [meta.unary.prop] p3 is recommended, because technically a Clause is always a "main chapter" &mdash; such as
Clause 20 &mdash; but every child of a Clause or sub-clause is a sub-clause]</em></p>

<blockquote>
<p>
[&hellip;]
<p/>
-3- For all of the class templates <tt>X</tt> declared in this <del>Clause</del><ins>sub-clause</ins>, instantiating that 
template with a template-argument that is a class template specialization may result in the implicit instantiation of the 
template argument if and only if the semantics of <tt>X</tt> require that the argument must be a complete type.
<p/>
<ins>-?- For the purpose of defining the templates in this sub-clause, a function call expression 
<tt>declval&lt;T&gt;()</tt> for any type <tt>T</tt> is considered to be a trivial (3.9 [basic.types], 12 [special]) 
function call that is not an odr-use (3.2 [basic.def.odr]) of <tt>declval</tt> in the context of the corresponding definition 
notwithstanding the restrictions of 20.2.5 [declval].</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</li>

<li><p>Modify 20.10.4.3 [meta.unary.prop] p7 as indicated:</p>

<blockquote>
<p>
-7- <del>Given the following function prototype:</del>
</p>
<blockquote><pre>
<del>template &lt;class T&gt;
  typename add_rvalue_reference&lt;T&gt;::type create();</del>
</pre></blockquote>
<p>
<del>t</del><ins>T</ins>he predicate condition for a template specialization <tt>is_constructible&lt;T, Args...&gt;</tt> 
shall be satisfied if and only if the following variable definition would be well-formed for some invented variable <tt>t</tt>:
</p>
<blockquote><pre>
T t(<del>create</del><ins>declval</ins>&lt;Args&gt;()...);
</pre></blockquote>
<p>
[&hellip;]
</p>
</blockquote>
</li>

<li><p>Add a new paragraph after 20.10.6 [meta.rel] p2 as indicated: <em>[Editorial note: Technically we don't need
the guarantee of "a trivial function call" for the type relationship predicates at the very moment, but it seems more robust and
consistent to have the exact same guarantee here as well]</em>
</p>
<blockquote>
<p>
[&hellip;]
<p/>
-2- [&hellip;]
<p/>
<ins>-?- For the purpose of defining the templates in this sub-clause, a function call expression 
<tt>declval&lt;T&gt;()</tt> for any type <tt>T</tt> is considered to be a trivial (3.9 [basic.types], 12 [special]) 
function call that is not an odr-use (3.2 [basic.def.odr]) of <tt>declval</tt> in the context of the corresponding definition 
notwithstanding the restrictions of 20.2.5 [declval].</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</li>

<li><p>Modify 20.10.6 [meta.rel] p4 as indicated:</p>

<blockquote>
<p>
-4- <del>Given the following function prototype:</del>
</p>
<blockquote><pre>
<del>template &lt;class T&gt;
  typename add_rvalue_reference&lt;T&gt;::type create();</del>
</pre></blockquote>
<p>
<del>t</del><ins>T</ins>he predicate condition for a template specialization <tt>is_convertible&lt;From, To&gt;</tt> 
shall be satisfied if and only if the return expression in the following code would be well-formed, including any implicit 
conversions to the return type of the function:
</p>
<blockquote><pre>
To test() {
  return <del>create</del><ins>declval</ins>&lt;From&gt;();
}
</pre></blockquote>
<p>
[&hellip;]
</p>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="2337"></a>2337. <tt>shared_ptr operator*()</tt> should not be <tt>noexcept</tt></h3>
<p><b>Section:</b> 20.8.2.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-10-05 <b>Last modified:</b> 2014-03-03</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.8.1.2.4 [unique.ptr.single.observers]/3: "<tt>pointer operator-&gt;() const noexcept;</tt> <i>Requires:</i> <tt>get() != nullptr</tt>."
<p/>
20.8.2.2.5 [util.smartptr.shared.obs]/2: "<tt>T&amp; operator*() const noexcept;</tt> <i>Requires:</i> <tt>get() != 0</tt>."
<p/>
20.8.2.2.5 [util.smartptr.shared.obs]/5: "<tt>T* operator-&gt;() const noexcept;</tt> <i>Requires:</i> <tt>get() != 0</tt>."
<p/>
Narrow-contract functions should not be <tt>noexcept</tt>.
</p>

<p><i>[2015-02-15 Issuquah]</i></p>

<p>
Issue is contentious, raise to P2.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>In 20.8.1.2 [unique.ptr.single]/1, class template <tt>unique_ptr</tt> synopsis for single objects, change as indicated:</p>

<blockquote><pre>
pointer operator-&gt;() const <del>noexcept</del>;
</pre></blockquote>
</li>

<li><p>In 20.8.1.2.4 [unique.ptr.single.observers] change as indicated:</p>

<blockquote><pre>
pointer operator-&gt;() const <del>noexcept</del>;
</pre><blockquote>
<p>
-3- <i>Requires:</i> <tt>get() != nullptr</tt>.
<p/>
-4- <i>Returns:</i> <tt>get()</tt>.
<p/>
<ins>-?- <i>Throws:</i> Nothing.</ins>
<p/>
-5- <i>Note:</i> use typically requires that <tt>T</tt> be a complete type.
</p>
</blockquote></blockquote>
</li>

<li><p>In 20.8.2.2 [util.smartptr.shared]/1, class template <tt>shared_ptr</tt> synopsis, change as indicated:</p>

<blockquote><pre>
T&amp; operator*() const <del>noexcept</del>;
T* operator-&gt;() const <del>noexcept</del>;
</pre></blockquote>
</li>

<li><p>In 20.8.2.2.5 [util.smartptr.shared.obs] change as indicated:</p>

<blockquote><pre>
T&amp; operator*() const <del>noexcept</del>;
</pre><blockquote>
<p>
-2- <i>Requires:</i> <tt>get() != 0</tt>.
<p/>
-3- <i>Returns:</i> <tt>*get()</tt>.
<p/>
<ins>-?- <i>Throws:</i> Nothing.</ins>
<p/>
-4- <i>Remarks:</i> When <tt>T</tt> is <tt>void</tt>, it is unspecified whether this member function is declared. 
If it is declared, it is unspecified what its return type is, except that the declaration (although not necessarily the
definition) of the function shall be well formed.
</p>
</blockquote></blockquote>

<blockquote><pre>
T* operator-&gt;() const <del>noexcept</del>;
</pre><blockquote>
<p>
-5- <i>Requires:</i> <tt>get() != 0</tt>.
<p/>
-6- <i>Returns:</i> <tt>get()</tt>.
<p/>
<ins>-?- <i>Throws:</i> Nothing.</ins>
</p>
</blockquote></blockquote>
</li>

</ol>





<hr>
<h3><a name="2338"></a>2338. [re.traits]/7 expects of locale facets something not guaranteed by [locale.facet]/4</h3>
<p><b>Section:</b> 28.7 [re.traits], 22.3.1.1.2 [locale.facet] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Sergey Zubkov <b>Opened:</b> 2013-10-15 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#re.traits">issues</a> in [re.traits].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
28.7 [re.traits]/7, begins with "if <tt>typeid(use_facet&lt;collate&lt;charT&gt; &gt;) == typeid(collate_byname&lt;charT&gt;)</tt>", 
which appears to be pseudocode with the intention to convey that the collate facet has not been replaced by the user. Cf. the wording in 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1429.htm">N1429</a> "there is no portable way to implement 
<tt>transform_primary</tt> in terms of <tt>std::locale</tt>, since even if the sort key format returned by 
<tt>std::collate_byname&lt;&gt;::transform</tt> is known and can be converted into a primary sort key, the user can still 
install their own custom <tt>std::collate</tt> implementation into the locale object used, and that can use any sort key 
format they see fit.".
<p/>
Taken literally, 28.7 [re.traits]/7 appears to imply that named locales are required to hold their collate facets with 
dynamic type <tt>std::collate_byname&lt;charT&gt;</tt>, which is in fact true in some implementations (e.g libc++), but not others 
(e.g. libstdc++). This does not follow from the description of <tt>_byname</tt> in 22.3.1.1.2 [locale.facet]/4, which is only 
required to provide equivalent semantics, to the named locale's facet, not to actually be one.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Modify 22.3.1.1.2 [locale.facet]/4 as indicated:</p>

<blockquote><p>
For some standard facets a standard "...<tt>_byname</tt>" class, derived from it, implements the virtual function
semantics <del>equivalent to</del><ins>provided by</ins> that facet of the locale constructed by <tt>locale(const char*)</tt> 
with the same name.
Each such facet provides a constructor that takes a <tt>const char*</tt> argument, which names the locale, and a
<tt>refs</tt> argument, which is passed to the base class constructor. Each such facet also provides a constructor
that takes a string argument <tt>str</tt> and a <tt>refs</tt> argument, which has the same effect as calling the first
constructor with the two arguments <tt>str.c_str()</tt> and <tt>refs</tt>. If there is no "...<tt>_byname</tt>" 
version of a facet, the base class implements named locale semantics itself by reference to other facets. <ins>For any 
locale <tt>loc</tt> constructed by <tt>locale(const char*)</tt> and facet <tt>Facet</tt> that has a corresponding standard 
<tt>Facet_byname</tt> class, <tt>typeid(use_facet&lt;Facet&gt;(loc)) == typeid(Facet_byname)</tt>.</ins>
</p></blockquote>
</li>

<li><p>Modify 28.7 [re.traits]/7 as indicated:</p>

<blockquote><pre>
template &lt;class ForwardIterator&gt;
  string_type transform_primary(ForwardIterator first, ForwardIterator last) const;
</pre><blockquote>
<p>
-7- <i>Effects:</i> if <tt>typeid(use_facet&lt;collate&lt;charT&gt; &gt;<ins>(getloc())</ins>) == typeid(collate_byname&lt;charT&gt;)</tt> 
and the form of the sort key returned by <tt>collate_byname&lt;charT&gt;::transform(first, last)</tt> is known and
can be converted into a primary sort key then returns that key, otherwise returns an empty string.
</p>
</blockquote></blockquote>
</li>

</ol>





<hr>
<h3><a name="2340"></a>2340. Replacement allocation functions declared as inline</h3>
<p><b>Section:</b> 17.6.4.6 [replacement.functions] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> David Majnemer <b>Opened:</b> 2013-10-20 <b>Last modified:</b> 2014-03-03</p>
<p><b>View all other</b> <a href="lwg-index.html#replacement.functions">issues</a> in [replacement.functions].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
N3290 17.6.4.6 [replacement.functions]/p3 says:
</p>
<blockquote><p>
The program's definitions shall not be specified as <tt>inline</tt>.
</p></blockquote>
<p>
This seems to permit declarations of replacement allocation functions that are specified as <tt>inline</tt> so long 
as they aren't used. This behavior seems more like a bug than a feature, I propose that we do the following:
</p>
<blockquote><p>
The program's <del>definitions</del><ins>declarations</ins> shall not be specified as <tt>inline</tt>.
</p></blockquote>

<p><i>[2014-02-15 Issaquah : Move to Ready]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

<ol>
<li><p>Modify 17.6.4.6 [replacement.functions]/3 as indicated:</p>

<blockquote><p>
-3- The program's definitions are used instead of the default versions supplied by the implementation (18.6).
Such replacement occurs prior to program startup (3.2, 3.6). The program's <del>definitions</del><ins>declarations</ins> 
shall not be specified as <tt>inline</tt>. No diagnostic is required.</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2342"></a>2342. User conversion to <tt>wchar_t const*</tt> or to <tt>wchar_t</tt> not invoked for <tt>operator&lt;&lt;</tt></h3>
<p><b>Section:</b> 27.7.3.1 [ostream] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Alf P. Steinbach <b>Opened:</b> 2013-10-29 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#ostream">issues</a> in [ostream].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
For wide streams argument types <tt>wchar_t const*</tt> and <tt>wchar_t</tt> are supported only as template parameters. 
User defined conversions are not considered for template parameter matching. Hence inappropriate overloads of 
<tt>operator&lt;&lt;</tt> are selected when an implicit conversion is required for the argument, which is inconsistent 
with the behavior for <tt>char const*</tt> and <tt>char</tt>, is unexpected, and is a useless result.
<p/>
Demonstration:
</p>
<blockquote><pre>
#include &lt;iostream&gt;

struct Byte_string
{ 
  operator char const*() const { return "Hurray, it works!"; } 
};

struct Wide_string
{ 
  operator wchar_t const*() const { return L"Hurray, it works!"; } 
};

struct Byte_ch
{ 
  operator char() const { return 'X'; } 
};

struct Wide_ch
{ 
  operator wchar_t() const { return L'X'; } 
};

auto main() -> int
{
  using namespace std;
  wcout &lt;&lt; "'X' as char value   : " &lt;&lt; Byte_ch() &lt;&lt; endl;
  wcout &lt;&lt; "'X' as wchar_t value: " &lt;&lt; Wide_ch() &lt;&lt; endl;
  wcout &lt;&lt; "Byte string pointer : " &lt;&lt; Byte_string() &lt;&lt; endl;
  wcout &lt;&lt; "Wide string pointer : " &lt;&lt; Wide_string() &lt;&lt; endl;
}
</pre></blockquote>
<p>
Example output:
</p>
<blockquote><pre>
'X' as char value   : X
'X' as wchar_t value: 88
Byte string pointer : Hurray, it works!
Wide string pointer : 000803C8
</pre></blockquote>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

<ol>
<li><p>Modify 27.7.3.1 [ostream], class template <tt>basic_ostream</tt> synopsis, as indicated:</p>

<blockquote><pre>
namespace std {
[&hellip;]

<i>// 27.7.3.6.4 character inserters</i>
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp;,
                                          charT);
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp;,
                                          char);
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp;,
                                         char);
<ins>template&lt;class traits&gt;
  basic_ostream&lt;wchar_t,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;wchar_t,traits&gt;&amp;,
                                            wchar_t);</ins>
[&hellip;]

template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp;,
                                          const charT*);
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp;,
                                          const char*);
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp;,
                                         const char*);
<ins>template&lt;class traits&gt;
  basic_ostream&lt;wchar_t,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;wchar_t,traits&gt;&amp;,
                                            const wchar_t*);</ins>
[&hellip;]
}

</pre></blockquote>
</li>

<li><p>Modify 27.7.3.6.4 [ostream.inserters.character] as indicated: <em>[Drafting note: 
The replacement of <tt>os</tt> by <tt>out</tt> in p1 and the insertion of "<tt>out.</tt>" in p4 
just fix two obvious typos &mdash; end drafting note]</em></p>

<blockquote><pre>
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp; out,
                                          charT c);
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp; out,
                                          char c);
<i>// specialization</i>
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                         char c);
<ins>template&lt;class traits&gt;
  basic_ostream&lt;wchar_t,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;wchar_t,traits&gt;&amp; out,
                                            wchar_t c);</ins>

<i>// signed and unsigned</i>
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                          signed char c);
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                          unsigned char c);
</pre><blockquote>
<p>
-1- <i>Effects:</i> Behaves as a formatted output function (27.7.3.6.1 [ostream.formatted.reqmts]) of <tt>out</tt>. 
Constructs a character sequence <tt>seq</tt>. If <tt>c</tt> has type <tt>char</tt> and the character type of the stream 
is not <tt>char</tt>, then <tt>seq</tt> consists of <tt>out.widen(c)</tt>; otherwise <tt>seq</tt> consists of <tt>c</tt>. 
Determines padding for <tt>seq</tt> as described in 27.7.3.6.1 [ostream.formatted.reqmts]. Inserts <tt>seq</tt> into 
<tt>out</tt>. Calls <tt><del>os</del><ins>out</ins>.width(0)</tt>.
<p/>
-2- <i>Returns:</i> <tt>out</tt>.
</p>
</blockquote>
<pre>
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp; out,
                                          const charT* s);
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp; out,
                                          const char* s);
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                         const char* s);
<ins>template&lt;class traits&gt;
  basic_ostream&lt;wchar_t,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;wchar_t,traits&gt;&amp; out,
                                            const wchar_t* s);</ins>
											
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                         const signed char* s);
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                         const unsigned char* s);
</pre><blockquote>
<p>
-3- <i>Requires:</i> <tt>s</tt> shall not be a null pointer.
<p/>
-4- <i>Effects:</i> Behaves like a formatted inserter (as described in 27.7.3.6.1 [ostream.formatted.reqmts]) of <tt>out</tt>. 
Creates a character sequence <tt>seq</tt> of <tt>n</tt> characters starting at <tt>s</tt>, each widened using <tt>out.widen()</tt> 
(27.5.5.3), where <tt>n</tt> is the number that would be computed as if by:
</p>
<ul>
<li><p>
<tt>traits::length(s)</tt> for the <ins>following</ins> overload<ins>s:</ins>
<ul>
<li><p>
where the first argument is of type <tt>basic_ostream&lt;charT, traits&gt;&amp;</tt> 
and the second is of type <tt>const charT*</tt>,
</p></li>
<li><p>
<del>and also for the overload</del> where the first argument is of type 
<tt>basic_ostream&lt;char, traits&gt;&amp;</tt> and the second is of type <tt>const char*</tt>,
</p></li>
<li><p>
<ins>where the first argument is of type 
<tt>basic_ostream&lt;wchar_t, traits&gt;&amp;</tt> and the second is of type <tt>const wchar_t*</tt>,</ins>
</p></li>
</ul> 
</p></li>
<li><p>
<tt>std::char_traits&lt;char&gt;::length(s)</tt> for the overload where the first argument is of type
<tt>basic_ostream&lt;charT, traits&gt;&amp;</tt> and the second is of type <tt>const char*</tt>,
</p></li>
<li><p>
<tt>traits::length(reinterpret_cast&lt;const char*&gt;(s))</tt> for the other two overloads.
</p></li>
</ul>
<p>
Determines padding for <tt>seq</tt> as described in 27.7.3.6.1 [ostream.formatted.reqmts]. Inserts <tt>seq</tt> into 
<tt>out</tt>. Calls <tt><ins>out.</ins>width(0)</tt>.
<p/>
-5- <i>Returns:</i> <tt>out</tt>.
</p>
</blockquote></blockquote>
</li>

</ol>





<hr>
<h3><a name="2343"></a>2343. Is the value of the ECMA-262 RegExp object's multiline property really false?</h3>
<p><b>Section:</b> 28.13 [re.grammar] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Nayuta Taga <b>Opened:</b> 2013-10-30 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#re.grammar">issues</a> in [re.grammar].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In the following "Multiline" is the value of the ECMA-262 RegExp object's multiline property.
<p/>
In <a href="http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%203rd%20edition,%20December%201999.pdf">ECMA-262</a>, 
there are some definitions that relate to Multiline:
</p>
<ul>
<li><p>
ECMA-262 15.10.2.6:
</p>
<blockquote>
<p>
If Multiline is true, ^ matches just after LineTerminator.
<p/>
If Multiline is false, ^ does not match just after LineTerminator.
<p/>
If Multiline is true, $ matches just before LineTerminator.
<p/>
If Multiline is false, $ does not match just before LineTerminator.
</p>
</blockquote>
</li>
<li>
<p>
ECMA-262 15.10.4.1, 15.10.7.4:
</p>
<blockquote><p>
By default, Multiline is false.
</p></blockquote>
</li>
</ul>
<p>
So, the C++11 standard says that Multiline is false. As it is false,
^ matches only the beginning of the string, and $ matches only the end
of the string.
<p/>
However, two flags are defined in 28.5.2 [re.matchflag] Table 139:
</p>
<blockquote>
<p>
<tt>match_not_bol</tt>: the character ^ in the regular expression shall not match <tt>[first,first)</tt>.
<p/>
<tt>match_not_eol</tt>: the character "$" in the regular expression shall not match <tt>[last,last)</tt>.
</p>
</blockquote>
<p>
As Multiline is false, the <tt>match_not_bol</tt> and the <tt>match_not_eol</tt> are
meaningless because they only make ^ and $ match none.
<p/>
In my opinion, Multiline should be true.
<p/>
FYI, Multiline of the existing implementations are as follows:
<p/>
<em>Multiline=false:</em>
</p>
<ul>
<li><p>
libstdc++ r206594
</p></li>
<li><p>
libc++ r199174
</p></li>
</ul>
<p>
<em>Multiline=true:</em>
</p>
<ul>
<li><p>
Visual Studio Express 2013
</p></li>
<li><p>
boost 1.55
</p></li>
</ul>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2348"></a>2348. <tt>charT('1')</tt> is not the wide equivalent of <tt>'1'</tt></h3>
<p><b>Section:</b> 20.6 [template.bitset], 27.7.6 [quoted.manip] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Zhihao Yuan <b>Opened:</b> 2013-12-02 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Example: <tt>char16_t('1') != u'1'</tt> is possible.
<p/>
The numeric value of <tt>char16_t</tt> is defined to be Unicode
code point, which is same to the ASCII value and UTF-8 for
7-bit chars.  However, <tt>char</tt> is not guaranteed to have an
encoding which is compatible with ASCII. For example, <tt>'1'</tt> in EBCDIC is 241.
<p/>
I found three places in the standard casting narrow char
literals: <tt>bitset::bitset</tt>, <tt>bitset::to_string</tt> and <tt>quoted</tt>.
<p/>
PJ confirmed this issue and says he has a solution used
in their <tt>&lt;filesystem&gt;</tt> implementation, and he may want to
propose it to the standard.
<p/>
The solution in my mind, for now, is to make those default
arguments magical, where the "magic" can be implemented
with a C11 <tt>_Generic</tt> selection (works in clang):
</p>
<blockquote><pre>
#define _G(T, literal) _Generic(T{}, \
      char: literal, \
      wchar_t: L ## literal, \
      char16_t: u ## literal, \
      char32_t: U ## literal)

  _G(char16_t, '1') == u'1'
</pre></blockquote>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

[<i>Drafting note:</i> This is a sample wording fixing only one case;
 I'm just too lazy to copy-paste it before we discussed whether
 the solution is worth and sufficient (for example, should the
 other `charT`s like `unsigned char` just don't compile without
 supplying those arguments?  I hope so). &mdash; <i>end drafting note</i>]

<ol>
<li><p>Modify 20.6 [template.bitset] p1, class template <tt>bitset</tt> synopsis, as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;size_t N&gt; class bitset {
  public:
    [&hellip;]
    template&lt;class charT, class traits, class Allocator&gt;
      explicit bitset(
        const basic_string&lt;charT,traits,Allocator&gt;&amp; str,
        typename basic_string&lt;charT,traits,Allocator&gt;::size_type pos = 0,
        typename basic_string&lt;charT,traits,Allocator&gt;::size_type n =
          basic_string&lt;charT,traits,Allocator&gt;::npos,
          charT zero = <del>charT('0')</del><ins><em>see below</em></ins>, charT one = <del>charT('1')</del><ins><em>see below</em></ins>);
     [&hellip;]
  };
  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Modify 20.6.1 [bitset.cons] as indicated:</p>

<blockquote><pre>
template&lt;class charT, class traits, class Allocator&gt;
explicit 
bitset(const basic_string&lt;charT, traits, Allocator&gt;&amp; str,
       typename basic_string&lt;charT, traits, Allocator&gt;::size_type pos = 0,
       typename basic_string&lt;charT, traits, Allocator&gt;::size_type n =
         basic_string&lt;charT, traits, Allocator&gt;::npos,
         charT zero = <del>charT('0')</del><ins><em>see below</em></ins>, charT one = <del>charT('1')</del><ins><em>see below</em></ins>);
</pre><blockquote>
<p>
<ins>-?- The default values of <tt>zero</tt> and <tt>one</tt> compare equal to the
character literals <tt>0</tt> and <tt>1</tt> of type <tt>charT</tt>, respectively.</ins>
<p/>
-3- <i>Requires::</i> <tt>pos &lt;= str.size()</tt>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>
</li>

</ol>






<hr>
<h3><a name="2349"></a>2349. Clarify input/output function rethrow behavior</h3>
<p><b>Section:</b> 27.7.2.2.1 [istream.formatted.reqmts] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Zhihao Yuan <b>Opened:</b> 2013-12-06 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#istream.formatted.reqmts">issues</a> in [istream.formatted.reqmts].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The formatted input function requirement says in 27.7.2.2.1 [istream.formatted.reqmts]:
</p>
<blockquote><p>
"If an exception is thrown during input then <tt>ios::badbit</tt> is turned on
in <tt>*this</tt>'s error state.  If <tt>(exceptions()&amp;badbit) != 0</tt> then the exception
is rethrown."
</p></blockquote>
<p>
while some formatted function may throw an exception from <tt>basic_ios::clear</tt>, for example
in 20.6.4 [bitset.operators] p6:
</p>
<blockquote><p>
"If no characters are stored in <tt>str</tt>, calls <tt>is.setstate(ios_base::failbit)</tt> (which may 
throw <tt>ios_base::failure</tt>)"
</p></blockquote>
<p>
So should this exception be considered as "an exception [...] thrown
during input"?  And here is an implementation divergence (or you
can read the following as "a bug libc++ only has" :)
</p>
<blockquote><pre>
cin.exceptions(ios_base::failbit);
bitset&lt;N&gt; b;
try {
  cin &gt;&gt; b;  // type 'a' and return
} catch (...)
{}
</pre></blockquote>
<p>
Now <tt>cin.rdstate()</tt> is just <tt>failbit</tt> in libstdc++ (and Dinkumware, by
PJ), but <tt>failbit &amp; badbit</tt> libc++. Similar difference found in other
places, like <tt>eofbit &amp; badbid</tt> after <tt>std::getline</tt>.
<p/>
PJ and Matt both agree that the intention (of <tt>badbit</tt> + rethrow) is
"to signify an exception arising in user code, not the iostreams package".
<p/>
In addition, I found the following words in unformatted input
function's requirements (27.7.2.3 [istream.unformatted]):
</p>
<blockquote><p>
If an exception is thrown during input then <tt>ios::badbit</tt> is turned on
in <tt>*this</tt>'s error state. (Exceptions thrown from <tt>basic_ios&lt;&gt;::clear()</tt>
are not caught or rethrown.)  If <tt>(exceptions()&amp;badbit) != 0</tt> then the
exception is rethrown.
</p></blockquote>
<p>
The content within the parenthesis is added by LWG defect <a href="lwg-defects.html#61">61</a>,
and does fix the ambiguity. However, it only fixed the 1 of 4
requirements, and it lost some context (the word "rethrown" is not
seen before this sentence within this section).
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

[<i>Drafting note:</i> The editor is kindly asked to introduce additional spaces at the following marked occurrences of
<tt>operator&amp;</tt> &mdash; <i>end drafting note</i>]

<ol>
<li><p>Modify 27.7.2.2.1 [istream.formatted.reqmts] p1 as indicated:</p>

<blockquote><p>
-1- Each formatted input function begins execution by constructing an object of class <tt>sentry</tt> with the <tt>noskipws</tt>
(second) argument false. If the <tt>sentry</tt> object returns true, when converted to a value of type <tt>bool</tt>, the
function endeavors to obtain the requested input. If an exception<ins>, other than the ones thrown from <tt>clear()</tt>, if any,</ins> 
is thrown during input then <tt>ios::badbit</tt>
is turned on[Footnote 314] in <tt>*this</tt>'s error state. If <tt>(exceptions()<ins> </ins>&amp;<ins> </ins>badbit) != 0</tt> 
then the exception is rethrown.
In any case, the formatted input function destroys the <tt>sentry</tt> object. If no exception has been thrown, it returns <tt>*this</tt>.
</p></blockquote>
</li>

<li><p>Modify 27.7.3.6.1 [ostream.formatted.reqmts] p1 as indicated:</p>

<blockquote><p>
-1- Each formatted output function begins execution by constructing an object of class <tt>sentry</tt>. If this object
returns true when converted to a value of type <tt>bool</tt>, the function endeavors to generate the requested
output. If the generation fails, then the formatted output function does <tt>setstate(ios_base::failbit)</tt>,
which might throw an exception. If an exception<ins>, other than the ones thrown from <tt>clear()</tt>, if any,</ins> is thrown 
during output, then <tt>ios::badbit</tt> is turned on[Footnote 327]
in <tt>*this</tt>'s error state. If <tt>(exceptions()<ins> </ins>&amp;<ins> </ins>badbit) != 0</tt> then the exception is rethrown. 
Whether or not
an exception is thrown, the <tt>sentry</tt> object is destroyed before leaving the formatted output function. If no
exception is thrown, the result of the formatted output function is <tt>*this</tt>.
</p></blockquote>
</li>

<li><p>Modify 27.7.3.7 [ostream.unformatted] p1 as indicated:</p>

<blockquote><p>
-1- Each unformatted output function begins execution by constructing an object of class <tt>sentry</tt>. If this object
returns true, while converting to a value of type <tt>bool</tt>, the function endeavors to generate the requested
output. If an exception<ins>, other than the ones thrown from <tt>clear()</tt>, if any,</ins> is thrown during output, 
then ios::badbit is turned on[Footnote 330] in <tt>*this</tt>'s error state.
If <tt>(exceptions() &amp; badbit) != 0</tt> then the exception is rethrown. In any case, the unformatted output
function ends by destroying the <tt>sentry</tt> object, then, if no exception was thrown, returning the value specified
for the unformatted output function.
</p></blockquote>
</li>

<li><p>Modify 27.7.2.3 [istream.unformatted] p1 as indicated:</p>

<blockquote><p>
-1- Each unformatted input function begins execution by constructing an object of class <tt>sentry</tt> with the default
argument <tt>noskipws</tt> (second) argument true. If the <tt>sentry</tt> object returns true, when converted to a value
of type <tt>bool</tt>, the function endeavors to obtain the requested input. Otherwise, if the <tt>sentry</tt> constructor exits
by throwing an exception or if the sentry object returns false, when converted to a value of type <tt>bool</tt>, the
function returns without attempting to obtain any input. In either case the number of extracted characters
is set to <tt>0</tt>; unformatted input functions taking a character array of non-zero size as an argument shall also
store a null character (using <tt>charT()</tt>) in the first location of the array. If an exception<ins>, other than the 
ones thrown from <tt>clear()</tt>, if any,</ins> is thrown during input
then <tt>ios::badbit</tt> is turned on[Footnote 317] in <tt>*this</tt>'s error state. <del>(Exceptions thrown from 
<tt>basic_ios&lt;&gt;::clear()</tt> are not caught or rethrown.)</del> If <tt>(exceptions()<ins> </ins>&amp;<ins> </ins>badbit) != 0</tt> 
then the exception is rethrown. It also counts the number of characters extracted. If no exception has been thrown it ends 
by storing the count in a member object and returning the value specified. In any event the <tt>sentry</tt> object is destroyed 
before leaving the unformatted input function.
</p></blockquote>
</li>

</ol>






<hr>
<h3><a name="2351"></a>2351. Does <tt>.seed()</tt> completely reset state of engine?</h3>
<p><b>Section:</b> 26.5.3 [rand.eng] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2013-12-02 <b>Last modified:</b> 2014-02-14</p>
<p><b>View all other</b> <a href="lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
With regard to Random number engine class templates 26.5.3 [rand.eng],
the Standard can be read in two different ways: when the member function
</p>
<blockquote><pre>
.seed(result_type s = default_seed)
</pre></blockquote>
<p>
is invoked, is all associated state (such as carry) reset to the same
state that would have been created by the constructor
</p>
<blockquote><pre>
explicit <em>engine-type</em>(result_type s = default_seed)
</pre></blockquote>
<p>
or is the exact state unspecified?
<p/>
Implementations differ.
</p>

<p><i>[2014-02-13, Issaquah]</i></p>

<p>
Walter Brown says that Table 117 makes this very clear, and that the answer is "Yes"
<p/>
Suggested resolution: NAD
</p>



<p><b>Proposed resolution:</b></p>
<p>
Suggested resolution: NAD
</p>





<hr>
<h3><a name="2352"></a>2352. Is a default-constructed <tt>std::seed_seq</tt> intended to produce a predictable <tt>.generate()</tt>?</h3>
<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2013-12-02 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
With respect to class <tt>seed_seq</tt> 26.5.7.1 [rand.util.seedseq], is a default-constructed 
<tt>std::seed_seq</tt> intended to produce a predictable <tt>.generate()</tt> sequence?
<p/>
Implementations differ.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2353"></a>2353. <tt>std::next</tt> is over-constrained</h3>
<p><b>Section:</b> 24.4.4 [iterator.operations] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2013-12-24 <b>Last modified:</b> 2014-02-11</p>
<p><b>View all other</b> <a href="lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In LWG <a href="lwg-defects.html#1011">1011</a>, <tt>std::next</tt> and <tt>std::prev</tt> were changed 
from accepting <tt>InputIterator</tt> to accepting
<tt>ForwardIterator</tt>. This needlessly excludes perfectly legitimate use
cases. Consider the following hypothetical range-based implementation of
drop, which creates a view of a range without the first <tt>n</tt> elements:
</p>
<blockquote><pre>
template&lt;typename Distance, typename InputRange&gt;
iterator_range&lt;range_iterator_t&lt;InputRange&gt;&gt;
drop(Distance n, InputRange&amp; rng)
{
  return make_iterator_range(
    std::next(std::begin(rng), n),
    std::end(rng)
  );
}
</pre></blockquote>
<p>
I believe this to be a legitimate use case that is currently outlawed by
the standard without cause. See the discussion beginning at
<a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=35313">c++std-lib-35313</a> 
for an in-depth discussion of the issue, in which
Howard Hinnant agreed that it was a defect.
<p/>
(Some discussion then ensued about whether an overload should be added
that only accepts rvalue <tt>InputIterators</tt> to avoid the surprise that issue
<a href="lwg-defects.html#1011">1011</a> sought to address. I make no such attempt, nor do I believe it to
be necessary.)
<p/>
Suggested resolution:
<p/>
Back out the resolution of <a href="lwg-defects.html#1011">1011</a>.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

<ol>
<li><p>Change 24.3 [iterator.synopsis], header <tt>&lt;iterator&gt;</tt> synopsis, and 24.4.4 [iterator.operations]
before p.6 as indicated:</p>

<blockquote><pre>
template &lt;class <del>Forward</del><ins>Input</ins>Iterator&gt;
  <del>Forward</del><ins>Input</ins>Iterator next(<del>Forward</del><ins>Input</ins>Iterator x,
    typename std::iterator_traits&lt;<del>Forward</del><ins>Input</ins>Iterator&gt;::difference_type n = 1);
</pre></blockquote>
</li>

</ol>





<hr>
<h3><a name="2354"></a>2354. Unnecessary copying when inserting into maps with braced-init syntax</h3>
<p><b>Section:</b> 23.4.4.1 [map.overview], 23.4.5.1 [multimap.overview], 23.5.4.1 [unord.map.overview], 23.5.5.1 [unord.multimap.overview] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Geoffrey Romer <b>Opened:</b> 2014-01-08 <b>Last modified:</b> 2014-02-27</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The rvalue-reference <tt>insert()</tt> members of <tt>map</tt>, <tt>multimap</tt>, <tt>unordered_map</tt>, and 
<tt>unordered_multimap</tt> are specified as function templates, where the rvalue-reference parameter type 
depends on the template parameter. 
As a consequence, these overloads cannot be invoked via braced-initializer syntax (e.g. <tt>my_map.insert({key, value})</tt>), 
because the template argument cannot be deduced from a braced-init-list. Such calls instead resolve to the 
const lvalue reference overload, which forces a non-elidable copy of the argument, despite the fact that the 
argument is an rvalue, and so should be eligible for moving and copy elision.
<p/>
This leads to sub-optimal performance for copyable values, and makes this syntax unusable with noncopyable 
values. This is particularly problematic because sources such as Josuttis's "C++ Standard Library" recommend 
this syntax as the preferred way to insert into a map in C++11.
<p/>
I think this can be fixed by adding an equivalent non-template <tt>value_type&amp;&amp;</tt> overload for each affected 
member template. Simply declaring these members in the class synopses should be sufficient; their semantics are 
already dictated by the container concepts (c.f. the corresponding lvalue-reference overloads, which have no 
additional discussion beyond being listed in the synopsis).
</p>

<p><i>[2012-02-13 Issaquah]</i></p>

<p>
AJM: Is this not better solved by <tt>emplace</tt>?
</p>

<p>
Nico: <tt>emplace</tt> was a mistake, it breaks a uniform pattern designed into the STL.
Hence, this fix is important, it should be the preferred way to do this.
</p>

<p>
JonW: <tt>emplace</tt> is still more efficient, as this form must make a non-elidable copy.
</p>

<p>
GeoffR: Also, cannot move from a <tt>const</tt> key, must always make a copy.
</p>

<p>
Poll for adopting the proposed wording:  
<p/>
SF: 1 WF: 4 N: 4 WA: 1 SA: 0 
</p>

<p>
Move to Ready, pending implementation experience.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

<ol>
<li><p>Change 23.4.4.1 [map.overview], class template <tt>map</tt> synopsis, as indicated:</p>

<blockquote><pre>
[&hellip;]
pair&lt;iterator, bool&gt; insert(const value_type&amp; x);
<ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; x);</ins>
template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);
iterator insert(const_iterator position, const value_type&amp; x);
<ins>iterator insert(const_iterator position, value_type&amp;&amp; x);</ins>
template &lt;class P&gt;
  iterator insert(const_iterator position, P&amp;&amp;);
[&hellip;]
</pre></blockquote>
</li>

<li><p>Change 23.4.5.1 [multimap.overview], class template <tt>multimap</tt> synopsis, as indicated:</p>

<blockquote><pre>
[&hellip;]
iterator insert(const value_type&amp; x);
<ins>iterator insert(value_type&amp;&amp; x);</ins>
template &lt;class P&gt; iterator insert(P&amp;&amp; x);
iterator insert(const_iterator position, const value_type&amp; x);
<ins>iterator insert(const_iterator position, value_type&amp;&amp; x);</ins>
template &lt;class P&gt; iterator insert(const_iterator position, P&amp;&amp; x);
[&hellip;]
</pre></blockquote>
</li>

<li><p>Change 23.5.4.1 [unord.map.overview], class template <tt>unordered_map</tt> synopsis, as indicated:</p>

<blockquote><pre>
[&hellip;]
pair&lt;iterator, bool&gt; insert(const value_type&amp; obj);
<ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; obj);</ins>
template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);
iterator insert(const_iterator hint, const value_type&amp; obj);
<ins>iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
template &lt;class P&gt; iterator insert(const_iterator hint, P&amp;&amp; obj);
[&hellip;]
</pre></blockquote>
</li>

<li><p>Change 23.5.5.1 [unord.multimap.overview], class template <tt>unordered_multimap</tt> synopsis, as indicated:</p>

<blockquote><pre>
[&hellip;]
iterator insert(const value_type&amp; obj);
<ins>iterator insert(value_type&amp;&amp; obj);</ins>
template &lt;class P&gt; iterator insert(P&amp;&amp; obj);
iterator insert(const_iterator hint, const value_type&amp; obj);
<ins>iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
template &lt;class P&gt; iterator insert(const_iterator hint, P&amp;&amp; obj);
[&hellip;]
</pre></blockquote>
</li>

</ol>





<hr>
<h3><a name="2358"></a>2358. Apparently-bogus definition of <tt>is_empty</tt> type trait</h3>
<p><b>Section:</b> 20.10.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2014-02-01 <b>Last modified:</b> 2014-02-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The 'Condition' for <tt>std::is_empty</tt> is listed as:
</p>
<blockquote><p>
"<tt>T</tt> is a class type, but not a union type, with no non-static data members other than bit-fields of length 0, 
no virtual member functions, no virtual base classes, and no base class <tt>B</tt> for which <tt>is_empty&lt;B&gt;::value</tt> 
is false."
</p></blockquote>
<p>
This is incorrect: there is no such thing as a non-static data member that is a bit-field of length 0, since bit-fields of 
length 0 must be unnamed, and unnamed bit-fields are not members (see 9.6 [class.bit] p2).
<p/>
It also means that classes such as:
</p>
<blockquote><pre>
struct S {
 int : 3;
};
</pre></blockquote>
<p>
are empty (because they have no non-static data members). There's implementation divergence on the value of 
<tt>is_empty&lt;S&gt;::value</tt>.
<p/>
I'm not sure what the purpose of <tt>is_empty</tt> is (or how it could be useful), but if it's desirable for the above type to 
not be treated as empty, something like this could work:
</p>
<blockquote><p>
"<tt>T</tt> is a class type, but not a union type, with no non-static data members <del>other than</del><ins>, no unnamed</ins> 
bit-fields of <ins>non-zero</ins> length <del>0</del>, no virtual member functions, no virtual base classes, and no base class 
<tt>B</tt> for which <tt>is_empty&lt;B&gt;::value</tt> is false."
</p></blockquote>
<p>
and if the above type <em>should</em> be treated as empty, then this might be appropriate:
</p>
<blockquote><p>
"<tt>T</tt> is a class type, but not a union type, with no <ins>(named)</ins> non-static data members <del>other than bit-fields of 
length 0</del>, no virtual member functions, no virtual base classes, and no base class <tt>B</tt> for which 
<tt>is_empty&lt;B&gt;::value</tt> is false."
</p></blockquote>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2361"></a>2361. Apply 2299 resolution throughout library</h3>
<p><b>Section:</b> 20.8.1.2 [unique.ptr.single], 20.7.3.1 [pointer.traits.types], 20.7.7.1 [allocator.uses.trait], 20.7.8.1 [allocator.traits.types], 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-02-14 <b>Last modified:</b> 2014-05-23</p>
<p><b>View other</b> <a href="lwg-index-open.html#unique.ptr.single">active issues</a> in [unique.ptr.single].</p>
<p><b>View all other</b> <a href="lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="lwg-defects.html#2299">2299</a> addressed a N.B. comment pointing out that recently added
wording about a type existing was not clear what happens if the type
exists but is inaccessible. There are 16 pre-existing uses of the same
language in the library that should use the same wording used to
resolve 2299.
</p>

<p>
The relevant paragraphs are:
</p>

<p>
20.8.1.2 [unique.ptr.single]
<p/>
20.7.3.1 [pointer.traits.types]
<p/>
20.7.7.1 [allocator.uses.trait]
<p/>
20.7.8.1 [allocator.traits.types]
<p/>
23.2.3 [sequence.reqmts]
</p>

<p><i>[2014-05-16, Daniel provides wording]</i></p>


<p><i>[2014-05-18 Library reflector vote]</i></p>

<p>
The issue has been identified as Tentatively Ready based on six votes in favour.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 20.7.3.1 [pointer.traits.types] as indicated:</p>

<blockquote>
<pre>
typedef <i>see below</i> element_type;
</pre>
<blockquote>
<p>
-1- <i>Type</i>: <tt>Ptr::element_type</tt> if <del>such a type exists</del><ins>the qualified-id <tt>Ptr::element_type</tt> is
valid and denotes a type (14.8.2 [temp.deduct])</ins>; otherwise, <tt>T</tt> if <tt>Ptr</tt> is a class template instantiation
of the form <tt>SomePointer&lt;T, Args&gt;</tt>, where <tt>Args</tt> is zero or more type arguments; otherwise, the
specialization is ill-formed.
</p>
</blockquote>

<pre>
typedef <i>see below</i> difference_type;
</pre>
<blockquote>
<p>
-2- <i>Type</i>: <tt>Ptr::difference_type</tt> if <del>such a type exists</del><ins>the qualified-id <tt>Ptr::difference_type</tt> is
valid and denotes a type (14.8.2 [temp.deduct])</ins>; otherwise, <tt>std::ptrdiff_t</tt>.
</p>
</blockquote>

<pre>
template &lt;class U&gt; using rebind = <i>see below</i>;
</pre>
<blockquote>
<p>
-3- <i>Alias template</i>: <tt>Ptr::rebind&lt;U&gt;</tt> if <del>such a type exists</del><ins>the qualified-id 
<tt>Ptr::rebind&lt;U&gt;</tt> is valid and denotes a type (14.8.2 [temp.deduct])</ins>; otherwise, 
<tt>SomePointer&lt;U, Args&gt;</tt> if <tt>Ptr</tt> is a class template instantiation of the form <tt>SomePointer&lt;T, Args&gt;</tt>, 
where <tt>Args</tt> is zero or more type arguments; otherwise, the instantiation of <tt>rebind</tt> is ill-formed.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.7.7.1 [allocator.uses.trait] p1 as indicated:</p>

<blockquote>
<pre>
template &lt;class T, class Alloc&gt; struct uses_allocator;
</pre>
<blockquote>
<p>
-1- <i>Remark<ins>s</ins></i>: automatically detects whether <tt>T</tt> has a nested <tt>allocator_type</tt> that is 
convertible from <tt>Alloc</tt>. Meets the <tt>BinaryTypeTrait</tt> requirements (20.10.1). The implementation shall provide a definition
that is derived from <tt>true_type</tt> if <del>a type</del><ins>the qualified-id</ins> <tt>T::allocator_type</tt> <del>exists</del><ins>is
valid and denotes a type (14.8.2 [temp.deduct])</ins> and <tt>is_convertible&lt;Alloc, T::allocator_type&gt;::value != false</tt>, 
otherwise it shall be derived from <tt>false_type</tt>. [&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.7.8.1 [allocator.traits.types] as indicated:</p>

<blockquote>
<pre>
typedef <i>see below</i> pointer;
</pre>
<blockquote>
<p>
-1- <i>Type</i>: <tt>Alloc::pointer</tt> if <del>such a type exists</del><ins>the qualified-id <tt>Alloc::pointer</tt> is
valid and denotes a type (14.8.2 [temp.deduct])</ins>; otherwise, <tt>value_type*</tt>.
</p>
</blockquote>

<pre>
typedef <i>see below</i> const_pointer;
</pre>
<blockquote>
<p>
-2- <i>Type</i>: <tt>Alloc::const_pointer</tt> if <del>such a type exists</del><ins>the qualified-id <tt>Alloc::const_pointer</tt> is
valid and denotes a type (14.8.2 [temp.deduct])</ins>; otherwise, 
<tt>pointer_traits&lt;pointer&gt;::rebind&lt;const value_type&gt;</tt>.
</p>
</blockquote>

<pre>
typedef <i>see below</i> void_pointer;
</pre>
<blockquote>
<p>
-3- <i>Type</i>: <tt>Alloc::void_pointer</tt> if <del>such a type exists</del><ins>the qualified-id <tt>Alloc::void_pointer</tt> is
valid and denotes a type (14.8.2 [temp.deduct])</ins>; otherwise, 
<tt>pointer_traits&lt;pointer&gt;::rebind&lt;void&gt;</tt>.
</p>
</blockquote>

<pre>
typedef <i>see below</i> const_void_pointer;
</pre>
<blockquote>
<p>
-4- <i>Type</i>: <tt>Alloc::const_void_pointer</tt> if <del>such a type exists</del><ins>the qualified-id 
<tt>Alloc::const_void_pointer</tt> is valid and denotes a type (14.8.2 [temp.deduct])</ins>; otherwise, 
<tt>pointer_traits&lt;pointer&gt;::rebind&lt;const void&gt;</tt>.
</p>
</blockquote>

<pre>
typedef <i>see below</i> difference_type;
</pre>
<blockquote>
<p>
-5- <i>Type</i>: <tt>Alloc::difference_type</tt> if <del>such a type exists</del><ins>the qualified-id 
<tt>Alloc::difference_type</tt> is valid and denotes a type (14.8.2 [temp.deduct])</ins>; otherwise, 
<tt>pointer_traits&lt;pointer&gt;::difference_type</tt>.
</p>
</blockquote>

<pre>
typedef <i>see below</i> size_type;
</pre>
<blockquote>
<p>
-6- <i>Type</i>: <tt>Alloc::size_type</tt> if <del>such a type exists</del><ins>the qualified-id 
<tt>Alloc::size_type</tt> is valid and denotes a type (14.8.2 [temp.deduct])</ins>; otherwise, 
<tt>make_unsigned_t&lt;difference_type&gt;</tt>.
</p>
</blockquote>

<pre>
typedef <i>see below</i> propagate_on_container_copy_assignment;
</pre>
<blockquote>
<p>
-7- <i>Type</i>: <tt>Alloc::propagate_on_container_copy_assignment</tt> if <del>such a type exists</del><ins>the qualified-id 
<tt>Alloc::propagate_on_container_copy_assignment</tt> is valid and denotes a type (14.8.2 [temp.deduct])</ins>; otherwise, 
<tt>false_type</tt>.
</p>
</blockquote>

<pre>
typedef <i>see below</i> propagate_on_container_move_assignment;
</pre>
<blockquote>
<p>
-8- <i>Type</i>: <tt>Alloc::propagate_on_container_move_assignment</tt> if <del>such a type exists</del><ins>the qualified-id 
<tt>Alloc::propagate_on_container_move_assignment</tt> is valid and denotes a type (14.8.2 [temp.deduct])</ins>; otherwise, 
<tt>false_type</tt>.
</p>
</blockquote>

<pre>
typedef <i>see below</i> propagate_on_container_swap;
</pre>
<blockquote>
<p>
-9- <i>Type</i>: <tt>Alloc::propagate_on_container_swap</tt> if <del>such a type exists</del><ins>the qualified-id 
<tt>Alloc::propagate_on_container_swap</tt> is valid and denotes a type (14.8.2 [temp.deduct])</ins>; otherwise, 
<tt>false_type</tt>.
</p>
</blockquote>

<pre>
template &lt;class T&gt; using rebind_alloc = <i>see below</i>;
</pre>
<blockquote>
<p>
-10- <i>Alias template</i>: <tt>Alloc::rebind&lt;T&gt;::other</tt> if <del>such a type exists</del><ins>the qualified-id 
<tt>Alloc::rebind&lt;T&gt;::other</tt> is valid and denotes a type (14.8.2 [temp.deduct])</ins>; otherwise, 
<tt>Alloc&lt;T, Args&gt;</tt> if <tt>Alloc</tt> is a class template instantiation of the form <tt>Alloc&lt;U, Args&gt;</tt>, 
where <tt>Args</tt> is zero or more type arguments; otherwise, the instantiation of <tt>rebind_alloc</tt> is ill-formed.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.8.1.2 [unique.ptr.single] p3 as indicated:</p>

<blockquote><p>
-3- If the <del>type</del><ins>qualified-id</ins> <tt>remove_reference_t&lt;D&gt;::pointer</tt> <del>exists</del><ins>is 
valid and denotes a type (14.8.2 [temp.deduct])</ins>, then <tt>unique_ptr&lt;T, D&gt;::pointer</tt> shall be a synonym
for <tt>remove_reference_t&lt;D&gt;::pointer</tt>. [&hellip;]
</p></blockquote>
</li>

<li><p>Change 23.2.3 [sequence.reqmts] p3 as indicated:</p>

<blockquote><p>
-3- In Tables 100 and 101, <tt>X</tt> denotes a sequence container class, <tt>a</tt> denotes a value of <tt>X</tt> containing elements
of type <tt>T</tt>, <tt>A</tt> denotes <tt>X::allocator_type</tt> if <del>it exists</del><ins>the qualified-id 
<tt>X::allocator_type</tt> is valid and denotes a type (14.8.2 [temp.deduct])</ins> and <tt>std::allocator&lt;T&gt;</tt> 
if it doesn't, [&hellip;]
</p></blockquote>
</li>


</ol>






<hr>
<h3><a name="2362"></a>2362. unique, associative <tt>emplace()</tt> should not move/copy the <tt>mapped_type</tt> constructor arguments when no insertion happens</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts], 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2014-02-15 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>a_uniq.emplace(args)</tt> is specified as:
</p>

<blockquote><p>
<i>Effects</i>: Inserts a value_type object <tt>t</tt> constructed with<br/>
<tt>std::forward&lt;Args&gt;(args)...</tt> if and only if there is no element in the<br/>
container with key equivalent to the key of <tt>t</tt>. The <tt>bool</tt> component of<br/>
the returned pair is true if and only if the insertion takes place,<br/>
and the iterator component of the pair points to the element with key<br/>
equivalent to the key of <tt>t</tt>. 
</p></blockquote>

<p>
However, we occasionally find code of the form:
</p>

<blockquote><pre>
std::unique_ptr&lt;Foo&gt; p(new Foo);
auto res = m.emplace("foo", std::move(p));
</pre></blockquote>

<p>
where we'd like to avoid destroying the <tt>Foo</tt> if the insertion doesn't
take place (if the container already had an element with the specified key).
<p/>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3873">N3873</a> includes
a partial solution to this in the form of a new <tt>emplace_stable</tt> member function, but LEWG's 
discussion strongly agreed that we'd rather have <tt>emplace()</tt> Just Work:
<p/>
Should <tt>map::emplace()</tt> be guaranteed not to move/copy its arguments if the insertion doesn't happen?
<p/>
SF: 8 F: 3 N: 0 A: 0 SA: 0
<p/>
This poll was marred by the fact that we didn't notice or call out
that <tt>emplace()</tt> must construct the key before doing the lookup, and it
must not then move the key after it determines whether an insert is
going to happen, and the <tt>mapped_type</tt> instance must live next to the key.
<p/>
The very similar issue <a href="lwg-closed.html#2006">2006</a> was previously marked NAD, with
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3178.htm">N3178</a> as
discussion. However, given LEWG's interest in the alternate behavior,
we should reopen the question in this issue.
<p/>
We will need a paper that describes how to implement this before we can make more progress.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2363"></a>2363. Defect in 30.4.1.4.1 [thread.sharedtimedmutex.class]</h3>
<p><b>Section:</b> 30.4.1.4.1 [thread.sharedtimedmutex.class] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2014-02-16 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
30.4.1.4.1 [thread.sharedtimedmutex.class] paragraph 2: 
</p>
<blockquote><p> The class <tt>shared_timed_mutex</tt> shall satisfy all of the 
<tt>SharedTimedMutex</tt> requirements (30.4.1.4). It shall be a standard layout class (Clause 9).
</p></blockquote> 
<p>
There's no <tt>SharedTimedMutex</tt> requirements; this name doesn't appear anywhere else in the standard. (Prior to N3891, 
this was <tt>SharedMutex</tt>, which was equally undefined.)
<p/>
I assume this concept should be defined somewhere?
<p/>
Also, n3891 changes 30.4.1.4 [thread.sharedtimedmutex.requirements] from defining "shared mutex type" to defining 
"shared timed mutex type", but its paragraph 2 still talks about "shared mutex type". Is that OK? I think you could argue 
that it's clear enough what it means, but presumably it should use the term that paragraph 1 defined.
<p/>
30.4.2.3 [thread.lock.shared] paragraph 1 talks about the "shared mutex requirements", which again is a term that isn't 
defined, and presumably means "the requirements on a shared timed mutex type" or similar (maybe if <tt>SharedMutex</tt> or 
<tt>SharedTimedMutex</tt> were defined it could be reused here).
</p>

<p><i>[2014-05-22, Daniel comments]</i></p>

<p>
As for <tt>SharedTimedMutex</tt>, there exists a similar problem in regard to <tt>TimedMutex</tt> referred to in
30.4.1.3.1 [thread.timedmutex.class] p2 and in 30.4.1.3.2 [thread.timedmutex.recursive] p2, but nowhere defined.
<p/>
Another problem is, that according to 30.4.1.2.1 [thread.mutex.class] p3, "The class <tt>mutex</tt> shall satisfy all the 
<tt>Mutex</tt> requirements (30.4.1 [thread.mutex.requirements]).", but there are no concrete <tt>Mutex</tt> requirements,
30.4.1 [thread.mutex.requirements] &mdash; titled as "Mutex requirements" &mdash; describes <em>mutex types</em>,
<em>timed mutex types</em>, and <em>shared timed mutex types</em>.
</p>

<p><i>[2014-06-08, Daniel comments and provides wording]</i></p>

<p>
The presented wording adds to the existing <em>mutex types</em>, <em>timed mutex types</em>, and <em>shared timed mutex types</em> 
terms a new set of corresponding <tt>MutexType</tt>, <tt>TimedMutexType</tt>, and <tt>SharedTimedMutexType</tt> requirements. 
<p/>
The reason for the change of requirement names is two-fold: First, the new name better matches the intention to have a concrete 
name for the requirements imposed on the corresponding <em>mutex types</em> (This kind of requirement deviate from the more general
<tt>Lockable</tt> requirements, which are not restricted to a explicitly enumerated set of library types). Second, using 
<tt>**MutexType</tt> over <tt>**Mutex</tt> provides the additional advantage that it reduces the chances of confusing named 
requirements from template parameters named <tt>Mutex</tt> (such as for <tt>unique_lock</tt> or <tt>shared_lock</tt>).
<p/>
Nonetheless the here presented wording has one unfortunate side-effect: Once applied it would have the effect that types
used to instantiate <tt>std::shared_lock</tt> cannot be user-defined shared mutex types due to 30.4.2.3 [thread.lock.shared]. 
The reason is based on the currently lack of an existing <tt>SharedLockable</tt> requirement set, which would complete the 
existing <tt>BasicLockable</tt> and <tt>Lockable</tt> requirements (which are "real" requirements). This restriction is not
actually a problem introduced by the provided resolution but instead one that existed before but becomes more obvious now.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 30.4.1.2 [thread.mutex.requirements.mutex] as indicated:</p>

<blockquote><p>
-1- The <em>mutex types</em> are the standard library types <tt>std::mutex</tt>, <tt>std::recursive_mutex</tt>, <tt>std::timed_mutex</tt>,
<tt>std::recursive_timed_mutex</tt>, and <tt>std::shared_timed_mutex</tt>. They shall meet the <ins><tt><em>MutexType</em></tt></ins> 
requirements set out in this section. In this description, <tt>m</tt> denotes an object of a mutex type.
</p></blockquote>
</li>

<li><p>Change 30.4.1.2.1 [thread.mutex.class] as indicated:</p>

<blockquote><p>
-3- The class <tt>mutex</tt> shall satisfy all the <tt>Mutex<ins>Type</ins></tt> requirements 
(<ins>30.4.1.2 [thread.mutex.requirements.mutex]</ins><del>30.4.1 [thread.mutex.requirements]</del>). 
It shall be a standard-layout class (Clause 9).
</p></blockquote>
</li>

<li><p>Change 30.4.1.2.2 [thread.mutex.recursive] as indicated:</p>

<blockquote><p>
-2- The class <tt>recursive_mutex</tt> shall satisfy all the <del>Mutex</del><ins><tt>MutexType</tt></ins> requirements 
(<ins>30.4.1.2 [thread.mutex.requirements.mutex]</ins><del>30.4.1 [thread.mutex.requirements]</del>). 
It shall be a standard-layout class (Clause 9).
</p></blockquote>
</li>

<li><p>Change 30.4.1.3 [thread.timedmutex.requirements] as indicated:</p>

<blockquote><p>
-1- The <em>timed mutex types</em> are the standard library types <tt>std::timed_mutex</tt>, <tt>std::recursive_timed_mutex</tt>,
and <tt>std::shared_timed_mutex</tt>. They shall meet the <ins><tt><em>TimedMutexType</em></tt></ins> requirements set out below. 
In this description, <tt>m</tt> denotes an object of a mutex type, <tt>rel_time</tt> denotes an object of an instantiation of 
<tt>duration</tt> (20.12.5), and <tt>abs_time</tt> denotes an object of an instantiation of <tt>time_point</tt> (20.12.6).
</p></blockquote>
</li>

<li><p>Change 30.4.1.3.1 [thread.timedmutex.class] as indicated:</p>

<blockquote><p>
-2- The class <tt>timed_mutex</tt> shall satisfy all of the <tt>TimedMutex<ins>Type</ins></tt> requirements 
(30.4.1.3 [thread.timedmutex.requirements]). It shall be a standard-layout class (Clause 9).
</p></blockquote>
</li>

<li><p>Change 30.4.1.3.2 [thread.timedmutex.recursive] as indicated:</p>

<blockquote><p>
-2- The class <tt>recursive_timed_mutex</tt> shall satisfy all of the <tt>TimedMutex<ins>Type</ins></tt> requirements 
(30.4.1.3 [thread.timedmutex.requirements]). It shall be a standard-layout class (Clause 9).
</p></blockquote>
</li>

<li><p>Change 30.4.1.4 [thread.sharedtimedmutex.requirements] as indicated: [<i>Drafting note</i>: The reference to the
timed mutex types requirements has been moved <em>after</em> introducing the new requirement set to ensure that 
<tt>SharedTimedMutexType</tt> <em>refine</em> <tt>TimedMutexType</tt>.]</p>

<blockquote>
<p>
-1- The standard library type <tt>std::shared_timed_mutex</tt> is a <em>shared timed mutex type</em>. Shared timed mutex
types shall meet the <ins><tt><em>SharedTimedMutexType</em></tt></ins> requirements <del>of timed mutex types 
(30.4.1.3 [thread.timedmutex.requirements]), and additionally shall meet the requirements</del> set out below. In this 
description, <tt>m</tt> denotes an object of a mutex type, <tt>rel_type</tt> denotes
an object of an instantiation of <tt>duration</tt> (20.12.5), and <tt>abs_time</tt> denotes an object of an instantiation of
<tt>time_point</tt> (20.12.6).
<p/>
<ins>-?- The shared timed mutex types shall meet the <tt>TimedMutexType</tt> requirements (30.4.1.3 [thread.timedmutex.requirements]).</ins>
</p>
</blockquote>
</li>

<li><p>Change 30.4.1.4.1 [thread.sharedtimedmutex.class] as indicated:</p>

<blockquote><p>
-2- The class <tt>shared_timed_mutex</tt> shall satisfy all of the <tt>SharedTimedMutex<ins>Type</ins></tt> requirements 
(30.4.1.4 [thread.sharedtimedmutex.requirements]). It shall be a standard-layout class (Clause 9).
</p></blockquote>
</li>

<li><p>Change 30.4.2.3 [thread.lock.shared] as indicated: [<i>Drafting note</i>: Once 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3995.htm">N3995</a> has been applied, the following 
reference should be changed to the new <tt>SharedMutexType</tt> requirements ([thread.sharedmutex.requirements]) or 
even better to some new <tt>SharedLockable</tt> requirements (to be defined) &mdash; <i>end drafting note</i>]</p>

<blockquote><p>
-1- [&hellip;] The supplied <tt>Mutex</tt> type shall meet the <del>shared mutex</del><ins><tt>SharedTimedMutexType</tt></ins> requirements 
(30.4.1.4 [thread.sharedtimedmutex.requirements]).
<p/>
-2- [<i>Note</i>: <tt>shared_lock&lt;Mutex&gt;</tt> meets the <tt>TimedLockable</tt> requirements 
(30.2.5.4). &mdash; <i>end note</i>]
</p></blockquote>
</li>
</ol>






<hr>
<h3><a name="2364"></a>2364. <tt>deque</tt> and <tt>vector</tt> <tt>pop_back</tt> don't specify iterator invalidation requirements</h3>
<p><b>Section:</b> 23.3.3.4 [deque.modifiers], 23.3.6.5 [vector.modifiers] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Deskin Miller <b>Opened:</b> 2014-02-17 <b>Last modified:</b> 2014-07-01</p>
<p><b>View all other</b> <a href="lwg-index.html#deque.modifiers">issues</a> in [deque.modifiers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I think it's obvious that <tt>vector::pop_back</tt> invalidates the path-the-end iterator, but I cannot find language that says so to 
my satisfaction in the Standard. N3797 23.2.3 [sequence.reqmts] Table 101 lists <tt>a.pop_back()</tt> semantics as "Destroys the 
last element", but nowhere do I see this required to invalidate the end iterator (or iterators previously referring to the last element). 
 [container.reqmts.general]/11 states "Unless otherwise specified (either explicitly or by defining a function in terms of 
other functions), invoking a container member function or passing a container as an argument to a library function shall not 
invalidate iterators to, or change the values of, objects within that container." 23.3.6.5 [vector.modifiers]/3 says that each 
flavor of <tt>vector::erase</tt> "Invalidates iterators and references at or after the point of the erase", but <tt>pop_back</tt> isn't 
discussed, and it wasn't specified in terms of <tt>erase</tt>.
</p>
<p>
Similarly for <tt>std::deque</tt>, 23.2.3 [sequence.reqmts] Table 101 and  [container.reqmts.general]/11 both apply. 
Yet 23.3.3.4 [deque.modifiers] likewise doesn't discuss <tt>pop_back</tt> nor <tt>pop_front</tt>. Furthermore paragraph 4 fails to 
specify the iterator-invalidation guarantees when erasing the first element but not the last.
<p/>
Both <tt>std::vector</tt> and <tt>std::deque</tt> are in contrast to <tt>std::list</tt>, which says in 23.3.5.4 [list.modifiers]/3 
regarding <tt>pop_back</tt> (as well as all forms of <tt>erase</tt>, <tt>pop_front</tt>, and <tt>clear</tt>) "Effects: Invalidates only 
the iterators and references to the erased elements."
</p>

<p><i>[2014-06-16 Jonathan comments and improves wording]</i></p>


<p>
I believe this reflects our preferred form discussed earlier,
specifically putting the signatures with the <tt>erase</tt> signatures, so that
the full specification of <tt>erase()</tt> applies to the <tt>pop_xxx()</tt> functions.
This covers the case for <tt>deque</tt> where <tt>pop_front()</tt> erases the only
element (which is both the first and last element).
<p/>
Open question: the "erase" wording talks about "An erase operation" &mdash;
are <tt>pop_front</tt> and <tt>pop_back</tt> clearly covered by "erase operations"? I
believe so, as 23.3.3.1 [deque.overview]/1 and other places talk about "insert
and erase operations" which covers <tt>push</tt>/<tt>pop</tt> functions too. I've added
a note which could be used to clarify that if desired.
</p>

<strong>Previous resolution [SUPERSEDED]:</strong>
<p/>
<blockquote class="note">
<p>This wording is relative to N3936.</p> 

<ol>
<li><p>Change 23.3.3.4 [deque.modifiers] as indicated:</p>

<blockquote>
<pre>
iterator erase(const_iterator position);
iterator erase(const_iterator first, const_iterator last);
</pre>
<blockquote><p>
-4- <i>Effects</i>: An erase operation that erases the last element of a deque invalidates only the past-the-end
iterator and all iterators and references to the erased elements. An erase operation that erases the first
element of a deque but not the last element invalidates only <ins>iterators and references to</ins> the erased elements. 
An erase operation that erases neither the first element nor the last element of a deque invalidates the past-the-end iterator
and all iterators and references to all the elements of the deque.
<p/>
-5- [&hellip;]
<p/>
-6- [&hellip;]
</p>
</blockquote>

<pre>
<ins>void pop_front();
void pop_back();</ins>
</pre>
<blockquote><p>
<ins>-?- <i>Effects</i>: <tt>pop_front</tt> invalidates iterators and references to the first element of the <tt>deque</tt>. 
<tt>pop_back</tt> invalidates the past-the-end iterator, and all iterators and references to the last element of the <tt>deque</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 23.3.6.5 [vector.modifiers] as indicated:</p>
<blockquote>
<blockquote>
<p>
-5- [&hellip;]
</p>
</blockquote>

<pre>
<ins>void pop_back();</ins>
</pre>
<blockquote><p>
<ins>-?- <i>Effects</i>: Invalidates the past-the-end iterator, and iterators and references to the last element of the vector.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2014-06-21 Rapperswil]</i></p>

<p>
Tony van Eerd: Would be good to define "an erase operation is ..." somewhere.
<p/>
AM: The containers clause is known to be suboptimal in many ways.
<p/>
Looks good 
</p>



<p><b>Proposed resolution:</b></p>

<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 23.3.3.4 [deque.modifiers] as indicated:</p>

<blockquote>
<pre>
iterator erase(const_iterator position);
iterator erase(const_iterator first, const_iterator last);
<ins>void pop_front();
void pop_back();</ins>
</pre>
<blockquote><p>
-4- <i>Effects</i>: An erase operation that erases the last element of a deque invalidates only the past-the-end
iterator and all iterators and references to the erased elements. An erase operation that erases the first
element of a deque but not the last element invalidates only <ins>iterators and references to</ins> the erased elements. 
An erase operation that erases neither the first element nor the last element of a deque invalidates the past-the-end iterator
and all iterators and references to all the elements of the deque. <ins>[<i>Note</i>: <tt>pop_front</tt> and <tt>pop_back</tt> 
are erase operations &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 23.3.6.5 [vector.modifiers] as indicated:</p>
<blockquote>
<pre>
iterator erase(const_iterator position);
iterator erase(const_iterator first, const_iterator last);
<ins>void pop_back();</ins>
</pre>
<blockquote><p>
-3- <i>Effects</i>: Invalidates iterators and references at or after the point of the erase.
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2365"></a>2365. Missing <tt>noexcept</tt> in <tt>shared_ptr::shared_ptr(nullptr_t)</tt></h3>
<p><b>Section:</b> 20.8.2.2 [util.smartptr.shared] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Cassio Neri <b>Opened:</b> 2014-02-13 <b>Last modified:</b> 2014-05-02</p>
<p><b>View other</b> <a href="lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The declaration and definition of <tt>shared_ptr::shared_ptr(nullptr_t)</tt>, given in 20.8.2.2 [util.smartptr.shared], is 
</p>
<blockquote><pre>
constexpr shared_ptr(nullptr_t) : shared_ptr() { }
</pre></blockquote>
<p>
The intention seems clear: this constructor should have the same semantics of the default constructor. However, contrarily to the 
default constructor, this one is not <tt>noexcept</tt>. In contrast, <tt>unique_ptr::unique_ptr(nullptr_t)</tt> is <tt>noexcept</tt>, 
as per 20.8.1.2 [unique.ptr.single]: 
</p>
<blockquote><pre>
constexpr unique_ptr(nullptr_t) noexcept : unique_ptr() { }
</pre></blockquote>
<p>
Both libstdc++ and libc++ have added <tt>noexcept</tt> to <tt>shared_ptr::shared_ptr(nullptr_t)</tt>. Microsoft's STL has not.
</p>

<p><i>[2014-03-26 Library reflector vote]</i></p>

<p>
The issue has been identified as Tentatively Ready based on six votes in favour.
</p>



<p><b>Proposed resolution:</b></p>

<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change class template <tt>shared_ptr</tt> synopsis, 20.8.2.2 [util.smartptr.shared], as indicated:</p>

<blockquote>
<pre>
constexpr shared_ptr(nullptr_t) <ins>noexcept</ins> : shared_ptr() { }
</pre>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2366"></a>2366. <tt>istreambuf_iterator</tt> end-of-stream equality</h3>
<p><b>Section:</b> 24.6.3 [istreambuf.iterator] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Hyman Rosen <b>Opened:</b> 2014-02-19 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all other</b> <a href="lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Given the following code,
</p>
<blockquote><pre>
#include &lt;sstream&gt;

std::stringbuf buf;
std::istreambuf_iterator&lt;char&gt; begin(&amp;buf);
std::istreambuf_iterator&lt;char&gt; end;
</pre></blockquote>
<p>
it is not clear from the wording of the Standard whether <tt>begin.equal(end)</tt>
must be true. In at least one implementation it is not (CC: Sun C++ 5.10 SunOS_sparc Patch 128228-25 2013/02/20) and in at least
one implementation it is (gcc version 4.3.2 x86_64-unknown-linux-gnu).
<p/>
24.6.3 [istreambuf.iterator] says that <tt>end</tt> is an end-of-stream iterator since it was default
constructed. It also says that an iterator becomes equal to an end-of-stream
iterator when end of stream is reached by <tt>sgetc()</tt> having returned <tt>eof()</tt>.
24.6.3.5 [istreambuf.iterator::equal] says that <tt>equal()</tt> returns true iff both iterators are end of stream
or not end of stream. But there seems to be no requirement that <tt>equal</tt> check for end-of-stream by calling <tt>sgetc()</tt>. 
<p/>
Jiahan Zi at BloombergLP discovered this issue through his code failing to
work correctly. Dietmar K&uuml;hl has opined in a private communication that
the iterators should compare equal.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2367"></a>2367. <tt>pair</tt> and <tt>tuple</tt> are not correctly implemented for <tt>is_constructible</tt> with no args</h3>
<p><b>Section:</b> 20.10.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2014-02-19 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider:
</p>
<blockquote><pre>
struct X
{
  X() = delete;
};

int main()
{
  typedef std::pair&lt;int, X&gt; P;
  static_assert(!std::is_constructible&lt;P&gt;::value, "");
  static_assert(!std::is_default_constructible&lt;P&gt;::value, "");
  typedef std::tuple&lt;int, X&gt; T;
  static_assert(!std::is_constructible&lt;T&gt;::value, "");
  static_assert(!std::is_default_constructible&lt;T&gt;::value, "");
}
</pre></blockquote>
<p>
For me these <tt>static_asserts</tt> fail. And worse than that, even asking the question fails (as opposed to gets the wrong answer):
</p>
<blockquote><pre>
assert(!std::is_constructible&lt;P&gt;::value);
</pre></blockquote>
<p>
In file included from test.cpp:2:
</p>
<blockquote><pre>
error:
      call to deleted constructor of 'X'
   pair() : first(), second() {}
                     ^
note: function has been explicitly marked deleted here
    X() = delete;
    ^
1 error generated.
</pre></blockquote>
<p>
This can be solved by specializing <tt>is_constructible</tt> on <tt>pair</tt> and <tt>tuple</tt> for zero Args:
</p>
<blockquote><pre>
template &lt;class T, class U&gt;
struct is_constructible&lt;pair&lt;T, U&gt;&gt;
  : integral_constant&lt;bool, is_default_constructible&lt;T&gt;::value &amp;&amp;
                            is_default_constructible&lt;U&gt;::value&gt;
{};

template &lt;class ...T&gt;
struct is_constructible&lt;tuple&lt;T...&gt;&gt;
  : integral_constant&lt;bool,
                      __all&lt;is_default_constructible&lt;T&gt;::value...&gt;::value&gt;
{};
</pre></blockquote>
<p>
Now everything just works.
</p>

<p><i>[2014-05-14, Daniel comments]</i></p>


<p>
The proposed resolution is incomplete, because it wouldn't work for <i>cv</i>-qualified objects of
<tt>pair</tt> or for references of them during reference-initialization.
<p/>
I would like to point out that the approach suggested in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3739.html">N3739</a>
can be easily extended to solve the problem without need to muddle with specializing <tt>is_constructible</tt>:
</p>
<blockquote><pre>
template&lt;class U1 = T1, class U2 = T2,
  typename enable_if&lt;
    is_default_constructible&lt;U1&gt;::value &amp;&amp; is_default_constructible&lt;U2&gt;::value
  , bool&gt;::type = false
&gt;
constexpr pair();
</pre></blockquote>
<p>
The new wording proposal represents an alternative wording change that I would strongly prefer.
</p>

<strong>Previous resolution from Howard [SUPERSEDED]:</strong>
<p/>
<blockquote class="note">
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Add to 20.3.3 [pairs.spec]:</p>

<blockquote>
<pre>
<ins>template &lt;class T, class U&gt;
struct is_constructible&lt;pair&lt;T, U&gt;&gt;
  : integral_constant&lt;bool, is_default_constructible&lt;T&gt;::value &amp;&amp;
                            is_default_constructible&lt;U&gt;::value&gt;
{};</ins>
</pre>
</blockquote>
</li>

<li><p>Add to 20.4.2.9 [tuple.special]:</p>

<blockquote>
<pre>
<ins>template &lt;class ...T&gt;
struct is_constructible&lt;tuple&lt;T...&gt;&gt;
  : integral_constant&lt;bool, <i>see below</i>&gt;
{};</ins>
</pre>
<blockquote><p>
<ins>-?- The second argument to <tt>integral_constant</tt> shall be true if for each <tt>T</tt>, 
<tt>is_default_constructible&lt;T&gt;::value</tt> is true.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 20.3.2 [pairs.pair] around p3 as indicated:</p>

<blockquote><pre>
constexpr pair();
</pre>
<blockquote>
<p>
<del>-3- <i>Requires</i>: <tt>is_default_constructible&lt;first_type&gt;::value</tt> is true and 
<tt>is_default_constructible&lt;second_type&gt;::value</tt> is true.</del>
<p/>
-4- <i>Effects</i>: Value-initializes first and second.
<p/>
<ins>-?- <i>Remarks</i>: This constructor shall not participate in overload resolution unless 
<tt>is_default_constructible&lt;first_type&gt;::value</tt> is true and 
<tt>is_default_constructible&lt;second_type&gt;::value</tt> is true. [<i>Note</i>: This behaviour can be implemented
by a constructor template with default template arguments &mdash; <i>end note</i>].</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.4.2.1 [tuple.cnstr] around p4 as indicated:</p>

<blockquote><pre>
constexpr tuple();
</pre>
<blockquote>
<p>
<del>-4- <i>Requires</i>: <tt>is_default_constructible&lt;<i>T<sub>i</sub></i>&gt;::value</tt> is true for all <i>i</i>.</del>
<p/>
-5- <i>Effects</i>: Value initializes each element.
<p/>
<ins>-?- <i>Remarks</i>: This constructor shall not participate in overload resolution unless 
<tt>is_default_constructible&lt;<i>T<sub>i</sub></i>&gt;::value</tt> is true for all <i>i</i>. [<i>Note</i>: This behaviour can 
be implemented by a constructor template with default template arguments &mdash; <i>end note</i>].</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2368"></a>2368. Replacing global <tt>operator new</tt></h3>
<p><b>Section:</b> 18.6.1 [new.delete] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Stephen Clamage <b>Opened:</b> 2014-02-20 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all other</b> <a href="lwg-index.html#new.delete">issues</a> in [new.delete].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Section 18.6.1 [new.delete] and subsections shows:
</p>
<blockquote><pre>
void* operator new(std::size_t size);
void* operator new[](std::size_t size);
</pre></blockquote>
<p>
That is, without exception-specifications. (Recall that C++03 specified these functions with <tt>throw(std::bad_alloc)</tt>.)
<p/>
Section 17.6.5.12 [res.on.exception.handling] the end of paragraph 4 says:
</p>
<blockquote><p>
Any other functions defined in the C++ standard library that do not have an exception-specification may throw implementation-defined 
exceptions unless otherwise specified. An implementation may strengthen this implicit exception-specification by adding an explicit one.
</p></blockquote>
<p>
For example, an implementation could provide C++03-compatible declarations of <tt>operator new</tt>.
<p/>
Programmers are allowed to replace these <tt>operator new</tt> functions. But how can you write the definition of these functions when 
the exception specification can vary among implementations? For example, the declarations
</p>
<blockquote><pre>
void* operator new(std::size_t size) throw(std::bad_alloc);
void* operator new(std::size_t size);
</pre></blockquote>
<p>
are not compatible.
<p/>
From what I have been able to determine, gcc has a hack for the special case of <tt>operator new</tt> to ignore the differences in 
(at least) the two cases I show above. But can users expect all compilers to quietly ignore the incompatibility?
<p/>
The blanket permission to add any explicit exception specification could cause a problem for any user-overridable function. 
Different implementations could provide incompatible specifications, making portable code impossible to write.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2369"></a>2369. <tt>constexpr max(initializer_list)</tt> vs <tt>max_element</tt></h3>
<p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Marc Glisse <b>Opened:</b> 2014-02-21 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As part of the resolution for LWG issue <a href="lwg-defects.html#2350">2350</a>, <tt>max(initializer_list)</tt> was marked as <tt>constexpr</tt>. Looking 
at two implementations of this function (libstdc++ and libc++), both implement it in terms of <tt>max_element</tt>, which is <em>not</em> 
marked as <tt>constexpr</tt>. This is inconsistent and forces some small amount of code duplication in the implementation. Unless we 
remove <tt>constexpr</tt> from this overload of <tt>max</tt>, I believe we should add <tt>constexpr</tt> to <tt>max_element</tt>.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>In 25.1 [algorithms.general], header <tt>&lt;algorithm&gt;</tt> synopsis, and 25.4.7 [alg.min.max], change as 
indicated (add <tt>constexpr</tt> to every signature from the first <tt>min_element</tt> to the second <tt>minmax_element</tt>)::</p>

<blockquote>
<pre>
template&lt;class ForwardIterator&gt;
<ins>constexpr</ins> ForwardIterator min_element(ForwardIterator first, ForwardIterator last);
template&lt;class ForwardIterator, class Compare&gt;
<ins>constexpr</ins> ForwardIterator min_element(ForwardIterator first, ForwardIterator last,
                                      Compare comp);
[&hellip;]
template&lt;class ForwardIterator&gt;
<ins>constexpr</ins> ForwardIterator max_element(ForwardIterator first, ForwardIterator last);
template&lt;class ForwardIterator, class Compare&gt;
<ins>constexpr</ins> ForwardIterator max_element(ForwardIterator first, ForwardIterator last,
                                      Compare comp);
[&hellip;]
template&lt;class ForwardIterator&gt;
<ins>constexpr</ins> pair&lt;ForwardIterator, ForwardIterator&gt;
minmax_element(ForwardIterator first, ForwardIterator last);
template&lt;class ForwardIterator, class Compare&gt;
<ins>constexpr</ins> pair&lt;ForwardIterator, ForwardIterator&gt;
minmax_element(ForwardIterator first, ForwardIterator last, Compare comp);
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2370"></a>2370. Operations involving type-erased allocators should not be <tt>noexcept</tt> in <tt>std::function</tt></h3>
<p><b>Section:</b> 20.9.11.2 [func.wrap.func] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2014-02-27 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The following constructors in 20.9.11.2 [func.wrap.func] are declared <tt>noexcept</tt>, even
though it is not possible for an implementation to guarantee that they will not throw:
</p>

<blockquote><pre>
template &lt;class A&gt; function(allocator_arg_t, const A&amp;) noexcept;
template &lt;class A&gt; function(allocator_arg_t, const A&amp;, nullptr_t) noexcept;
</pre></blockquote>

<p>
In addition, the following functions are guaranteed not to throw if the target
is a function pointer or a <tt>reference_wrapper</tt>:
</p>

<blockquote><pre>
template &lt;class A&gt; function(allocator_arg_t, const A&amp; a, const function&amp; f);
template &lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
</pre></blockquote>

<p>
In all of the above cases, the function object might need to allocate memory
(an operation that can throw) in order to hold a copy of the type-erased
allocator itself. The first two constructors produce an empty function
object, but the allocator is still needed in case the object is later assigned
to. In this case, we note that the propagation of allocators on assignment is
underspecified for <tt>std::function</tt>. There are three possibilities:
</p>

<ol>
<li><p>The allocator is never copied on copy-assignment, moved on move-assignment, or swapped on swap.</p>
</li>

<li><p>The allocator is always copied on copy-assignment, moved on move-assignment, and swapped on swap.</p>
</li>

<li><p>Whether or not the allocator is copied, moved, or swapped is determined at
   run-time based on the <tt>propagate_on_container_copy_assignment</tt> and
   <tt>propagate_on_container_move_assignment</tt> traits of the allocators at
   construction of the source function, the target function, or both.</p>
</li>
</ol>

<p>
Although the third option seems to be the most consistent with existing
wording in the containers section of the standard, it is problematic in a
number of respects. To begin with, the propagation behavior is determined at
run time based on a pair of type-erased allocators, instead of at compile
time. Such run-time logic is <em>not</em> consistent with the rest of the standard
and is hard to reason about. Additionally, there are two allocator types
involved, rather than one. Any set of rules that attempts to rationally
interpret the propagation traits of both allocators is likely to be arcane
at best, and subtly wrong for some set of codes at worst.
</p>

<p>
The second option is a non-starter. Historically, and in the vast majority of
existing code, an allocator does not change after an object is constructed.
The second option, if adopted, would undermine the programmer's ability to
construct, e.g., an array of function objects, all using the same allocator.
</p>

<p>
The first option is (in Pablo's opinion) the simplest and best. It is
consistent with historical use of allocators, is easy to understand, and
requires minimal wording. It is also consistent with the wording in N3916,
which formalizes type-erased allocators.
</p>

<p>
For cross-referencing purposes: The resolution of this issue should be
harmonized with any resolution to LWG <a href="lwg-active.html#2062">2062</a>, which questions the <tt>noexcept</tt>
specification on the following member functions of std::function:
</p>

<blockquote><pre>
template &lt;class F&gt; function&amp; operator=(reference_wrapper&lt;F&gt;) noexcept;
void swap(function&amp;) noexcept;
</pre></blockquote>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 20.9.11.2 [func.wrap.func], class template <tt>function</tt> synopsis, as indicated:</p>

<blockquote><pre>
template &lt;class A&gt; function(allocator_arg_t, const A&amp;) <del>noexcept</del>;
template &lt;class A&gt; function(allocator_arg_t, const A&amp;, nullptr_t) <del>noexcept</del>;
</pre></blockquote>
</li>

<li><p>Change 20.9.11.2.1 [func.wrap.func.con] as indicated:</p>

<blockquote>
<p>
-1- When any function constructor that takes a first argument of type <tt>allocator_arg_t</tt> is invoked, the second
argument shall have a type that conforms to the requirements for <tt>Allocator</tt> (Table 17.6.3.5). A copy of the
allocator argument is used to allocate memory, if necessary, for the internal data structures of the constructed
function object. <ins> For the remaining constructors, an instance of <tt>allocator&lt;T&gt;</tt>, for some suitable type
<tt>T</tt>, is used to allocate memory, if necessary, for the internal data structures of the constructed function object.</ins>
</p>

<pre>
function() noexcept;
template &lt;class A&gt; function(allocator_arg_t, const A&amp;) <del>noexcept</del>;
</pre>

<blockquote>
<p>
-2- <i>Postconditions</i>: <tt>!*this</tt>.
</p>
</blockquote>

<pre>
function(nullptr_t) noexcept;
template &lt;class A&gt; function(allocator_arg_t, const A&amp;, nullptr_t) <del>noexcept</del>;
</pre>

<blockquote><p>
-3- <i>Postconditions</i>: <tt>!*this</tt>.
</p></blockquote>

<pre>
function(const function&amp; f);
<del>template &lt;class A&gt; function(allocator_arg_t, const A&amp; a, const function&amp; f);</del>
</pre>

<blockquote><p>
-4- <i>Postconditions</i>: <tt>!*this</tt> if <tt>!f</tt>; otherwise, <tt>*this</tt> targets a copy of <tt>f.target()</tt>.
</p>

<p>
-5- <i>Throws</i>: shall not throw exceptions if <tt>f</tt>'s target is a callable object passed
via <tt>reference_wrapper</tt> or a function pointer. Otherwise, may throw <tt>bad_alloc</tt>
or any exception thrown by the copy constructor of the stored callable
object. [<i>Note</i>: Implementations are encouraged to avoid the use of
dynamically allocated memory for small callable objects, for example, where
<tt>f</tt>'s target is an object holding only a pointer or reference to an object and
a member function pointer. &mdash; <i>end note</i>]
</p></blockquote>

<pre>
<ins>template &lt;class A&gt; function(allocator_arg_t, const A&amp; a, const function&amp; f);</ins>
</pre>

<blockquote><p>
<ins>-?- <i>Postconditions</i>: <tt>!*this</tt> if <tt>!f</tt>; otherwise, <tt>*this</tt> targets a copy of <tt>f.target()</tt>.</ins>
</p></blockquote>

<pre>
function(function&amp;&amp; f);
template &lt;class A&gt; function(allocator_arg_t, const A&amp; a, function&amp;&amp; f);
</pre>

<blockquote><p>
-6- <i>Effects</i>: If <tt>!f</tt>, <tt>*this</tt> has no target; otherwise, move-constructs the target
of <tt>f</tt> into the target of <tt>*this</tt>, leaving <tt>f</tt> in a valid state with an
unspecified value. <ins>If an allocator is not specified, the constructed function will use the same allocator as <tt>f</tt>.</ins>
</p></blockquote>

<pre>
template&lt;class F&gt; function(F f);
template &lt;class F, class A> function(allocator_arg_t, const A&amp; a, F f);
</pre>

<blockquote>
<p>
-7- <i>Requires</i>: <tt>F</tt> shall be <tt>CopyConstructible</tt>. 
<p/>
-8- <i>Remarks</i>: These constructors shall not participate in overload resolution unless <tt>f</tt> is Callable (20.9.11.2)
for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt>.
</p>

<p>
-9- <i>Postconditions</i>: <tt>!*this</tt> if any of the following hold:
</p>
<ul>
<li><p><tt>f</tt> is a null function pointer value.</p></li>
<li><p><tt>f</tt> is a null member pointer value.</p></li>
<li><p><tt>F</tt> is an instance of the function class template, and <tt>!f</tt></p></li>
</ul>

<p>
-10- Otherwise, <tt>*this</tt> targets a copy of <tt>f</tt> initialized with <tt>std::move(f)</tt>.
[<i>Note</i>: Implementations are encouraged to avoid the use of dynamically
allocated memory for small callable objects, for example, where <tt>f</tt>'s target
is an object holding only a pointer or reference to an object and a member
function pointer. &mdash; <i>end note</i>]
</p>

<p>
-11- <i>Throws</i>: shall not throw exceptions when <ins>an allocator is not specified
and</ins> <tt>f</tt> is a function pointer or a <tt>reference_wrapper&lt;T&gt;</tt> for some
<tt>T</tt>. Otherwise, may throw <tt>bad_alloc</tt> or any exception thrown by <tt>F</tt>'s copy or
move constructor<ins> or by <tt>A</tt>'s allocate function</ins>.
</p>
</blockquote>

</blockquote>
</li>

</ol>





<hr>
<h3><a name="2372"></a>2372. Assignment from int to <tt>std::string</tt></h3>
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Andrzej Krzemie&#324;ski <b>Opened:</b> 2014-03-13 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
<p><b>View all other</b> <a href="lwg-index.html#basic.string">issues</a> in [basic.string].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The following code works in C++:
</p>
<blockquote><pre>
int i = 300;
std::string threeHundred;
threeHundred = i;
</pre></blockquote>
<p>
"Works" == "Compiles and doesn't have an undefined behavior". But it may not be obvious and in fact misleading what it does. 
This assignment converts an <tt>int</tt> to <tt>char</tt> and then uses <tt>string</tt>'s assignment from <tt>char</tt>. While 
the assignment from <tt>char</tt> can be considered a feature, being able to assign from an int looks like a safety gap. Someone 
may believe C++ works like "dynamically typed" languages and expect a lexical conversion to take place.
<p/>
Ideally the assignment from <tt>char</tt> could be deprecated and later removed, but as a less intrusive alternative one could 
consider adding a SFINAEd deleted function template:
</p>
<blockquote><pre>
template &lt;typename IntT&gt; // enable if is_integral&lt;IntT&gt;::value
basic_string&amp; operator=(IntT) = delete;
</pre></blockquote>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>To 21.4 [basic.string], class template <tt>basic_string</tt> synopsis, add as indicated:</p>

<blockquote><pre>
basic_string&amp; operator=(const basic_string&amp; str);
basic_string&amp; operator=(basic_string&amp;&amp; str) noexcept;
basic_string&amp; operator=(const charT* s);
basic_string&amp; operator=(charT c);
<ins>template &lt;class IntT&gt; basic_string&amp; operator=(IntT i) = delete;</ins>
basic_string&amp; operator=(initializer_list&lt;charT&gt;);
</pre></blockquote>
</li>

<li><p>Add after 21.4.2 [string.cons] p26 as indicated:</p>

<blockquote>
<pre>
basic_string&amp; operator=(charT c);
</pre>
<blockquote>
<p>
-26- <i>Returns</i>: <tt>*this = basic_string(1,c)</tt>.
</p>
</blockquote>

<pre>
<ins>template &lt;class IntT&gt; basic_string&amp; operator=(IntT i) = delete;</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Remarks</i>: This signature shall not participate in overload resolution unless <tt>is_integral&lt;T&gt;::value</tt> is 
<tt>true</tt>.</ins>
</p>
</blockquote>
</blockquote>

</li>

</ol>





<hr>
<h3><a name="2373"></a>2373. Make new entities and names in namespace <tt>std</tt> conforming extensions</h3>
<p><b>Section:</b> 17.6.5 [conforming] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Chandler Carruth <b>Opened:</b> 2014-03-22 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all other</b> <a href="lwg-index.html#conforming">issues</a> in [conforming].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Technically, right now, it is not a conforming extension to add a new function to namespace <tt>std</tt>. Doing so could cause 
unqualified lookup on the name of that function in the presence of a using directive to find a different function. This seems 
an unreasonable restriction on library vendors providing conforming extensions, as such a using directive seems inherently risky 
in unqualified name lookup.
</p>
<p>
17.6.5.5 [member.functions] implies that adding overloads to a method <em>is</em> a conforming extension, and within some 
limits the same is true for global functions due to 17.6.5.4 [global.functions].
<p/>
It would likely be useful to specify that other new entities are valid conforming extensions, or preclude them where they pose 
serious compatibility problems.
</p>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2375"></a>2375. Is [iterator.requirements.general]/9 too broadly applied?</h3>
<p><b>Section:</b> 24.2.1 [iterator.requirements.general] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Marshall Clow <b>Opened:</b> 2014-03-25 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
24.2.1 [iterator.requirements.general] p9 says:
</p>
<blockquote><p>
Destruction of an iterator may invalidate pointers and references previously obtained from that iterator.
</p></blockquote>
<p>
But the resolution of LWG issue <a href="lwg-defects.html#2360">2360</a> specifically advocates returning <tt>*--temp;</tt> where <tt>temp</tt> is a 
local variable.
<p/>
And 24.2.5 [forward.iterators] p6 says:
</p>
<blockquote><p>
If <tt>a</tt> and <tt>b</tt> are both dereferenceable, then <tt>a == b</tt> if and only if <tt>*a</tt> and <tt>*b</tt> are bound 
to the same object.
</p></blockquote>
<p>
which disallows "stashing" iterators (i.e, iterators that refer to data inside themselves).
<p/>
So, I suspect that the restriction in p9 should only apply to input iterators, and can probably be moved into 
24.2.3 [input.iterators] instead of 24.2.1 [iterator.requirements.general].
</p>

<p><i>[2014-05-22, Daniel comments]</i></p>


<p>
Given that forward iterators (and beyond) are refinements of input iterator, moving this constraint to input iterators won't help
much because it would still hold for all refined forms. 
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2376"></a>2376. <tt>bad_weak_ptr::what()</tt> overspecified</h3>
<p><b>Section:</b> 20.8.2.1 [util.smartptr.weakptr] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-03-27 <b>Last modified:</b> 2014-05-02</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.8.2.1 [util.smartptr.weakptr] p2 requires <tt>bad_weak_ptr</tt> to return precisely
the string <tt>"bad_weak_ptr"</tt>.
<p/>
There was general agreement on the reflector and at the Issaquah
meeting that this is over-constrained and implementation should be
free to return something more descriptive if desired.
<p/>
The proposed resolution makes <tt>bad_weak_ptr</tt> consistent with other
exception types such as <tt>bad_alloc</tt> and <tt>bad_cast</tt>.
<p/>
If accepted, the P/R for issue <a href="lwg-active.html#2233">2233</a>, which currently uses similar
wording to <tt>bad_weak_ptr</tt>, could be updated appropriately.
</p>

<p><i>[2014-03-27 Library reflector vote]</i></p>

<p>
The issue has been identified as Tentatively Ready based on six votes in favour.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Edit 20.8.2.1 [util.smartptr.weakptr]:</p>

<blockquote>
<pre>
bad_weak_ptr() noexcept;
</pre><blockquote>
<p>
-2- <i>Postconditions</i>: <tt>what()</tt> returns <del><tt>"bad_weak_ptr"</tt></del><ins>an implementation-defined NTBS</ins>.
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2377"></a>2377. <tt>std::align</tt> requirements overly strict</h3>
<p><b>Section:</b> 20.7.5 [ptr.align] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2014-03-30 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>std::align</tt> requires that its <tt>alignment</tt> argument shall be "a fundamental alignment value or an 
extended alignment value supported by the implementation in this context".
<p/>
This requirement is overly strict. There are use cases that require a buffer aligned at values that are not tied 
to the C++ implementation, such as page size, cache line size, sector size. These come from the hardware or the 
OS and are generally not known until run time. The implementation of <tt>std::align</tt> does not depend on the 
requirement that <tt>alignment</tt> be a fundamental or an extended alignment value; any power of two would be handled 
the same way.
<p/>
In addition, it is not possible for the user to even determine whether a value is "a fundamental alignment value 
or an extended alignment value supported by the implementation in this context". One would expect values coming 
from <tt>alignof</tt> to be fine, but I'm not sure whether even that is guaranteed in the presence of <tt>alignas</tt>.
<p/>
Therefore, I propose that
</p>
<blockquote><p>
<i>Requires</i>:
</p>
<ul>
<li><p><tt>alignment</tt> shall be a fundamental alignment value or an extended alignment value supported by
the implementation in this context</p></li>
</ul>
</blockquote>
<p>
be changed to
</p>
<blockquote><p>
<i>Requires</i>:
</p>
<ul>
<li><p><tt>alignment</tt> shall be a power of two</p></li>
</ul>
</blockquote>

<p><i>[2014-06-16 Rapperswil]</i></p>

<p>
Move to Ready
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Edit 20.7.5 [ptr.align] p2 as indicated:</p>

<blockquote>
<pre>
void* align(std::size_t alignment, std::size_t size,
  void*&amp; ptr, std::size_t&amp; space);
</pre><blockquote>
<p>
-1- [&hellip;]
<p/>
-2- <i>Requires</i>:
</p>
<ul>
<li><p>
<tt>alignment</tt> shall be a <del>fundamental alignment value or an extended alignment value supported by
the implementation in this context</del><ins>power of two</ins>
</p></li>
</ul>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2378"></a>2378. Behaviour of standard exception types</h3>
<p><b>Section:</b> 18.6.2.1 [bad.alloc], 18.6.2.2 [new.badlength], 18.7.2 [bad.cast], 18.7.3 [bad.typeid], 18.8.2 [bad.exception] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2014-03-31 <b>Last modified:</b> 2014-07-01</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I think we have an issue with the specification of some of the standard exception types. 
In particular, several of them have default constructors with remarks to the effect that 
"The result of calling <tt>what()</tt> on the newly constructed object is implementation-defined". 
(In some cases this is contradictory to a further specification of <tt>what()</tt>, which 
is specified to return an implementation-defined NTBS.)
</p>

<p>
<strong>Previous resolution from Andy [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Edit 18.6.2.1 [bad.alloc] p3 as indicated:</p>

<blockquote>
<pre>
bad_alloc() noexcept;
</pre><blockquote>
<p>
[&hellip;]
<p/>
-3- <i>Remarks</i>: <del>The result of calling <tt>what()</tt> on the newly constructed object is 
  implementation-defined</del><ins><tt>what()</tt> returns an implementation-defined NTBS</ins>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 18.6.2.2 [new.badlength] p3 as indicated: [<i>Drafting note</i>: Added the Postcondition, since we don't 
say anything else about <tt>bad_array_new_length::what()</tt> &mdash; <i>end of note</i>]</p>

<blockquote>
<pre>
bad_array_new_length() noexcept;
</pre><blockquote>
<p>
[&hellip;]
<p/>
-3- <i><del>Remarks</del><ins>Postcondition</ins></i>: <del>The result of calling <tt>what()</tt> on the newly constructed object is 
  implementation-defined</del><ins><tt>what()</tt> returns an implementation-defined NTBS</ins>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 18.7.2 [bad.cast] p3 as indicated:</p>

<blockquote>
<pre>
bad_cast() noexcept;
</pre><blockquote>
<p>
[&hellip;]
<p/>
<del>-3- <i>Remarks</i>: The result of calling <tt>what()</tt> on the newly constructed object is implementation-defined.</del>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 18.7.3 [bad.typeid] p3 as indicated:</p>

<blockquote>
<pre>
bad_typeid() noexcept;
</pre><blockquote>
<p>
[&hellip;]
<p/>
<del>-3- <i>Remarks</i>: The result of calling <tt>what()</tt> on the newly constructed object is implementation-defined.</del>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 18.8.2 [bad.exception] p3 as indicated:</p>

<blockquote>
<pre>
bad_exception() noexcept;
</pre><blockquote>
<p>
[&hellip;]
<p/>
<del>-3- <i>Remarks</i>: The result of calling <tt>what()</tt> on the newly constructed object is implementation-defined.</del>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2014-06-17, Rapperswil]</i></p>

<p>
Jonathan provides alternative wording.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Edit 18.6.2.1 [bad.alloc] p3 as indicated:</p>

<blockquote>
<pre>
bad_alloc() noexcept;
</pre><blockquote>
<p>
[&hellip;]
<p/>
<del>-3- <i>Remarks</i>: The result of calling <tt>what()</tt> on the newly constructed object is 
  implementation-defined.</del>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 18.6.2.2 [new.badlength] as indicated:</p>

<blockquote>
<pre>
bad_array_new_length() noexcept;
</pre><blockquote>
<p>
[&hellip;]
<p/>
<del>-3- <i>Remarks</i>: The result of calling <tt>what()</tt> on the newly constructed object is 
  implementation-defined.</del>
</p>
</blockquote>
<pre>
<ins>virtual const char* what() const noexcept;</ins>
</pre>
<blockquote>
<ins>-?- <i>Returns</i>: An implementation-defined NTBS.</ins>
</blockquote>
</blockquote>
</li>

<li><p>Edit 18.7.2 [bad.cast] p3 as indicated:</p>

<blockquote>
<pre>
bad_cast() noexcept;
</pre><blockquote>
<p>
[&hellip;]
<p/>
<del>-3- <i>Remarks</i>: The result of calling <tt>what()</tt> on the newly constructed object is implementation-defined.</del>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 18.7.3 [bad.typeid] p3 as indicated:</p>

<blockquote>
<pre>
bad_typeid() noexcept;
</pre><blockquote>
<p>
[&hellip;]
<p/>
<del>-3- <i>Remarks</i>: The result of calling <tt>what()</tt> on the newly constructed object is implementation-defined.</del>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 18.8.2 [bad.exception] p3 as indicated:</p>

<blockquote>
<pre>
bad_exception() noexcept;
</pre><blockquote>
<p>
[&hellip;]
<p/>
<del>-3- <i>Remarks</i>: The result of calling <tt>what()</tt> on the newly constructed object is implementation-defined.</del>.
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2379"></a>2379. Obtaining native handle of the current thread</h3>
<p><b>Section:</b> 30.2.3 [thread.req.native], 30.3.2 [thread.thread.this] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2014-03-31 <b>Last modified:</b> 2014-05-02</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Class <tt>thread</tt> contains an implementation-defined type <tt>thread::native_handle_type</tt>, and an implementation-defined 
function <tt>thread::native_handle()</tt> that returns a value of that type. The presence and semantics of those members is 
implementation-defined; the intention is that they can be used for interoperability with libraries that rely on operating system 
specific features. (Posix libraries that accept arguments of type <tt>pthread_t</tt>, for example.)
<p/>
Unfortunately, there appears to be no native handle support for the equivalent of <tt>pthread_self()</tt>. We can use 
<tt>this_thread::get_id()</tt> to obtain the <tt>thread::id</tt> of the current thread, but there is no mechanism for converting 
a <tt>thread::id</tt> to a <tt>thread::native_handle</tt>.
<p/>
<em>Proposed wording:</em>
<p/>
In 30.3.2 [thread.thread.this] add:
</p>
<blockquote><pre>
thread::native_handle_type native_handle(); <i>// See 30.2.3</i>
</pre></blockquote>
<p>
 to the <tt>this_thread</tt> namespace synopsis.
<p/>
<em>Rationale:</em>
<p/>
Informally, we could address this issue either by adding a new function in <tt>this_thread</tt> or by providing a mechanism for converting 
between <tt>thread::id</tt> and <tt>thread::native_handle</tt>. I propose the former because it seems more localized, and doesn't involve 
saying anything more about implementation defined native functionality than we currently do.
<p/>
It's intentional that the proposed resolution adds a declaration of <tt>native_handle()</tt> without adding a paragraph explaining what 
it does. This is because everything about <tt>native_handle()</tt> is implementation-defined. The standard does the same thing in 
30.3.1.5 [thread.thread.member]. 
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 30.2.3 [thread.req.native] p1 as indicated:</p>

<blockquote>
<p>
-1- <del>Several classes described in this Clause have members</del><ins>This Clause includes several members named</ins> 
<tt>native_handle_type</tt> and <tt>native_handle</tt>. The presence of these members and their semantics is 
implementation-defined. [&hellip;]
</p>
</blockquote>
</li>

<li><p>In 30.3 [thread.threads], header <tt>&lt;thread&gt;</tt> synopsis, add:</p>

<blockquote>
<pre>
namespace std {
  [&hellip;]
  namespace this_thread {
    thread::id get_id() noexcept;
    <ins>thread::native_handle_type native_handle();</ins>
    [&hellip;]
  }
}
</pre>
</blockquote>
</li>

<li><p>In 30.3.2 [thread.thread.this] add:</p>
<blockquote>
<pre>
namespace std {
  namespace this_thread {
    thread::id get_id() noexcept;
    <ins>thread::native_handle_type native_handle(); <i>// See 30.2.3 [thread.req.native]</i></ins>
    [&hellip;]
  }
}
</pre>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2380"></a>2380. May <tt>&lt;cstdlib&gt;</tt> provide <tt>long ::abs(long)</tt> and <tt>long long ::abs(long long)</tt>?</h3>
<p><b>Section:</b> 17.6.1.2 [headers] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2014-03-31 <b>Last modified:</b> 2014-07-01</p>
<p><b>View all other</b> <a href="lwg-index.html#headers">issues</a> in [headers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>
<p>
D.5 [depr.c.headers] p3 says:
</p>
<blockquote><p>
[<i>Example</i>: The header <tt>&lt;cstdlib&gt;</tt> assuredly provides its declarations and definitions within the namespace
<tt>std</tt>. It may also provide these names within the global namespace. The header <tt>&lt;stdlib.h&gt;</tt> assuredly
provides the same declarations and definitions within the global namespace, much as in the C Standard. It
may also provide these names within the namespace <tt>std</tt>. &mdash; <i>end example</i>]
</p></blockquote>
<p>
This suggests that <tt>&lt;cstdlib&gt;</tt> may provide <tt>::abs(long)</tt> and <tt>::abs(long long)</tt>. But this seems like 
it might contradict the normative wording of 17.6.1.2 [headers] p4:
</p>
<blockquote><p>
Except as noted in Clauses 18 through 30 and Annex D, the contents of each header <tt>c<em>name</em></tt> shall be the same
as that of the corresponding header <tt><em>name</em>.h</tt>, as specified in the C standard library (1.2) or the C Unicode
TR, as appropriate, as if by inclusion. In the C++ standard library, however, the declarations (except for
names which are defined as macros in C) are within namespace scope (3.3.6) of the namespace <tt>std</tt>. It is
unspecified whether these names are first declared within the global namespace scope and are then injected
into namespace <tt>std</tt> by explicit using-declarations (7.3.3).
</p></blockquote>
<p>
Note that this allows <tt>&lt;cstdlib&gt;</tt> to provide <tt>::abs(int)</tt>, but does not obviously allow <tt>::abs(long)</tt> 
nor <tt>::abs(long long)</tt>, since they are not part of the header <tt>stdlib.h</tt> as specified in the C standard library.
<p/>
26.8 [c.math] p7 adds signatures <tt>std::abs(long)</tt> and <tt>std::abs(long long)</tt>, but not in a way that seems 
to allow <tt>::abs(long)</tt> and <tt>::abs(long long)</tt> to be provided.
<p/>
I think the right approach here would be to allow <tt>&lt;cstdlib&gt;</tt> to either provide no <tt>::abs</tt> declaration, or 
to provide all three declarations from namespace <tt>std</tt>, but it should not be permitted to provide only <tt>int abs(int)</tt>. 
Suggestion:
<p/>
Change in 17.6.1.2 [headers] p4:
</p>
<blockquote><p>
[&hellip;]. It is unspecified whether these names <ins>(including any overloads added in Clauses 18 through 30 and Annex D)</ins> 
are first declared within the global namespace scope and are then injected into namespace <tt>std</tt> by explicit using-declarations 
(7.3.3).
</p></blockquote>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Modify 17.6.1.2 [headers] p4 as indicated:</p>

<blockquote><p>
Except as noted in Clauses 18 through 30 and Annex D, the contents of each header <tt>c<em>name</em></tt> shall be the same
as that of the corresponding header <tt><em>name</em>.h</tt>, as specified in the C standard library (1.2) or the C Unicode
TR, as appropriate, as if by inclusion. In the C++ standard library, however, the declarations (except for
names which are defined as macros in C) are within namespace scope (3.3.6) of the namespace <tt>std</tt>. It is
unspecified whether these names <ins>(including any overloads added in Clauses 18 through 30 and Annex D)</ins> are first 
declared within the global namespace scope and are then injected into namespace <tt>std</tt> by explicit using-declarations (7.3.3).
</p></blockquote>
</li>
</ol>






<hr>
<h3><a name="2381"></a>2381. Inconsistency in parsing floating point numbers</h3>
<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Marshall Clow <b>Opened:</b> 2014-04-30 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all other</b> <a href="lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 22.4.2.1.2 [facet.num.get.virtuals] we have:
</p>
<blockquote><p>
Stage 3: The sequence of chars accumulated in stage 2 (the field) is converted to a numeric value by the
rules of one of the functions declared in the header <tt>&lt;cstdlib&gt;</tt>:
</p>
<ul>
<li><p>For a signed integer value, the function <tt>strtoll</tt>.</p></li>
<li><p>For an unsigned integer value, the function <tt>strtoull</tt>.</p></li>
<li><p>For a floating-point value, the function <tt>strtold</tt>.</p></li>
</ul>
</blockquote>
<p>
This implies that for many cases, this routine should return true:
</p>
<blockquote><pre>
bool is_same(const char* p) 
{
  std::string str{p};
  double val1 = std::strtod(str.c_str(), nullptr);
  std::stringstream ss(str);
  double val2;
  ss &gt;&gt; val2;
  return std::isinf(val1) == std::isinf(val2) &amp;&amp;                 // either they're both infinity
         std::isnan(val1) == std::isnan(val2) &amp;&amp;                 // or they're both NaN
         (std::isinf(val1) || std::isnan(val1) || val1 == val2); // or they're equal
}
</pre></blockquote>
<p>
and this is indeed true, for many strings:
</p>
<blockquote><pre>
assert(is_same("0"));
assert(is_same("1.0"));
assert(is_same("-1.0"));
assert(is_same("100.123"));
assert(is_same("1234.456e89"));
</pre></blockquote>
<p>
but not for others
</p>
<blockquote><pre>
assert(is_same("0xABp-4")); // hex float
assert(is_same("inf"));
assert(is_same("+inf"));
assert(is_same("-inf"));
assert(is_same("nan"));
assert(is_same("+nan"));
assert(is_same("-nan"));

assert(is_same("infinity"));
assert(is_same("+infinity"));
assert(is_same("-infinity"));
</pre></blockquote>
<p>
These are all strings that are correctly parsed by <tt>std::strtod</tt>, but not by the stream extraction operators.
They contain characters that are deemed invalid in stage 2 of parsing.
<p/>
If we're going to say that we're converting by the rules of <tt>strtold</tt>, then we should accept all the things that 
<tt>strtold</tt> accepts.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2382"></a>2382. Unclear order of container update versus object destruction on removing an object</h3>
<p><b>Section:</b> 17.6.5.8 [reentrancy] <b>Status:</b> <a href="lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> Peter Kasting <b>Opened:</b> 2014-05-06 <b>Last modified:</b> 2014-07-08</p>
<p><b>View other</b> <a href="lwg-index-open.html#reentrancy">active issues</a> in [reentrancy].</p>
<p><b>View all other</b> <a href="lwg-index.html#reentrancy">issues</a> in [reentrancy].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively NAD">Tentatively NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The standard does not seem to discuss reentrant access to a container during removal of an element, 
leaving it unclear whether a removed object is destroyed before or after it is removed from the container.  
For example, the behavior of the following code seems to be unspecified:
</p>
<blockquote><pre>
#include &lt;iostream&gt;
#include &lt;map&gt;
#include &lt;memory&gt;

struct T;
typedef std::map&lt;int, std::shared_ptr&lt;T&gt;&gt; TMap;

struct T {
  T(TMap* t_map, int index) : t_map(t_map), index(index) {}
  ~T() {
    std::cout &lt;&lt; "Object " &lt;&lt; index &lt;&lt; " is ";
    if (t_map->count(index))
      std::cout &lt;&lt; "destroyed before being removed from the map" &lt;&lt; std::endl;
    else
      std::cout &lt;&lt; "removed from the map before being destroyed" &lt;&lt; std::endl;
  }

  static void AddToMap(TMap* map, int index) {
    (*map)[index] = std::make_shared&lt;T&gt;(map, index);
  }

  TMap* t_map;
  int index;
};

int main()
{
  TMap t_map;
  T::AddToMap(&amp;t_map, 0);
  T::AddToMap(&amp;t_map, 1);
  t_map.erase(1);
  t_map.erase(0);
}
</pre></blockquote>
<p>
The output of this program in Visual Studio 2013 is:
</p>
<blockquote><pre>
Object 1 is removed from the map before being destroyed
Object 0 is destroyed before being removed from the map
</pre></blockquote>
<p>
The core issue here is whether an object removed from a container should be destroyed before or after 
it is removed from the container. The current standard seems to be silent on this issue. 
The above output demonstrates that the behavior is actually inconsistent. (It's difficult to fully 
describe Visual Studio's behavior; for example, changing <tt>main()</tt> in the above example to the following:)
</p>
<blockquote><pre>
int main()
{
  TMap t_map;
  T::AddToMap(&amp;t_map, 0);
  T::AddToMap(&amp;t_map, 1);
  T::AddToMap(&amp;t_map, 2);
  T::AddToMap(&amp;t_map, 3);
  t_map.erase(3);
  t_map.clear();
}
</pre></blockquote>
<p>
(...gives this output:)
</p>
<blockquote><pre>
Object 3 is removed from the map before being destroyed
Object 2 is destroyed before being removed from the map
Object 1 is destroyed before being removed from the map
Object 0 is removed from the map before being destroyed
</pre></blockquote>
<p>
In my opinion, the standard should explicitly describe when objects are destroyed as part of removal from a container. 
To me, it makes the most sense to say that objects should be removed from the container before they are destroyed.
</p>
<p><i>[2014-05-07, Jeffrey Yasskin comments]</i></p>

<p>
I think there are two main points here beyond this writeup:
</p>
<ol>
<li><p>We can't make recursive use of a standard library container valid
in all cases.</p></li>
<li><p>If recursion through especially <tt>erase()</tt> is undefined behavior,
that's pretty scary for existing large applications with code in
destructors. Of course, "scary" doesn't mean we have to define the
behavior.</p></li>
</ol>
<p>
I'll add a third: The language in 17.6.5.8 [reentrancy] nearly makes this
undefined behavior already. I think any fix is probably going to live
there, and extend the current "implementation-defined" on recursive
reentrancy for individual functions to recursive reentrancy on class
instances. I'm not sure exactly how to word that.
</p>

<p><i>[2014-06 Rapperswil]</i></p>

<p>
STL: We need more wording about how container methods can be reentrency.
<p/>
Jeffrey: The title for this issue is confusing, what we really want is "reentrancy for objects".
<p/>
Alisdair: Should we then close 2382 as NAD with a link to the new issue? 
</p>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2383"></a>2383. Overflow cannot be ill-formed for chrono::duration integer literals</h3>
<p><b>Section:</b> 20.12.5.8 [time.duration.literals] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-05-16 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.12.5.8 [time.duration.literals] p3 says:
</p>
<blockquote><p>
If any of these suffixes are applied to an integer literal and the
resulting <tt>chrono::duration</tt> value cannot be represented in the result
type because of overflow, the program is ill-formed.
</p></blockquote>
<p>
Ill-formed requires a diagnostic at compile-time, but there is no way
to  detect the overflow from <tt>unsigned long long</tt> to the <tt>signed
duration&lt;&gt;::rep</tt> type.
<p/>
Overflow could be detected if the duration integer literals were
literal operator templates, otherwise overflow can either be undefined
or a run-time error, not ill-formed.
</p>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2384"></a>2384. Allocator's <tt>deallocate</tt> function needs better specification</h3>
<p><b>Section:</b> 17.6.3.5 [allocator.requirements] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2014-05-19 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to Table 28, 17.6.3.5 [allocator.requirements], an <tt>Allocator</tt>'s <tt>deallocate</tt>
function is specified as follows:
</p>
<blockquote><p>
All <tt>n</tt> <tt>T</tt> objects in the area
pointed to by <tt>p</tt> shall be
destroyed prior to this call. <tt>n</tt>
shall match the value passed to
allocate to obtain this
memory. Does not throw
exceptions. [<i>Note</i>: <tt>p</tt> shall not be
singular. &mdash; <i>end note</i>]
</p></blockquote>
<p>
This wording is confusing in regard to the following points:
</p>
<ol>
<li><p>This specification does not make clear that the result of an <tt>allocate</tt>
call can only be returned once to the <tt>deallocate</tt> function. This is much
clearer expressed for <tt>operator delete</tt> (18.6.1.1 [new.delete.single] p12, emphasis mine):</p>
<blockquote><p>
<i>Requires</i>: <tt>ptr</tt> shall be a null pointer or <span style="color:#C80000;font-weight:bold">its value shall be a value returned 
by an earlier call to</span> the (possibly replaced) <span style="color:#C80000;font-weight:bold"><tt>operator new(std::size_t)</tt> or 
<tt>operator new(std::size_t,const std::nothrow_t&amp;)</tt> which has not been invalidated 
by an intervening call to <tt>operator delete(void*)</tt></span>.
</p></blockquote>
</li>
<li><p>The intended meaning of that wording was to say that <tt>deallocate</tt> shall accept <em>every</em> result value
that had been returned by a corresponding call to <tt>allocate</tt>, this includes also a possible result of a
null pointer value, which is possible ("[<i>Note</i>: If <tt>n == 0</tt>, the return value is unspecified.
&mdash; <i>end note</i>]"). Unfortunately the <tt>deallocate</tt> function uses a non-normative note ("<tt>p</tt> shall not be
singular.") which refers to the fuzzy term <tt>singular</tt>, that is one of the most unclear and misunderstood terms
of the library, as pointed out in <a href="lwg-active.html#1213">1213</a>. The occurrence of this term has lead to the possible understanding,
that this function would never allow null pointer values. Albeit for allocators the intention had not been to require the support
<em>in general</em> that a null pointer value can be provided to <tt>deallocate</tt> (as it is allowed for <tt>std::free</tt>
and <tt>operator delete</tt>), the mental model was that <em>every</em> returned value of <tt>allocate</tt> shall be an
acceptable argument type of the corresponding <tt>deallocate</tt> function.
</p>
</li>
</ol>

<p>
This issue is not intending to enforce a specific meaning of <em>singular</em> iterator values, but the assertion is
that this note does more harm than good. In addition to wording from <tt>operator delete</tt> there is no longer any need
to obfuscate the normative wording. 
</p>

<p><i>[2014-05-24 Alisdair comments]</i></p>


<p>
Now that I am reading it very precisely, there is another mis-stated assumption
as a precondition for <tt>deallocate</tt>:
</p>
<blockquote><p>
All <tt>n T</tt> objects in the area pointed to by <tt>p</tt> shall be destroyed prior to this call.
</p></blockquote>
<p>
This makes a poor assumption that every possible object in the allocated buffer
was indeed constructed, but this is often not the case, e.g., a <tt>vector</tt> that is not
filled to capacity. We should require calling the destructor for only those objects
actually constructed in the buffer, which may be fewer than <tt>n</tt>, or even 0.
<p/>
I wonder if we really require all objects to be destroyed before calling <tt>deallocate</tt>
though. Are we really so concerned about leaking objects that might not manage
resources? Should this not be the proper concern of the library managing the
objects and memory?
</p>

<p><i>[2014-06-05 Daniel responds and improves wording]</i></p>


<p>
I fully agree with the last comment and I think that this requirement should be removed. We have no such
requirements for comparable functions such as <tt>operator delete</tt> or <tt>return_temporary_buffer()</tt>,
and this wording seems to be a wording rudiment that exists since C++98.
</p>



<p><b>Proposed resolution:</b></p>

<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change Table 28 ("<tt>Allocator</tt> requirements") as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 28 &mdash; <tt>Allocator</tt> requirements</caption>
<tr>
<th align="center">Expression</th>
<th align="center">Return type</th>
<th align="center">Assertion/note<br/>pre-/post-condition</th>
<th align="center">Default</th>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>a.deallocate(p,n)</tt>
</td>
<td>
(not used)
</td>
<td>
<ins><i>Pre</i>: <tt>p</tt> shall be a value returned by an earlier<br/> 
call to <tt>allocate</tt> which has not been invalidated by<br/> 
an intervening call to <tt>deallocate</tt>. <tt>n</tt> shall<br/> 
match the value passed to <tt>allocate</tt> to obtain this<br/> 
memory.</ins> <del>All <tt>n T</tt> objects in the area pointed to by<br/> 
<tt>p</tt> shall be destroyed prior to this call.</del><br/>
<ins><i>Throws</i>: Nothing.</ins><del><tt>n</tt><br/>
shall match the value passed to<br/>
allocate to obtain this<br/>
memory. Does not throw<br/>
exceptions. [<i>Note</i>: <tt>p</tt> shall not<br/>
be singular. &mdash; <i>end note</i>]</del>
</td>
<td>
&nbsp;
</td>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

</table>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="2385"></a>2385. <tt>function::assign</tt> allocator argument doesn't make sense</h3>
<p><b>Section:</b> 20.9.11.2 [func.wrap.func] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2014-05-23 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The definition of <tt>function::assign</tt> in N3936 is:
</p>
<blockquote><pre>
template&lt;class F, class A&gt;
  void assign(F&amp;&amp; f, const A&amp; a);
</pre>
<blockquote>
<p>
<i>Effects</i>: <tt>function(allocator_arg, a, std::forward&lt;F&gt;(f)).swap(*this)</tt>
</p>
</blockquote>
</blockquote>
<p>
This definition is flawed in several respects:
</p>
<ol>
<li><p>The interface implies that the intent is to replace the allocator in <tt>*this</tt>
with the specified allocator, <tt>a</tt>.  Such functionality is unique in the
standard and is problematic when creating, e.g. a container of function
objects, all using the same allocator.</p>
</li>
<li><p>The current definition of <tt>swap()</tt> makes it unclear whether the objects being
swapped can have different allocators.  The general practice is that
allocators must be equal in order to support swap, and this practice is
reinforced by the proposed library TS. Thus, the definition of <tt>assign</tt> would
have undefined behavior unless the allocator matched the allocator already
within function.
</p>
</li>
<li><p>
The general rule for members of function is to supply the allocator before
the functor, using the <tt>allocator_arg</tt> prefix. Supplying the allocator as a
second argument, without the <tt>allocator_arg</tt> prefix is error prone and
confusing.
</p></li>
</ol>

<p>
I believe that this ill-conceived interface was introduced in the effort to
add allocators to parts of the standard where it had been missing, when we
were unpracticed in the right way to accomplish that. Allocators were added
to function at a time when the allocator model was in flux and it was the
first class in the standard after <tt>shared_ptr</tt> to use type-erased allocators, so
it is not surprising to see some errors in specification here. (<tt>shared_ptr</tt> is
a special case because of its shared semantics, and so is not a good model.)
<p/>
The main question is whether this member should be specified with better
precision or whether it should be deprecated/removed. The only way I can see to
give a "reasonable" meaning to the existing interface is to describe it in
terms of destroying and re-constructing <tt>*this</tt>:
</p>
<blockquote><pre>
function temp(allocator_arg, a, std::forward&lt;F&gt;(f));
this-&gt;~function();
::new(this) function(std::move(temp));
</pre></blockquote>
<p>
(The temp variable is needed for exception safety). The ugliness of this
specification underscores the ugliness of the concept. What is the purpose of
this member other than to reconstruct the object from scratch, a facility that
library classes do not generally provide? Programmers are always free to
destroy and re-construct objects &mdash; there is no reason why function should
make that especially easy.
<p/>
I propose, therefore, that we make no attempt at giving the current interface
a meaningful definition of questionable utility, but simply get rid of it
all together. This leaves us with only two questions:
</p>
<ol>
<li><p>Should we deprecate the interface or just remove it?</p></li>
<li><p>Should we replace it with an <tt>assign(f)</tt> member that doesn't take an
allocator?</p></li>
</ol>
<p>
Of these four combinations of binary answers to the above questions, I think
the ones that make the most sense are (remove, no) and (deprecate, yes). The
proposed new interface provides nothing that <tt>operator=</tt> does not already
provide. However, if the old (deprecated) interface remains, then having the
new interface will guide the programmer away from it.
<p/>
The proposed wording below assumes deprecation. If we choose removal, then
there is no wording needed; simply remove the offending declaration and
definition.
</p>


<p><b>Proposed resolution:</b></p>

<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change class template <tt>function</tt> synopsis, 20.9.11.2 [func.wrap.func], as indicated:</p>

<blockquote>
<pre>
template&lt;class R, class... ArgTypes&gt;
class function&lt;R(ArgTypes...)&gt; {
  [&hellip;]
  <i>// 20.9.11.2.2, function modifiers:</i>
  void swap(function&amp;) noexcept;
  template&lt;class F<del>, class A</del>&gt; void assign(F&amp;&amp;<del>, const A&amp;</del>);
  [&hellip;]
};
</pre>
</blockquote>
</li>

<li><p>Change 20.9.11.2.2 [func.wrap.func.mod] as indicated:</p>

<blockquote>
<pre>
template&lt;class F<del>, class A</del>&gt; void assign(F&amp;&amp; f<del>, const A&amp; a</del>);
</pre>
<blockquote>
<p>
<i>Effects</i>: <tt><ins>*this = forward&lt;F&gt;(f);</ins><del>function(allocator_arg, a, std::forward&lt;F&gt;(f)).swap(*this)</del></tt>
</p>
</blockquote>
</blockquote>
</li>

<li><p>To deprecation section D.8 [depr.function.objects], add the following new sub-clause:</p>

<blockquote>
<p>
<b>Old <tt>assign</tt> member of polymorphic function wrappers [depr.function.objects.assign]</b>
</p>
<blockquote>
<pre>
namespace std{
  template&lt;class R, class... ArgTypes&gt;
  class function&lt;R(ArgTypes...)&gt; {
    <i>// remainder unchanged</i>
    template&lt;class F, class A&gt; void assign(F&amp;&amp; f, const A&amp; a);
    [&hellip;]
  };
}
</pre>
</blockquote>
<p>
The two-argument form of <tt>assign</tt> is defined as follows:
</p>
<pre>
template&lt;class F, class A&gt; void assign(F&amp;&amp; f, const A&amp; a);
</pre>
<blockquote>
<p>
<i>Requires</i>: <tt>a</tt> shall be equivalent to the allocator used to construct <tt>*this</tt>.
<p/>
<i>Effects</i>: <tt>this-&gt;assign(forward&lt;F&gt;(f));</tt>
</p>
</blockquote>

</blockquote>
</li>
</ol>






<hr>
<h3><a name="2386"></a>2386. <tt>function::operator=</tt> handles allocators incorrectly</h3>
<p><b>Section:</b> 20.9.11.2.1 [func.wrap.func.con] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2014-05-23 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <i>Effects</i> clauses for the assignment operator for class template <tt>function</tt> are
written as code that constructs a temporary <tt>function</tt> and then swaps it with <tt>*this</tt>.
The intention appears to be that assignment should have the strong exception 
guarantee, i.e., <tt>*this</tt> is not modified if an exception is thrown. However, the current 
description is incorrect when <tt>*this</tt> was constructed using an allocator.
<p/>
Part of the problem is the under-specification of <tt>swap</tt>, which does not state the 
allocator requirements or allocator postconditions. If <tt>swap</tt> behaves like the rest of the 
standard library, swapping function objects constructed with different allocators 
would be undefined behavior. Alternatively <tt>swap</tt> could exchange the allocators, 
though I would argue against this specification.
<p/>
For either specification of <tt>swap</tt>, the current <i>Effects</i> clauses for <tt>operator=</tt> are
incorrect. If <tt>swap</tt> does not exchange the allocators, then <tt>operator=</tt> would have 
undefined behavior, which is clearly not desired. If <tt>swap</tt> does exchange the allocators, 
then <tt>operator=</tt> would always leave the left-hand side (lhs) of the assignment with a 
default allocator. The latter would be surprising behavior, as the allocator instance is 
normally unchanged for the lifetime of an object (for good reason), and is certainly not 
reset to default arbitrarily.
<p/>
The desired behavior is that assignment would leave the allocator of the lhs
unchanged. The way to achieve this behavior is to construct the temporary <tt>function</tt> 
using the original allocator. Unfortunately, we cannot describe the desired behavior in 
pure code, because there is no way to name the type-erased value of the allocator. 
(N3916 would improve this situation for the Library Fundamentals TS, but even with 
those changes, there is no way to recover the original type of the allocator.) The PR 
below, therefore, uses pseudo-code, inventing a fictitious <tt><i>ALLOCATOR_OF</i>(f)</tt> 
expression that evaluates to the actual allocator type, even if that allocator was type 
erased. I have implemented this PR successfully.
</p>


<p><b>Proposed resolution:</b></p>

<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 20.9.11.2.1 [func.wrap.func.con] as indicated:</p>

<blockquote>
<p>
<ins>In the following descriptions, <tt><i>ALLOCATOR_OF</i>(f)</tt> is a copy of the allocator specified in the 
construction of <tt>function</tt> <tt>f</tt>, or <tt>allocator&lt;char&gt;()</tt> if no allocator was specified.</ins>
</p>
<pre>
function&amp; operator=(const function&amp; f);
</pre>
<blockquote>
<p>
-12- <i>Effects</i>: <tt>function(<ins>allocator_arg, <i>ALLOCATOR_OF</i>(*this),</ins> f).swap(*this);</tt>
<p/>
-13- <i>Returns</i>: <tt>*this</tt>
</p>
</blockquote>
<pre>
function&amp; operator=(function&amp;&amp; f);
</pre>
<blockquote>
<p>
-14- <i>Effects</i>: <del>Replaces the target of <tt>*this</tt> with the target of <tt>f</tt>.</del><ins><tt>function(allocator_arg,
<i>ALLOCATOR_OF</i>(*this), std::move(f)).swap(*this);</tt></ins>
<p/>
-15- <i>Returns</i>: <tt>*this</tt>
</p>
</blockquote>
<pre>
function&amp; operator=(nullptr_t);
</pre>
<blockquote>
<p>
-16- <i>Effects</i>: If <tt>*this != nullptr</tt>, destroys the target of <tt>this</tt>.
<p/>
-17- <i>Postconditions</i>: <tt>!(*this)</tt>. <ins>The allocator is unchanged.</ins>
<p/>
-18- <i>Returns</i>: <tt>*this</tt>
<p/>
<ins>-?- <i>Throws</i>: Nothing.</ins>
</p>
</blockquote>
<pre>
template&lt;class F&gt; function&amp; operator=(F&amp;&amp; f);
</pre>
<blockquote>
<p>
-19- <i>Effects</i>: <tt>function(<ins>allocator_arg, <i>ALLOCATOR_OF</i>(*this),</ins> std::forward&lt;F&gt;(f)).swap(*this);</tt>
<p/>
-20- <i>Returns</i>: <tt>*this</tt>
<p/>
-21- <i>Remarks</i>: This assignment operator shall not participate in overload resolution unless 
<tt>declval&lt;typename decay&lt;F&gt;::type&amp;&gt;()</tt> is <tt>Callable</tt> (20.9.11.2) for argument types 
<tt>ArgTypes...</tt> and return type <tt>R</tt>.
</p>
</blockquote>
<pre>
template&lt;class F&gt; function&amp; operator=(reference_wrapper&lt;F&gt; f);
</pre>
<blockquote>
<p>
-22- <i>Effects</i>: <tt>function(<ins>allocator_arg, <i>ALLOCATOR_OF</i>(*this),</ins> f).swap(*this);</tt>
<p/>
-23- <i>Returns</i>: <tt>*this</tt>
</p>
</blockquote>

</blockquote>
</li>

</ol>






<hr>
<h3><a name="2387"></a>2387. More nested types that must be accessible and unambiguous</h3>
<p><b>Section:</b> 20.9.2 [func.require], 20.9.3 [refwrap] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-05-23 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.require">active issues</a> in [func.require].</p>
<p><b>View all other</b> <a href="lwg-index.html#func.require">issues</a> in [func.require].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Further to <a href="lwg-defects.html#2299">2299</a> and <a href="lwg-active.html#2361">2361</a>, 20.9.2 [func.require] p3 and 20.9.3 [refwrap] p3 and p4
talk about member types without any mention of being accessible and unambiguous.
</p>

<p><i>[2014-06-05 Daniel provides wording]</i></p>


<p><i>[2014-06-06 Library reflector vote]</i></p>

<p>
The issue has been identified as Tentatively Ready based on six votes in favour.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 20.9.2 [func.require] p3 as indicated:</p>

<blockquote><p>
-3- If a call wrapper (20.9.1) has a <i>weak result type</i> the type of its member type <tt>result_type</tt> is based on the
type <tt>T</tt> of the wrapper's target object (20.9.1):
</p>
<ul>
<li><p>if <tt>T</tt> is a pointer to function type, <tt>result_type</tt> shall be a synonym for the return type of <tt>T</tt>;</p></li>
<li><p>if <tt>T</tt> is a pointer to member function, <tt>result_type</tt> shall be a synonym for the return type of <tt>T</tt>;</p></li>
<li><p>if <tt>T</tt> is a class type <ins>and the qualified-id <tt>T::result_type</tt> is valid and denotes a type 
(14.8.2 [temp.deduct])</ins><del>with a member type <tt>result_type</tt></del>, then <tt>result_type</tt> shall be a synonym for
<tt>T::result_type</tt>;</p></li> 
<li><p>otherwise <tt>result_type</tt> shall not be defined.</p></li>
</ul>
</blockquote>
</li>

<li><p>Change 20.9.3 [refwrap] p3+p4 as indicated:</p>

<blockquote>
<p>
-3- The template instantiation <tt>reference_wrapper&lt;T&gt;</tt> shall define a nested type named <tt>argument_type</tt> as a
synonym for <tt>T1</tt> only if the type <tt>T</tt> is any of the following:
</p>
<ul>
<li><p>a function type or a pointer to function type taking one argument of type <tt>T1</tt></p></li>
<li><p>a pointer to member function <tt>R T0::f</tt> <i>cv</i> (where  <i>cv</i> represents the member function_s cv-qualifiers);
the type <tt>T1</tt> is <i>cv</i> <tt>T0*</tt></p></li> 
<li><p>a class type <ins>where the qualified-id <tt>T::argument_type</tt> is valid and denotes a type 
(14.8.2 [temp.deduct])</ins><del>with a member type <tt>argument_type</tt></del>; the type <tt>T1</tt> is 
<tt>T::argument_type</tt>.</p></li>
</ul>
<p>
-4- The template instantiation <tt>reference_wrapper&lt;T&gt;</tt> shall define two nested types named <tt>first_argument_type</tt> 
and <tt>second_argument_type</tt> as synonyms for <tt>T1</tt> and <tt>T2</tt>, respectively, only if the type <tt>T</tt> is any of the
following:
</p>
<ul>
<li><p>a function type or a pointer to function type taking two arguments of types <tt>T1</tt> and <tt>T2</tt></p></li>
<li><p>a pointer to member function <tt>R T0::f(T2)</tt> <i>cv</i> (where <i>cv</i> represents the member function's cv-qualifiers);
the type <tt>T1</tt> is <i>cv</i> <tt>T0*</tt></p></li> 
<li><p>a class type <ins>where the qualified-ids <tt>T::first_argument_type</tt> and <tt>T::second_argument_type</tt> are both valid 
and both denote types (14.8.2 [temp.deduct])</ins><del>with member types <tt>first_argument_type</tt> and 
<tt>second_argument_type</tt></del>; the type <tt>T1</tt> is <tt>T::first_argument_type</tt><del>.</del> and the type <tt>T2</tt> is 
<tt>T::second_argument_type</tt>.</p></li>
</ul>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2388"></a>2388. Handling self-assignment in the proposed library function <tt>std::exchange</tt></h3>
<p><b>Section:</b> 20.2.3 [utility.exchange] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Nick Calus <b>Opened:</b> 2014-05-09 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all other</b> <a href="lwg-index.html#utility.exchange">issues</a> in [utility.exchange].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3668.html">N3668</a>, the addition of a template function 
<tt>std::exchange</tt> had been proposed. In the rationale provided by the paper, we find the following:
</p>
<blockquote>
<p>
I chose the name for symmetry with <tt>atomic_exchange</tt>, since they behave the same except for this function not being atomic.
</p>
</blockquote>
<p>
and:
</p>
<blockquote>
<p>
Atomic objects provide an <tt>atomic_exchange</tt> function ([atomics.types.operations.req]p18) that <em>assigns a new value to the object 
and returns the old value</em>. This operation is also useful on non-atomic objects, and this paper proposes adding it to the library.
<p/>
But the specified semantics of <tt>std::exchange</tt> is defined as follows:
</p>
</blockquote>
<blockquote><pre>
template &lt;class T, class U=T&gt; T exchange(T&amp; obj, U&amp;&amp; new_val);
</pre>
<blockquote>
<p>
<i>Effects</i>: Equivalent to:
</p>
<blockquote><pre>
T old_val = std::move(obj);
obj = std::forward&lt;U&gt;(new_val);
return old_val;
</pre>
</blockquote>
</blockquote>
</blockquote>
<p>
When looking at the post-condition of the <tt>std::exchange</tt> function, one would expect the return value to be the old value 
of <tt>obj</tt> and also that <tt>obj</tt> now contains the value of <tt>new_value</tt>.
This post-condition is violated when <tt>obj</tt> is a reference to the same object as <tt>new_value</tt> and type <tt>T</tt> 
has move semantics.
<p/>
Given it's specification, it is clear that <tt>std::exchange</tt> is meant to be used with types that have move semantics.
Therefore, the post-condition is violated for self-assignments.
<p/>
Suppose the following situation:
<p/>
You have a vector of objects. The objects implement move semantics and are emptied when moved from.
You provide a function that allows you to replace an object at a specific index by a new object (provided by reference as 
an argument to your function). When replacing an object, your function calls a member-function <tt>do_something_fancy</tt> 
on the old object.
</p>
<blockquote><pre>
void your_function(int i, X&amp; new_val) {
  std::exchange(vec[i], new_val).do_something_fancy();
}
</pre></blockquote>
<p>
Your function gets called with a given index and the corresponding element of said vector. (by coincidence or by purpose, it 
doesn't really matter)
</p>
<blockquote><pre>
your_function(5, vec[5]);
</pre></blockquote>
<p>
This will cause the object at <tt>vec[5]</tt> to be in an empty state.
If this object would not implement move semantics, assignment performance is potentially worse, but at least it 
is not in an empty (to my business logic, invalid) state.
<p/>
So to me, the current reference implementation of <tt>std::exchange</tt> does not have the behavior it is expected to have.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 20.2.3 [utility.exchange] as indicated:</p>
<blockquote><pre>
template &lt;class T, class U=T&gt; T exchange(T&amp; obj, U&amp;&amp; new_val);
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: Equivalent to:
</p>
<blockquote><pre>
<ins>T tmp = std::forward&lt;U&gt;(new_val);</ins>
T old_val = std::move(obj);
obj = <del>std::forward&lt;U&gt;(new_val)</del><ins>std::move(tmp)</ins>;
return old_val;
</pre>
</blockquote>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2391"></a>2391. <tt>basic_string</tt> is missing non-<tt>const</tt> <tt>data()</tt></h3>
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Michael Bradshaw <b>Opened:</b> 2014-05-27 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
<p><b>View all other</b> <a href="lwg-index.html#basic.string">issues</a> in [basic.string].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Regarding 21.4 [basic.string], <tt>std::basic_string&lt;charT&gt;::data()</tt> returns a <tt>const charT*</tt> 
21.4.7.1 [string.accessors]. While this method is convenient, it doesn't quite match <tt>std::array&lt;T&gt;::data()</tt> 
23.3.2.5 [array.data] or <tt>std::vector&lt;T&gt;::data()</tt> 23.3.6.4 [vector.data], both of which provide two 
versions (that return <tt>T*</tt> or <tt>const T*</tt>). An additional <tt>data()</tt> method can be added to 
<tt>std::basic_string</tt> that returns a <tt>charT*</tt> so it can be used in similar situations that <tt>std::array</tt> and 
<tt>std::vector</tt> can be used. Without a non-<tt>const</tt> <tt>data()</tt> method, <tt>std::basic_string</tt> has to be treated 
specially in code that is otherwise oblivious to the container type being used.
<p/>
Adding a <tt>charT*</tt> return type to <tt>data()</tt> would be equivalent to doing <tt>&amp;str[0]</tt> or <tt>&amp;str.front()</tt>.
<p/>
Small discussion on the issue can be found <a href="http://stackoverflow.com/questions/7518732/why-are-stdvectordata-and-stdstringdata-different">here</a>
and in the <a href="https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/ll9HuEML6zo/discussion">std-discussion thread</a>  
(which didn't get too much attention).
<p/>
This requires a small change to <tt>std::basic_string</tt>'s definition in 21.4 [basic.string] to add the method to 
<tt>std::basic_string</tt>, and another small change in 21.4.7.1 [string.accessors] to define the new method.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change class template <tt>basic_string</tt> synopsis, 21.4 [basic.string], as indicated:</p>
<blockquote>
<pre>
namespace std {
  template&lt;class charT, class traits = char_traits&lt;charT&gt;,
  class Allocator = allocator&lt;charT&gt; &gt;
  class basic_string {
  public:
    [&hellip;]
    <i>// 21.4.7, string operations:</i>
    const charT* c_str() const noexcept;
    const charT* data() const noexcept;
    <ins>charT* data() noexcept;</ins>
    allocator_type get_allocator() const noexcept;
    [&hellip;]
  };
}
</pre>
</blockquote>

</li>

<li><p>Add the following sequence of paragraphs following 21.4.7.1 [string.accessors] p3, as indicated:</p>
<blockquote>
<pre>
<ins>charT* data() noexcept;</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Returns</i>: A pointer <tt>p</tt> such that <tt>p + i == &amp;operator[](i)</tt> for each <tt>i</tt> in <tt>[0,size()]</tt>.</ins>
<p/>
<ins>-?- <i>Complexity</i>: Constant time.</ins>
<p/>
<ins>-?- <i>Requires</i>: The program shall not alter the value stored at <tt>p + size()</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2392"></a>2392. "character type" is used but not defined</h3>
<p><b>Section:</b> 17.3.17 [defns.ntcts], 22.3.1.1.1 [locale.category], 27.2.2 [iostreams.limits.pos], 27.7.3.6.1 [ostream.formatted.reqmts], 27.7.3.6.4 [ostream.inserters.character] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2014-06-01 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The term "character type" is used in 17.3.17 [defns.ntcts], 22.3.1.1.1 [locale.category],
27.2.2 [iostreams.limits.pos], 27.7.3.6.1 [ostream.formatted.reqmts], and
27.7.3.6.4 [ostream.inserters.character], but the core language only defines
"narrow character types" (3.9.1 [basic.fundamental]).
<p/>
"wide-character type" is used in 22.5 [locale.stdcvt], but the core
language only defines a "wide-character set" and "wide-character literal".
</p>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2393"></a>2393. <tt>std::function</tt>'s <em>Callable</em> definition is broken</h3>
<p><b>Section:</b> 20.9.11.2 [func.wrap.func] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2014-06-03 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The existing definition of <tt>std::function</tt>'s <em>Callable</em> requirements provided in 20.9.11.2 [func.wrap.func]
p2,
</p>
<blockquote><p>
A callable object <tt>f</tt> of type <tt>F</tt> is <em>Callable</em> for argument types <tt>ArgTypes</tt> and return type 
<tt>R</tt> if the expression <tt><i>INVOKE</i>(f, declval&lt;ArgTypes&gt;()..., R)</tt>, considered as an unevaluated operand 
(Clause 5), is well formed (20.9.2).
</p></blockquote>
<p>
is defective in several aspects:
</p>
<ol style="list-style-type:upper-roman">
<li><p>The wording can be read to be defined in terms of callable objects, not of callable types.</p>
</li>
<li><p>Contrary to that, 20.9.11.2.5 [func.wrap.func.targ] p2 speaks of "<tt>T</tt> shall be a type that is <em>Callable</em> 
(20.9.11.2) for parameter types <tt>ArgTypes</tt> and return type <tt>R</tt>."</p>
</li>
<li><p>
The required value category of the callable object during the call expression (lvalue or rvalue) strongly depends on
an interpretation of the expression <tt>f</tt> and therefore needs to be specified unambiguously.
</p></li>
</ol>
<p>
The intention of original <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1402.html">proposal</a> 
(see IIIa. Relaxation of target requirements) was to refer to both types and values ("we say that the function object <tt>f</tt> 
(and its type <tt>F</tt>) is <em>Callable</em> [&hellip;]"), but that mental model is not really deducible from the
existing wording. An improved type-dependence wording would also make the sfinae-conditions specified in 20.9.11.2.1 [func.wrap.func.con] 
p8 and p21 ("[&hellip;] shall not participate in overload resolution unless <tt>f</tt> is Callable (20.9.11.2)
for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt>.") easier to interpret.
<p/>
My understanding always had been (see e.g. Howard's code example in the 2009-05-01 comment in LWG <a href="lwg-defects.html#815">815</a>), that 
<tt>std::function</tt> invokes the call operator of its target via an <b>lvalue</b>. The required value-category is relevant, 
because it allows to reflect upon whether an callable object such as
</p>
<blockquote><pre>
struct RVF 
{
  void operator()() const &amp;&amp; {}
};
</pre></blockquote>
<p>
would be a feasible target object for <tt>std::function&lt;void()&gt;</tt> or not.
<p/>
Clarifying the current <em>Callable</em> definition seems also wise to make a future transition to language-based concepts
easier. A local fix of the current wording is simple to achieve, e.g. by rewriting it as follows:
</p>
<blockquote><p>
A callable <del>object <tt>f</tt> of</del> type <ins>(20.9.1 [func.def])</ins> <tt>F</tt> is <em>Callable</em> 
for argument types <tt>ArgTypes</tt> and return type <tt>R</tt> if the expression <tt><i>INVOKE</i>(<del>f</del><ins>declval&lt;F&amp;&gt;()</ins>, 
declval&lt;ArgTypes&gt;()..., R)</tt>, considered as an unevaluated operand (Clause 5), is well formed (20.9.2).
</p></blockquote>
<p>
It seems appealing to move such a general <em>Callable</em> definition to a more "fundamental" place (e.g. as another
paragraph of 20.9.1 [func.def]), but the question arises, whether such a more general concept should impose
the requirement that the call expression is invoked on an <b>lvalue</b> of the callable object &mdash; such a
special condition would also conflict with the more general definition of the <tt>result_of</tt> trait, which
is defined for either lvalues or rvalues of the callable type <tt>Fn</tt>. In this context I would like to point out that
"<em>Lvalue-Callable</em>" is not the one and only <em>Callable</em> requirement in the library. Counter examples are
<tt>std::thread</tt>, <tt>call_once</tt>, or <tt>async</tt>, which depend on "<em>Rvalue-Callable</em>", because they 
all act on functor rvalues, see e.g. 30.3.1.2 [thread.thread.constr]:
</p>
<blockquote><p>
[&hellip;] The new thread of execution executes <tt><i>INVOKE</i>(<i>DECAY_COPY</i>(std::forward&lt;F&gt;(f)), 
<i>DECAY_COPY</i>(std::forward&lt;Args&gt;(args))...)</tt> [&hellip;]
</p></blockquote>
<p>
For every callable object <tt>F</tt>, the result of <tt><i>DECAY_COPY</i></tt> is an rvalue. These implied rvalue function calls are 
no artifacts, but had been deliberately voted for by a Committee decision (see LWG <a href="lwg-defects.html#2021">2021</a>, 2011-06-13 comment) 
and existing implementations respect these constraints correctly. Just to give an example,
</p>
<blockquote><pre>
#include &lt;thread&gt;

struct LVF 
{
  void operator()() &amp; {}
};

int main()
{
  LVF lf;
  std::thread t(lf);
  t.join();
}
</pre></blockquote>
<p>
is supposed to be rejected.
<p/>
The below presented wording changes are suggested to be minimal (still local to <tt>std::function</tt>), but the used approach
would simplify a future (second) conceptualization or any further generalization of <em>Callable</em> requirements of the Library.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 20.9.11.2 [func.wrap.func] p2 as indicated:</p>

<blockquote><p>
-2- A callable <del>object <tt>f</tt> of</del> type <ins>(20.9.1 [func.def])</ins> <tt>F</tt> is <em><ins>Lvalue-</ins>Callable</em> 
for argument types <tt>ArgTypes</tt> and return type <tt>R</tt> if the expression <tt><i>INVOKE</i>(<del>f</del><ins>declval&lt;F&amp;&gt;()</ins>, 
declval&lt;ArgTypes&gt;()..., R)</tt>, considered as an unevaluated operand (Clause 5), is well formed (20.9.2).
</p></blockquote>
</li>

<li><p>Change 20.9.11.2.1 [func.wrap.func.con] p8+p21 as indicated:</p>

<blockquote>
<pre>
template&lt;class F&gt; function(F f);
template &lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-8- <i>Remarks</i>: These constructors shall not participate in overload resolution unless <tt><del>f</del><ins>F</ins></tt> is 
<tt><ins>Lvalue-</ins>Callable</tt> (20.9.11.2) for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt>.
</p>
</blockquote>
<p>
[&hellip;]
</p>
<pre>
template&lt;class F&gt; function&amp; operator=(F&amp;&amp; f);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-21- <i>Remarks</i>: This assignment operator shall not participate in overload resolution unless 
<tt><del>declval&lt;typename decay&lt;F&gt;::type&amp;&gt;()</del><ins>decay_t&lt;F&gt;</ins></tt> is 
<tt><ins>Lvalue-</ins>Callable</tt> (20.9.11.2) for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt>.
</p>
</blockquote>

</blockquote>
</li>

<li><p>Change 20.9.11.2.5 [func.wrap.func.targ] p2 as indicated: [<i>Editorial comment</i>: Instead of adapting the preconditions
for the naming change I recommend to strike it completely, because the <tt>target()</tt> functions do not depend on it; the
corresponding wording exists since its <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1667.pdf">initial proposal</a>
and it seems without any advantage to me. Assume that some template argument <tt>T</tt> is provided, which does <em>not</em>
satisfy the requirements: The effect will be that the result is a null pointer value, but that case can happen in other (valid) situations
as well. &mdash; <i>end comment</i>]</p>

<blockquote><pre>
template&lt;class T&gt; T* target() noexcept;
template&lt;class T&gt; const T* target() const noexcept;
</pre>
<blockquote>
<p>
<del>-2- <i>Requires</i>: <tt>T</tt> shall be a type that is <tt>Callable</tt> (20.9.11.2) for parameter types 
<tt>ArgTypes</tt> and return type <tt>R</tt>.</del>
<p/>
-3- <i>Returns</i>: If <tt>target_type() == typeid(T)</tt> a pointer to the stored function target; otherwise a null
pointer.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2394"></a>2394. <tt>locale::name</tt> specification unclear &mdash; what is implementation-defined?</h3>
<p><b>Section:</b> 22.3.1.3 [locale.members] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2014-06-09 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all other</b> <a href="lwg-index.html#locale.members">issues</a> in [locale.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
22.3.1.3 [locale.members] p5 says:
</p>
<blockquote><p>
<i>Returns</i>: The name of <tt>*this</tt>, if it has one; otherwise, the string <tt>"*"</tt>. If <tt>*this</tt> has a name, then
<tt>locale(name().c_str())</tt> is equivalent to <tt>*this</tt>. Details of the contents of the resulting string are
otherwise implementation-defined.
</p></blockquote>
<p>
So&hellip; what is implementation-defined here, exactly? The first sentence <em>completely</em> defines the behavior of this function 
in all cases.
<p/>
Also, the second sentence says (effectively) that all locales with the same name are equivalent: given <tt>L1</tt> and <tt>L2</tt> 
that have the same name <tt>N</tt>, they are both equivalent to <tt>locale(N)</tt>, and since there is no definition of 
"equivalent" specific to <tt>locale</tt>, I assume it's the normal transitive equivalence property, which would imply that 
<tt>L1</tt> is equivalent to <tt>L2</tt>. I'm not sure why this central fact is in the description of <tt>locale::name</tt>, nor 
why it's written in this roundabout way.
</p>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2396"></a>2396. <tt>underlying_type</tt> doesn't say what to do for an incomplete enumeration type</h3>
<p><b>Section:</b> 20.10.7.6 [meta.trans.other] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2014-06-12 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider:
</p>
<blockquote><pre>
enum E {
  e = std::underlying_type&lt;E&gt;::type(1)
};
</pre></blockquote>
<p>
Clearly this should be ill-formed, but the library section doesn't appear to ban it. Suggestion:
<p/>
Change in 20.10.7.6 [meta.trans.other] Table 57:
</p>
<blockquote>
<p>
Template: <tt>template&lt;class T&gt; struct underlying_type;</tt>
<p/>
Condition: <tt>T</tt> shall be <ins>a complete</ins> <del>an</del> enumeration type (7.2)
<p/>
Comments: [&hellip;]
</p>
</blockquote>

<p><i>[2014-06-16 Rapperswil]</i></p>

<p>
Move to Ready
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change Table 57 &mdash; "Other transformations" as indicated:</p></li>

<blockquote>
<table border="1">
<caption>Table 3 &mdash; Other type transformations</caption>
<tr>
<th align="center">Template</th>
<th align="center">Condition</th>
<th align="center">Comments</th>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct underlying_type;</tt>
</td>
<td>
T shall be <ins>a complete</ins> <del>an</del> enumeration type (7.2)
</td>
<td align="center">
[&hellip;]
</td>
</tr>

</table>
</blockquote>

</ol>





<hr>
<h3><a name="2397"></a>2397. <tt>map&lt;K, V&gt;::emplace</tt> and explicit <tt>V</tt> constructors</h3>
<p><b>Section:</b> 20.10.7.6 [meta.trans.other] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2014-06-12 <b>Last modified:</b> 2014-06-23</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Please consider the following example:
</p>
<blockquote><pre>
#include &lt;map&gt;
#include &lt;atomic&gt;

int main()
{
   std::map&lt;int, std::atomic&lt;int&gt;&gt; map_;

   map_.emplace(1, 0);  // <span style="color:#C80000;font-weight:bold">fail</span>
   map_.emplace(1);     // <span style="color:#C80000;font-weight:bold">fail</span>
   map_.emplace(1, {}); // <span style="color:#C80000;font-weight:bold">fail</span>

   map_.emplace(std::piecewise_construct,
       std::tuple&lt;int&gt;(1), std::tuple&lt;>()); // <span style="color:#006600;font-weight:bold">OK</span>
}
</pre></blockquote>
<p>
The first three calls represent attempts by an ordinary programmer (in which role I appear today) to construct 
a map element. Since <tt>std::atomic&lt;int&gt;</tt> is non-copyable and immovable, I was naturally drawn to 
<tt>emplace()</tt> because it constructs in-place and hence doesn't need to copy or move. The logic behind the 
attempts was that <tt>K=int</tt> would be constructed from '<tt>1</tt>', and <tt>V=std::atomic&lt;int&gt;</tt> would be 
(directly) constructed by '<tt>0</tt>', default constructed, or constructed by '<tt>{}</tt>'.
<p/>
Yet none of the obvious attempts worked.
<p/>
I submit that at least two of the three ought to have worked, and that we have therefore a defect in either 
<tt>map::emplace</tt> or <tt>pair</tt>.
<p/>
Ville:
<p/>
There exists a related <a href="http://cplusplus.github.io/EWG/ewg-toc.html#114">EWG issue</a> for this.
<p/>
Daniel:
<p/>
If the proposal <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3739.html">N3739</a>
would be accepted, it would solve the problem mentioned here.
</p>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2398"></a>2398. <tt>type_info</tt>'s destructor shouldn't be required to be virtual</h3>
<p><b>Section:</b> 18.7.1 [type.info] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-06-14 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all other</b> <a href="lwg-index.html#type.info">issues</a> in [type.info].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>type_info</tt>'s destructor is depicted as being <tt>virtual</tt>, which is nearly unobservable to users (since they can't construct 
or copy this class, they can't usefully derive from it). However, it's technically observable (via <tt>is_polymorphic</tt> and 
<tt>has_virtual_destructor</tt>). It also imposes real costs on implementations, requiring them to store one vptr per 
<tt>type_info</tt> object, when RTTI space consumption is a significant concern.
<p/>
Making this implementation-defined wouldn't affect users (who can observe this only if they're specifically looking for it) and 
wouldn't affect implementations who need <tt>virtual</tt> here, but it would allow other implementations to drop <tt>virtual</tt> 
and improve their RTTI space consumption.
<p/>
Richard Smith:
<p/>
It's observable in a few other ways.
</p>
<blockquote><pre>
std::map&lt;void*, something&gt; m;
m[dynamic_cast&lt;void*&gt;(&amp;typeid(blah))] = stuff;
</pre></blockquote>
<p>
... is broken by this change, because you can't <tt>dynamic_cast</tt> a non-polymorphic class type to <tt>void*</tt>.
</p>
<blockquote><pre>
type_info&amp; f();
typeid(f());
</pre></blockquote>
<p>
... evaluates <tt>f()</tt> at runtime without this change, and might not do so with this change.
<p/>
These are probably rare things, but I can imagine at least some forms of the latter being used in SFINAE tricks.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 18.7.1 [type.info] as indicated:</p>

<blockquote>
<pre>
namespace std {
  class type_info {
  public:
    <del>virtual</del><ins><i>see below</i></ins> ~type_info();
    [&hellip;]
  };
}
</pre>
<p>
-1- The class <tt>type_info</tt> describes type information generated by the implementation. Objects of this class
effectively store a pointer to a name for the type, and an encoded value suitable for comparing two types for
equality or collating order. The names, encoding rule, and collating sequence for types are all unspecified
and may differ between programs. <ins>Whether <tt>~type_info()</tt> is <tt>virtual</tt> is implementation-defined.</ins>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2399"></a>2399. <tt>shared_ptr</tt>'s constructor from <tt>unique_ptr</tt> should be constrained</h3>
<p><b>Section:</b> 20.8.2.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-06-14 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider the following code:
</p>
<blockquote><pre>
#include &lt;iostream&gt;
#include &lt;memory&gt;
#include &lt;string&gt;

using namespace std;

void meow(const shared_ptr&lt;int&gt;&amp; sp) {
  cout &lt;&lt; "int: " &lt;&lt; *sp &lt;&lt; endl;
}

void meow(const shared_ptr&lt;string&gt;&amp; sp) {
  cout &lt;&lt; "string: " &lt;&lt; *sp &lt;&lt; endl;
}

int main() {
  meow(make_unique&lt;int&gt;(1729));
  meow(make_unique&lt;string&gt;("kitty"));
}
</pre></blockquote>
<p>
This fails to compile due to ambiguous overload resolution, but we can easily make this work. (Note: <tt>shared_ptr</tt>'s 
constructor from <tt>auto_ptr</tt> is also affected, but I believe that it's time to remove <tt>auto_ptr</tt> completely.)
</p>

<p><i>[2014-06-16 Rapperswil]</i></p>

<p>
Move to Ready
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 20.8.2.2.1 [util.smartptr.shared.const] around p33 as indicated:</p>

<blockquote>
<pre>
template &lt;class Y, class D&gt; shared_ptr(unique_ptr&lt;Y, D&gt;&amp;&amp; r);
</pre>
<p>
<ins>-?- <i>Remark</i>: This constructor shall not participate in overload resolution unless <tt>unique_ptr&lt;Y, D&gt;::pointer</tt> 
is convertible to <tt>T*</tt>.</ins>
<p/>
-33- <i>Effects</i>: Equivalent to <tt>shared_ptr(r.release(), r.get_deleter())</tt> when <tt>D</tt> is not a reference type,
otherwise <tt>shared_ptr(r.release(), ref(r.get_deleter()))</tt>.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2400"></a>2400. <tt>shared_ptr</tt>'s <tt>get_deleter()</tt> should use <tt>addressof()</tt></h3>
<p><b>Section:</b> 20.8.2.2.10 [util.smartptr.getdeleter] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-06-14 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The Standard Library should consistently use <tt>addressof()</tt> to defend itself against overloaded <tt>operator&amp;()</tt>.
<p/>
While we're in the neighbourhood, we should editorially change <tt>0</tt> to <tt>nullptr</tt>.
</p>

<p><i>[2014-06-16 Rapperswil]</i></p>

<p>
Move to Ready
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 20.8.2.2.10 [util.smartptr.getdeleter] as indicated:</p>

<blockquote>
<pre>
template &lt;class D, class T&gt; get_deleter(const shared_ptr&lt;T&gt;&amp; p) noexcept;
</pre>
<p>
-1- <i>Returns</i>: If <tt>p</tt> owns a deleter <tt>d</tt> of type cv-unqualified <tt>D</tt>, returns 
<tt><del>&amp;</del><ins>std::addressof(</ins>d<ins>)</ins></tt>; 
otherwise returns <tt><del>0</del><ins>nullptr</ins></tt>. [&hellip;]
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2401"></a>2401. <tt>std::function</tt> needs more <tt>noexcept</tt></h3>
<p><b>Section:</b> 20.9.11.2 [func.wrap.func] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-06-14 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There are two issues here:
</p>
<ol>
<li><p><tt>std::function</tt>'s constructor from <tt>nullptr_t</tt> is marked as <tt>noexcept</tt>, but its assignment operator 
from <tt>nullptr_t</tt> isn't. This assignment can and should be marked as <tt>noexcept</tt>.</p></li>
<li><p><tt>std::function</tt>'s comparisons with <tt>nullptr_t</tt> are marked as <tt>noexcept</tt> in two out of three places.</p></li>
</ol>

<p><i>[2014-06-16 Rapperswil]</i></p>

<p>
Move to Ready
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 20.9 [function.objects] p2, header <tt>&lt;functional&gt;</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  [&hellip;]
  <i>// 20.9.11 polymorphic function wrappers:</i>
  [&hellip;]
  template&lt;class R, class... ArgTypes&gt;
  bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, nullptr_t) <ins>noexcept</ins>;
  template&lt;class R, class... ArgTypes&gt;
  bool operator==(nullptr_t, const function&lt;R(ArgTypes...)&gt;&amp;) <ins>noexcept</ins>;
  template&lt;class R, class... ArgTypes&gt;
  bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, nullptr_t) <ins>noexcept</ins>;
  template&lt;class R, class... ArgTypes&gt;
  bool operator!=(nullptr_t, const function&lt;R(ArgTypes...)&gt;&amp;) <ins>noexcept</ins>;
  [&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Change 20.9.11.2 [func.wrap.func], class template <tt>function</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
[&hellip;]
<i>// 20.9.11.2.1, construct/copy/destroy:</i>
[&hellip;]
function&amp; operator=(nullptr_t) <ins>noexcept</ins>;
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Change 20.9.11.2.1 [func.wrap.func.con] before p16 as indicated:</p>

<blockquote>
<pre>
function&amp; operator=(nullptr_t) <ins>noexcept</ins>;
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2402"></a>2402. <tt>basic_string(const basic_string&amp; str, size_type pos, size_type n = npos)</tt> shouldn't use <tt>Allocator()</tt></h3>
<p><b>Section:</b> 21.4.2 [string.cons] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-06-14 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#string.cons">active issues</a> in [string.cons].</p>
<p><b>View all other</b> <a href="lwg-index.html#string.cons">issues</a> in [string.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
21.4.2 [string.cons] p3 specifies:
</p>
<blockquote>
<pre>
basic_string(const basic_string&amp; str, size_type pos, size_type n = npos, const Allocator&amp; a = Allocator());
</pre>
<p>
But this implies that <tt>basic_string(str, pos)</tt> and <tt>basic_string(str, pos, n)</tt> use <tt>Allocator()</tt> 
instead of getting an allocator from <tt>str</tt>.
<p/>
21.4.1 [string.require] p3 says "The <tt>Allocator</tt> object used shall be obtained as described in 23.2.1."  
23.2.1 [container.requirements.general] p8 says "Copy constructors for these container types obtain an allocator 
by calling <tt>allocator_traits&lt;allocator_type&gt;::select_on_container_copy_construction</tt> on the allocator 
belonging to the container being copied.", but this isn't exactly a copy constructor. Then it talks about move constructors 
(which this definitely isn't), and finally says that "All other constructors for these container types take a 
<tt>const allocator_type&amp;</tt> argument. [&hellip;] A copy of this allocator is used for any memory allocation performed".
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 21.4 [basic.string] p5, class template <tt>basic_string</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
[&hellip;]
<i>// 21.4.2, construct/copy/destroy:</i>
[&hellip;]
basic_string(basic_string&amp;&amp; str) noexcept;
<ins>basic_string(const basic_string&amp; str, size_type pos, size_type n = npos);</ins>
basic_string(const basic_string&amp; str, size_type pos, size_type n<del> = npos</del>,
            const Allocator&amp; a<del> = Allocator()</del>);
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Change 21.4.2 [string.cons] around p3 as indicated:</p>

<blockquote>
<pre>
<ins>basic_string(const basic_string&amp; str, 
             size_type pos, size_type n = npos);</ins>
basic_string(const basic_string&amp; str, 
             size_type pos, size_type n<del> = npos</del>,
             const Allocator&amp; a<del> = Allocator()</del>);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-5- <i>Effects</i>: Constructs an object of class <tt>basic_string</tt> and determines the effective length <tt>rlen</tt> of the
initial string value as the smaller of <tt>n</tt> and <tt>str.size() - pos</tt>, as indicated in Table 65. <ins>The first constructor 
obtains an allocator by calling <tt>allocator_traits&lt;allocator_type&gt;::select_on_container_copy_construction</tt> on the 
allocator belonging to <tt>str</tt>.</ins>
<p/>
Table 65 &mdash; <ins><tt>basic_string(const basic_string&amp;, size_type, size_type)</tt> and</ins>
<tt>basic_string(const basic_string&amp;, size_type, size_type, const Allocator&amp;)</tt> effects
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2403"></a>2403. <tt>stof()</tt> should call <tt>strtof()</tt> and <tt>wcstof()</tt></h3>
<p><b>Section:</b> 21.5 [string.conversions] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-06-14 <b>Last modified:</b> 2014-07-01</p>
<p><b>View all other</b> <a href="lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>stof()</tt> is currently specified to call <tt>strtod()</tt>/<tt>wcstod()</tt> (which converts the given string to 
<tt>double</tt>) and then it's specified to convert that <tt>double</tt> to <tt>float</tt>. This performs rounding twice, 
which introduces error. Here's an example written up by James McNellis:
<p/>
Consider the following number <tt>X</tt>:
</p>
<blockquote>
<pre>
1.999999821186065729339276231257827021181583404541015625 (X)
</pre>
</blockquote>
<p>
This number is exactly representable in binary as:
</p>
<blockquote>
<pre>
1.111111111111111111111101000000000000000000000000000001
* ^1st                  ^23rd                        ^52nd
</pre>
</blockquote>
<p>
I've marked the 23rd and 52nd fractional bits. These are the least significant bits for <tt>float</tt> and <tt>double</tt>, 
respectively.
<p/>
If we convert this number directly to <tt>float</tt>, we take the 23 most significant bits:
</p>
<blockquote>
<pre>
1.11111111111111111111110
</pre>
</blockquote>
<p>
The next bit is a one and the tail is nonzero (the 54th fractional bit is a one), so we round up. This gives us the correctly 
rounded result:
</p>
<blockquote>
<pre>
1.11111111111111111111111
</pre>
</blockquote>
<p>
So far so good. But... If we convert <tt>X</tt> to <tt>double</tt>, we take the 52 most significant bits:
</p>
<blockquote>
<pre>
1.1111111111111111111111010000000000000000000000000000 (Y)
</pre>
</blockquote>
<p>
The next bit is a zero, so we round down (truncating the value). If we then convert <tt>Y</tt> to <tt>float</tt>, we take 
its 23 most significant bits:
</p>
<blockquote>
<pre>
1.11111111111111111111110
</pre>
</blockquote>
<p>
The next bit is a one and the tail is zero, so we round to even (leaving the value unchanged). This is off by 1ulp from the 
correctly rounded result.
</p>

<p><i>[2014-06 Rapperswil]</i></p>

<p>
Marshall Clow will look at this.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 21.5 [string.conversions] p4+p6 as indicated:</p>

<blockquote>
<pre>
float stof(const string&amp; str, size_t* idx = 0);
double stod(const string&amp; str, size_t* idx = 0);
long double stold(const string&amp; str, size_t* idx = 0);
</pre>
<blockquote>
<p>
-4- <i>Effects</i>: <del>the first two</del><ins>These</ins> functions call <ins><tt>strtof(str.c_str(), ptr)</tt>,</ins> 
<tt>strtod(str.c_str(), ptr)</tt><ins>,</ins> and <del>the third function calls</del> <tt>strtold(str.c_str(), ptr)</tt><ins>, 
respectively</ins>. Each function returns the converted result, if any. [&hellip;]
<p/>
[&hellip;]
<p/>
-6- <i>Throws</i>: <tt>invalid_argument</tt> if <ins><tt>strtof</tt>,</ins> <tt>strtod</tt><ins>,</ins> or <tt>strtold</tt> reports 
that no conversion could be performed. Throws <tt>out_of_range</tt> if <ins><tt>strtof</tt>,</ins> <tt>strtod</tt><ins>,</ins> or 
<tt>strtold</tt> sets <tt>errno</tt> to <tt>ERANGE</tt> or if the converted value is outside the range of representable 
values for the return type.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 21.5 [string.conversions] p11+p13 as indicated:</p>

<blockquote>
<pre>
float stof(const wstring&amp; str, size_t* idx = 0);
double stod(const wstring&amp; str, size_t* idx = 0);
long double stold(const wstring&amp; str, size_t* idx = 0);
</pre>
<blockquote>
<p>
-11- <i>Effects</i>: <del>the first two</del><ins>These</ins> functions call <ins><tt>wcstof(str.c_str(), ptr)</tt>,</ins> 
<tt>wcstod(str.c_str(), ptr)</tt><ins>,</ins> and <del>the third function calls</del> <tt>wcstold(str.c_str(), ptr)</tt><ins>, 
respectively</ins>. Each function returns the converted result, if any. [&hellip;]
<p/>
[&hellip;]
<p/>
-13- <i>Throws</i>: <tt>invalid_argument</tt> if <ins><tt>wcstof</tt>,</ins> <tt>wcstod</tt><ins>,</ins> or <tt>wcstold</tt> 
reports that no conversion could be performed. Throws <tt>out_of_range</tt> if <ins><tt>wcstof</tt>,</ins> <tt>wcstod</tt><ins>,</ins> 
or <tt>wcstold</tt> sets <tt>errno</tt> to <tt>ERANGE</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2404"></a>2404. <tt>mismatch()</tt>'s complexity needs to be updated</h3>
<p><b>Section:</b> 25.2.10 [mismatch] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-06-14 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3671.html">N3671</a> updated the complexities of 
<tt>equal()</tt> and <tt>is_permutation()</tt>, but not <tt>mismatch()</tt>.
</p>

<p><i>[2014-06-16 Rapperswil]</i></p>

<p>
Move to Ready
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 25.2.10 [mismatch] p3 as indicated:</p>

<blockquote>
<p>
-3- <i>Complexity</i>: At most <tt><ins>min(</ins>last1 - first1<ins>, last2 - first2)</ins></tt> applications of the 
corresponding predicate.
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2406"></a>2406. <tt>negative_binomial_distribution</tt> should reject <tt>p == 1</tt></h3>
<p><b>Section:</b> 26.5.8.3.4 [rand.dist.bern.negbin] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-06-14 <b>Last modified:</b> 2014-06-17</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
26.5.8.3.4 [rand.dist.bern.negbin] p2 requires "<tt>0 &lt; p &lt;= 1</tt>". Consider what happens when <tt>p == 1</tt>.  
The discrete probability function specified by p1 involves "<tt>* p^k * (1 - p)^i</tt>". For <tt>p == 1</tt>, this is 
"<tt>* 1^k * 0^i</tt>", so every integer <tt>i &gt;= 0</tt> is produced with zero probability. (Let's avoid thinking about 
<tt>0^0</tt>.)
<p/>
<a href="http://en.wikipedia.org/wiki/Negative_binomial_distribution">Wikipedia</a> states that <tt>p</tt> must be within 
<tt>(0, 1)</tt>, exclusive on both sides.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 26.5.8.3.4 [rand.dist.bern.negbin] p2 as indicated: [<i>Drafting note</i>: This should be read as: Replace the 
symbol "<tt>&le;</tt>" by "<tt>&lt;</tt>" &mdash; <i>end drafting note</i>]</p>

<blockquote>
<pre>
explicit negative_binomial_distribution(IntType k = 1, double p = 0.5);
</pre>
<blockquote>
<p>
-2- <i>Requires</i>: <tt>0 &lt; p <del>&le;</del><ins>&lt;</ins> 1</tt> and <tt>0 &lt; k</tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2407"></a>2407. <tt>packaged_task(allocator_arg_t, const Allocator&amp;, F&amp;&amp;)</tt> should neither be constrained nor 
<tt>explicit</tt></h3>
<p><b>Section:</b> 30.6.9.1 [futures.task.members] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-06-14 <b>Last modified:</b> 2014-06-17</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.task.members">active issues</a> in [futures.task.members].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.task.members">issues</a> in [futures.task.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="lwg-defects.html#2097">2097</a>'s resolution was slightly too aggressive. It constrained 
<tt>packaged_task(allocator_arg_t, const Allocator&amp;, F&amp;&amp;)</tt>, but that's unnecessary because 
<tt>packaged_task</tt> doesn't have any other three-argument constructors. Additionally, it's marked as 
<tt>explicit</tt> (going back to WP N2798 when <tt>packaged_task</tt> first appeared) which is unnecessary.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 30.6.9 [futures.task] p2, class template <tt>packaged_task</tt> as indicated:</p>

<blockquote>
<pre>
template &lt;class F&gt;
explicit packaged_task(F&amp;&amp; f);
template &lt;class F, class Allocator&gt;
<del>explicit</del> packaged_task(allocator_arg_t, const Allocator&amp; a, F&amp;&amp; f);
</pre>
</blockquote>
</li>

<li><p>Change 30.6.9.1 [futures.task.members] as indicated:</p>

<blockquote>
<pre>
template &lt;class F&gt;
packaged_task(F&amp;&amp; f);
template &lt;class F, class Allocator&gt;
<del>explicit</del> packaged_task(allocator_arg_t, const Allocator&amp; a, F&amp;&amp; f);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-3- <i>Remarks</i>: <del>These constructors</del><ins>The first constructor</ins> shall not participate in overload 
resolution if <tt>decay_t&lt;F&gt;</tt> is the same type as <tt>std::packaged_task&lt;R(ArgTypes...)&gt;</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2408"></a>2408. SFINAE-friendly <tt>common_type/iterator_traits</tt> is missing in C++14</h3>
<p><b>Section:</b> 20.10.7.6 [meta.trans.other], 24.4.1 [iterator.traits] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2014-06-19 <b>Last modified:</b> 2014-06-20</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
During the Rapperswil meeting the proposal <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4041.html">N4041</a>
had been discussed and there seemed to be strong consensus to apply the SFINAE-friendly definitions
that currently exist within the fundamentals-ts to the C++ Standard working draft. This issue requests this change to happen.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 20.10.7.6 [meta.trans.other] p3 as indicated:</p>

<blockquote>
<p>
-3- <ins>For the <tt>common_type</tt> trait applied to a parameter pack <tt>T</tt> of types, 
the member <tt>type</tt> shall be either defined or not present as follows:</ins>
<ul>
<li><p><ins>If <tt>sizeof...(T)</tt> is zero, there shall be no member <tt>type</tt>.</ins></p></li>
<li><p><ins>If <tt>sizeof...(T)</tt> is one, let <tt>T0</tt> denote the sole type comprising <tt>T</tt>. 
The member typedef <tt>type</tt> shall denote the same type as <tt>decay_t&lt;T0&gt;</tt>.</ins></p></li>
<li><p><ins>If <tt>sizeof...(T)</tt> is greater than one, let <tt>T1</tt>, <tt>T2</tt>, and <tt>R</tt>, 
respectively, denote the first, second, and (pack of) remaining types comprising <tt>T</tt>. 
[<i>Note</i>: <tt>sizeof...(R)</tt> may be zero. &mdash; <i>end note</i>] Finally, let <tt>C</tt> denote 
the type, if any, of an unevaluated conditional expression (5.16 [expr.cond]) whose first operand is an arbitrary value 
of type <tt>bool</tt>, whose second operand is an xvalue of type <tt>T1</tt>, and whose third operand is 
an xvalue of type <tt>T2</tt>. If there is such a type <tt>C</tt>, the member typedef <tt>type</tt> shall 
denote the same type, if any, as <tt>common_type_t&lt;C,R...&gt;</tt>. Otherwise, there shall be no member 
<tt>type</tt>.</ins></p></li>
</ul>
<del>The nested typedef <tt>common_type::type</tt> shall be defined as follows:</del>
</p>
<blockquote>
<pre>
<del>template &lt;class ...T&gt; struct common_type;

template &lt;class T&gt;
struct common_type&lt;T&gt; {
  typedef decay_t&lt;T&gt; type;
};

template &lt;class T, class U&gt;
struct common_type&lt;T, U&gt; {
  typedef decay_t&lt;decltype(true ? declval&lt;T&gt;() : declval&lt;U&gt;())&gt; type;
};

template &lt;class T, class U, class... V&gt;
struct common_type&lt;T, U, V...&gt; {
  typedef common_type_t&lt;common_type_t&lt;T, U&gt;, V...&gt; type;
};</del>
</pre>
</blockquote>
</blockquote>
</li>

<li><p>Change 24.4.1 [iterator.traits] p2 as indicated:</p>

<blockquote>
<p>
-2- The template <tt>iterator_traits&lt;Iterator&gt;</tt> <del>is defined as</del><ins>shall have 
the following as publicly accessible members, and have no other members, if and only if 
<tt>Iterator</tt> has valid (14.8.2 [temp.deduct]) member types <tt>difference_type</tt>, 
<tt>value_type</tt>, <tt>pointer</tt>, <tt>reference</tt>, and <tt>iterator_category</tt>; otherwise, 
the template shall have no members:</ins>
</p>
<blockquote>
<pre>
<del>namespace std {
  template&lt;class Iterator&gt; struct iterator_traits {</del>
    typedef typename Iterator::difference_type difference_type;
    typedef typename Iterator::value_type value_type;
    typedef typename Iterator::pointer pointer;
    typedef typename Iterator::reference reference;
    typedef typename Iterator::iterator_category iterator_category;
  <del>};
}</del>
</pre>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2410"></a>2410. [fund.ts] <tt>shared_ptr&lt;array&gt;</tt>'s constructor from <tt>unique_ptr</tt> should be constrained</h3>
<p><b>Section:</b> X [mods.util.smartptr.shared.const] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2014-06-16 <b>Last modified:</b> 2014-07-01</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts</b></p>
<p>
The proposed resolution for LWG <a href="lwg-active.html#2399">2399</a> doesn't apply cleanly to the Fundamentals TS, but the issue is still present.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4023 in regard to fundamental-ts changes.</p>

<ol>
<li><p>In fundamental-ts, change [mods.util.smartptr.shared.const] p34 as indicated:</p>

<blockquote>
<pre>
template &lt;class Y, class D&gt; shared_ptr(unique_ptr&lt;Y, D&gt;&amp;&amp; r);
</pre>
<blockquote>
<p>
-34- <i><del>Requires</del><ins>Remarks</ins></i>: <ins>This constructor shall not participate in overload resolution
unless</ins> <tt>Y*</tt> <del>shall be</del><ins>is</ins> <i>compatible with</i> <tt>T*</tt>. 
<p/>
-35- <i>Effects</i>: Equivalent to <tt>shared_ptr(r.release(), r.get_deleter())</tt> when <tt>D</tt> is not a reference type, 
otherwise <tt>shared_ptr(r.release(), ref(r.get_deleter()))</tt>.
<p/>
-36- <i>Exception safety</i>: If an exception is thrown, the constructor has no effect. 
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2411"></a>2411. <tt>shared_ptr</tt> is only contextually convertible to <tt>bool</tt></h3>
<p><b>Section:</b> 20.8.2.2 [util.smartptr.shared] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-06-21 <b>Last modified:</b> 2014-07-01</p>
<p><b>View other</b> <a href="lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
N3920 made this edit, which is correct but unrelated to the support for arrays:
</p>
<blockquote>
<p>Change 20.7.2.2 [util.smartptr.shared] p2 as follows:</p>
<blockquote>
<p>
Specializations of <tt>shared_ptr</tt> shall be <tt>CopyConstructible</tt>, <tt>CopyAssignable</tt>, and <tt>LessThanComparable</tt>, 
allowing their use in standard containers. Specializations of <tt>shared_ptr</tt> shall be <ins>contextually</ins> convertible to 
<tt>bool</tt>, allowing their use in boolean expressions and declarations in conditions. [&hellip;]
</p>
</blockquote>
</blockquote>
<p>
That change is actually fixing a defect in the current wording and should be applied directly to the working paper, not just to the
Library Fundamentals TS. The declarations of the conversion operator in 20.8.2.2 [util.smartptr.shared] and 
20.8.2.2.5 [util.smartptr.shared.obs] are <tt>explicit</tt> which contradicts the "convertible to <tt>bool</tt>" statement. The
intention is definitely for <tt>shared_ptr</tt> to only be contextually convertible to <tt>bool</tt>.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 20.8.2.2 [util.smartptr.shared] p2 as indicated:</p>

<blockquote>
<p>
-2- Specializations of <tt>shared_ptr</tt> shall be <tt>CopyConstructible</tt>, <tt>CopyAssignable</tt>, and <tt>LessThanComparable</tt>,
allowing their use in standard containers. Specializations of <tt>shared_ptr</tt> shall be <ins>contextually</ins> convertible to 
<tt>bool</tt>, allowing their use in boolean expressions and declarations in conditions. The template parameter <tt>T</tt> of
<tt>shared_ptr</tt> may be an incomplete type.
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2412"></a>2412. <tt>promise::set_value()</tt> and <tt>promise::get_future()</tt> should not race</h3>
<p><b>Section:</b> 30.6.5 [futures.promise], 30.6.9.1 [futures.task.members] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-06-23 <b>Last modified:</b> 2014-07-01</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The following code has a data race according to the standard:
</p>
<blockquote>
<pre>
std::promise&lt;void&gt; p;
std::thread t{ []{
  p.get_future().wait();
}};
p.set_value();
t.join();
</pre>
</blockquote>
<p>
The problem is that both <tt>promise::set_value()</tt> and
<tt>promise::get_future()</tt> are non-const member functions which modify the
same object, and we only have wording saying that the <tt>set_value()</tt> and
<tt>wait()</tt> calls (i.e. calls setting and reading the shared state) are
synchronized.
<p/>
The calls don't actually access the same memory locations, so the
standard should allow it. My suggestion is to state that calling
<tt>get_future()</tt> does not conflict with calling the various functions that
make the shared state ready, but clarify with a note that this does
not imply any synchronization or "happens before", only being free
from data races.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 30.6.5 [futures.promise] around p12 as indicated:</p>

<blockquote>
<pre>
future&lt;R&gt; get_future();
</pre>
<blockquote>
<p>
-12- <i>Returns</i>: A <tt>future&lt;R&gt;</tt> object with the same shared state as <tt>*this</tt>.
<p/>
<ins>-?- <i>Synchronization</i>: Calls to this function do not conflict (1.10 [intro.multithread]) 
with calls to <tt>set_value</tt>, <tt>set_exception</tt>, <tt>set_value_at_thread_exit</tt>, or
<tt>set_exception_at_thread_exit</tt>. [<i>Note</i>: Such calls need not be synchronized, but implementations 
must ensure they do not introduce data races. &mdash; <i>end note</i>]</ins>
<p/>
-13- <i>Throws</i>: <tt>future_error</tt> if <tt>*this</tt> has no shared state or if <tt>get_future</tt> has already been called on a
<tt>promise</tt> with the same shared state as <tt>*this</tt>.
<p/>
-14- <i>Error conditions</i>: [&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 30.6.9.1 [futures.task.members] around p13 as indicated:</p>

<blockquote>
<pre>
future&lt;R&gt; get_future();
</pre>
<blockquote>
<p>
-13- <i>Returns</i>: A <tt>future&lt;R&gt;</tt> object that shares the same shared state as <tt>*this</tt>.
<p/>
<ins>-?- <i>Synchronization</i>: Calls to this function do not conflict (1.10 [intro.multithread]) 
with calls to <tt>operator()</tt> or <tt>make_ready_at_thread_exit</tt>. [<i>Note</i>: Such calls need not be 
synchronized, but implementations must ensure they do not introduce data races. &mdash; <i>end note</i>]</ins>
<p/>
-14- <i>Throws</i>: a <tt>future_error</tt> object if an error occurs.
<p/>
-15- <i>Error conditions</i>: [&hellip;]
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2413"></a>2413. <tt>assert</tt> macro is overconstrained</h3>
<p><b>Section:</b> 19.3 [assertions] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> David Krauss <b>Opened:</b> 2014-06-25 <b>Last modified:</b> 2014-07-01</p>
<p><b>View other</b> <a href="lwg-index-open.html#assertions">active issues</a> in [assertions].</p>
<p><b>View all other</b> <a href="lwg-index.html#assertions">issues</a> in [assertions].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
When <tt>NDEBUG</tt> is defined, <tt>assert</tt> must expand exactly to the token sequence <tt>((void)0)</tt>, with no 
whitespace (C99 &sect;7.2/1 and also C11 &sect;7.2/1). This is a lost opportunity to pass the condition along to the optimizer.
<p/>
The user may observe the token sequence using the stringize operator or discriminate it by making a matching <tt>#define</tt> 
directive. There is little chance of practical code doing such things. It's reasonable to allow any expansion that is a <tt>void</tt> 
expression with no side effects or semantic requirements, for example, an extension keyword or an attribute-specifier finagled 
into the context.
<p/>
Conforming optimizations would still be limited to treating the condition as hint, not a requirement. Nonconformance on this 
point is quite reasonable though, given user preferences. Anyway, it shouldn't depend on preprocessor quirks.
<p/>
As for current practice, Darwin OS <tt>&lt;assert.h&gt;</tt> provides a GCC-style compiler hint <tt>__builtin_expect</tt> but only in 
debug mode. Shouldn't release mode preserve hints?
<p/>
Daniel:
<p/>
The corresponding resolution should take care not to conflict with the intention behind LWG <a href="lwg-active.html#2234">2234</a>.
</p>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2414"></a>2414. Member function reentrancy should be implementation-defined</h3>
<p><b>Section:</b> 17.6.5.8 [reentrancy] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-07-01 <b>Last modified:</b> 2014-07-08</p>
<p><b>View other</b> <a href="lwg-index-open.html#reentrancy">active issues</a> in [reentrancy].</p>
<p><b>View all other</b> <a href="lwg-index.html#reentrancy">issues</a> in [reentrancy].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
N3936 17.6.5.8 [reentrancy]/1 talks about "functions", but that doesn't address the scenario of calling different member 
functions of a single object. Member functions often have to violate and then re-establish invariants. For example, vectors 
often have "holes" during insertion, and element constructors/destructors/etc. shouldn't be allowed to observe the vector 
while it's in this invariant-violating state. The [reentrancy] Standardese should be extended to cover member functions, 
so that implementers can either say that member function reentrancy is universally prohibited, or selectively allowed for 
very specific scenarios.
<p/>
(For clarity, this issue has been split off from LWG <a href="lwg-active.html#2382">2382</a>.)
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 17.6.5.8 [reentrancy] p1 as indicated:</p>
<blockquote>
<p>
-1- Except where explicitly specified in this standard, it is implementation-defined which functions <ins>(including different 
member functions called on a single object)</ins> in the Standard C++ library may be recursively reentered.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2415"></a>2415. Inconsistency between <tt>unique_ptr</tt> and <tt>shared_ptr</tt></h3>
<p><b>Section:</b> 20.8.2.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-07-03 <b>Last modified:</b> 2014-07-08</p>
<p><b>View other</b> <a href="lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>unique_ptr</tt> guarantees that it will not invoke its deleter if it stores
a null pointer, which is useful for deleters that must not be called
with a null pointer e.g.
</p>
<blockquote><pre>
unique_ptr&lt;FILE, int(*)(FILE*)&gt; fptr(file, &amp;::fclose);
</pre></blockquote>
<p>
However, <tt>shared_ptr</tt> does invoke the deleter if it owns a null pointer,
which is a silent change in behaviour when transferring
ownership from <tt>unique_ptr</tt> to <tt>shared_ptr</tt>. That means the following
leads to undefined behaviour:
</p>
<blockquote><pre>
std:shared_ptr&lt;FILE&gt; fp = std::move(fptr);
</pre></blockquote>
<p>
Peter Dimov's suggested fix is to construct an empty <tt>shared_ptr</tt> from a
<tt>unique_ptr</tt> that contains a null pointer.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 20.8.2.2.1 [util.smartptr.shared.const] p33 as indicated:</p>
<blockquote>
<pre>
template &lt;class Y, class D&gt; shared_ptr(unique_ptr&lt;Y, D&gt;&amp;&amp; r);
</pre>
<blockquote>
<p>
-33- <i>Effects</i>: Equivalent to <ins><tt>shared_ptr()</tt> if <tt>r.get() == nullptr</tt>,
otherwise equivalent to</ins> <tt>shared_ptr(r.release(), r.get_deleter())</tt> when <tt>D</tt> is not a reference type,
otherwise <tt>shared_ptr(r.release(), ref(r.get_deleter()))</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





</body>
</html>
