<!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">N3284=11-0054</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2011-03-25</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 (Madrid Resolutions)</h1>
<p>Revised 2011-03-25 at 10:03:28 UTC</p>

  <p>Reference ISO/IEC IS 14882:2003(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:2003(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:2003(E), and be
  submitted to Information Technology Industry Council (ITI), 1250 Eye
  Street NW, Washington, DC 20005.</p>

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

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

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


<h2>Revision History</h2>
<ul>
<li>Madrid meeting resolutions<ul>
<li><b>Summary:</b><ul>
<li>72 open issues, down by 24.</li>
<li>1493 closed issues, up by 33.</li>
<li>1565 issues total, up by 9.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 2 Immediate issues: <a href="lwg-active.html#2041">2041</a>, <a href="lwg-active.html#2042">2042</a>.</li>
<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-active.html#2040">2040</a>.</li>
<li>Added the following Pending Resolved issue: <a href="lwg-defects.html#2037">2037</a>.</li>
<li>Added the following Ready issue: <a href="lwg-active.html#2039">2039</a>.</li>
<li>Changed the following issue from New to Deferred: <a href="lwg-active.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 3 issues from New to Immediate: <a href="lwg-active.html#1524">1524</a>, <a href="lwg-active.html#2008">2008</a>, <a href="lwg-active.html#2032">2032</a>.</li>
<li>Changed the following 5 issues from Open to Immediate: <a href="lwg-active.html#1252">1252</a>, <a href="lwg-active.html#1349">1349</a>, <a href="lwg-active.html#1448">1448</a>, <a href="lwg-active.html#1478">1478</a>, <a href="lwg-active.html#1487">1487</a>.</li>
<li>Changed the following 2 issues from Ready to Immediate: <a href="lwg-active.html#1279">1279</a>, <a href="lwg-active.html#1401">1401</a>.</li>
<li>Changed the following 4 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#1369">1369</a>, <a href="lwg-closed.html#1452">1452</a>.</li>
<li>Changed the following issue from Open to NAD Future: <a href="lwg-closed.html#1396">1396</a>.</li>
<li>Changed the following 4 issues from New to Open: <a href="lwg-active.html#2012">2012</a>, <a href="lwg-active.html#2018">2018</a>, <a href="lwg-active.html#2033">2033</a>, <a href="lwg-active.html#2035">2035</a>.</li>
<li>Changed the following 2 issues from Open to Pending NAD: <a href="lwg-closed.html#1358">1358</a>, <a href="lwg-closed.html#1461">1461</a>.</li>
<li>Changed the following 2 issues from Tentatively NAD to Pending NAD: <a href="lwg-closed.html#1485">1485</a>, <a href="lwg-closed.html#1486">1486</a>.</li>
<li>Changed the following issue from Tentatively Ready to Pending NAD: <a href="lwg-closed.html#1456">1456</a>.</li>
<li>Changed the following issue from Open to Pending NAD Future: <a href="lwg-closed.html#1459">1459</a>.</li>
<li>Changed the following 3 issues from New to Pending 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 12 issues from Open to Pending Resolved: <a href="lwg-defects.html#964">964</a>, <a href="lwg-defects.html#966">966</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 Pending 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 Ready: <a href="lwg-active.html#2028">2028</a>.</li>
<li>Changed the following issue from Review to Ready: <a href="lwg-active.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 issue from Open to Resolved: <a href="lwg-defects.html#985">985</a>.</li>
<li>Changed the following issue from New to Review: <a href="lwg-active.html#2021">2021</a>.</li>
<li>Changed the following issue from Open to Review: <a href="lwg-active.html#2005">2005</a>.</li>
<li>Changed the following issue from Open to Tentatively NAD: <a href="lwg-active.html#1374">1374</a>.</li>
<li>Changed the following 22 issues from Tentatively Ready to Tentatively Voting: <a href="lwg-active.html#1215">1215</a>, <a href="lwg-active.html#1253">1253</a>, <a href="lwg-active.html#1310">1310</a>, <a href="lwg-active.html#1474">1474</a>, <a href="lwg-active.html#1479">1479</a>, <a href="lwg-active.html#1480">1480</a>, <a href="lwg-active.html#1494">1494</a>, <a href="lwg-active.html#1497">1497</a>, <a href="lwg-active.html#1514">1514</a>, <a href="lwg-active.html#2000">2000</a>, <a href="lwg-active.html#2001">2001</a>, <a href="lwg-active.html#2004">2004</a>, <a href="lwg-active.html#2007">2007</a>, <a href="lwg-active.html#2014">2014</a>, <a href="lwg-active.html#2017">2017</a>, <a href="lwg-active.html#2019">2019</a>, <a href="lwg-active.html#2020">2020</a>, <a href="lwg-active.html#2022">2022</a>, <a href="lwg-active.html#2027">2027</a>, <a href="lwg-active.html#2029">2029</a>, <a href="lwg-active.html#2030">2030</a>, <a href="lwg-active.html#2031">2031</a>.</li>
<li>Changed the following 6 issues from Ready to Voting: <a href="lwg-active.html#1332">1332</a>, <a href="lwg-active.html#1385">1385</a>, <a href="lwg-active.html#1408">1408</a>, <a href="lwg-active.html#1418">1418</a>, <a href="lwg-active.html#1420">1420</a>, <a href="lwg-active.html#1438">1438</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-active.html#2021">2021</a>, <a href="lwg-active.html#2025">2025</a>, <a href="lwg-active.html#2028">2028</a>, <a href="lwg-active.html#2032">2032</a>, <a href="lwg-active.html#2033">2033</a>, <a href="lwg-active.html#2034">2034</a>, <a href="lwg-active.html#2035">2035</a>.</li>
<li>Added the following Tentatively NAD issue: <a href="lwg-active.html#2026">2026</a>.</li>
<li>Added the following 8 Tentatively Ready issues: <a href="lwg-active.html#2020">2020</a>, <a href="lwg-active.html#2022">2022</a>, <a href="lwg-active.html#2023">2023</a>, <a href="lwg-active.html#2024">2024</a>, <a href="lwg-active.html#2027">2027</a>, <a href="lwg-active.html#2029">2029</a>, <a href="lwg-active.html#2030">2030</a>, <a href="lwg-active.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-active.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-active.html#1485">1485</a>, <a href="lwg-active.html#1486">1486</a>.</li>
<li>Changed the following 3 issues from New to Tentatively Ready: <a href="lwg-active.html#2014">2014</a>, <a href="lwg-active.html#2017">2017</a>, <a href="lwg-active.html#2019">2019</a>.</li>
<li>Changed the following 8 issues from Open to Tentatively Ready: <a href="lwg-active.html#1456">1456</a>, <a href="lwg-active.html#1457">1457</a>, <a href="lwg-active.html#1474">1474</a>, <a href="lwg-active.html#1479">1479</a>, <a href="lwg-active.html#1494">1494</a>, <a href="lwg-active.html#1514">1514</a>, <a href="lwg-active.html#1515">1515</a>, <a href="lwg-active.html#2001">2001</a>.</li>
<li>Changed the following issue from Review to Tentatively Ready: <a href="lwg-active.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-active.html#1521">1521</a>, <a href="lwg-defects.html#1523">1523</a>, <a href="lwg-active.html#2008">2008</a>, <a href="lwg-active.html#2012">2012</a>, <a href="lwg-active.html#2013">2013</a>, <a href="lwg-active.html#2014">2014</a>, <a href="lwg-active.html#2015">2015</a>, <a href="lwg-active.html#2016">2016</a>, <a href="lwg-active.html#2017">2017</a>, <a href="lwg-active.html#2018">2018</a>, <a href="lwg-active.html#2019">2019</a>.</li>
<li>Added the following 5 Open issues: <a href="lwg-active.html#2001">2001</a>, <a href="lwg-active.html#2003">2003</a>, <a href="lwg-active.html#2005">2005</a>, <a href="lwg-active.html#2010">2010</a>, <a href="lwg-active.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-active.html#2009">2009</a>.</li>
<li>Added the following Tentatively NAD issue: <a href="lwg-active.html#2006">2006</a>.</li>
<li>Added the following 3 Tentatively Ready issues: <a href="lwg-active.html#2000">2000</a>, <a href="lwg-active.html#2004">2004</a>, <a href="lwg-active.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-active.html#1214">1214</a>, <a href="lwg-active.html#1330">1330</a>.</li>
<li>Changed the following issue from Open to Deferred: <a href="lwg-active.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-active.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-active.html#1279">1279</a>, <a href="lwg-closed.html#1318">1318</a>, <a href="lwg-active.html#1332">1332</a>.</li>
<li>Changed the following 6 issues from Open to Ready: <a href="lwg-active.html#1385">1385</a>, <a href="lwg-active.html#1401">1401</a>, <a href="lwg-active.html#1408">1408</a>, <a href="lwg-active.html#1418">1418</a>, <a href="lwg-active.html#1420">1420</a>, <a href="lwg-active.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-active.html#1480">1480</a>.</li>
<li>Changed the following 2 issues from Open to Tentatively NAD: <a href="lwg-active.html#1371">1371</a>, <a href="lwg-active.html#1413">1413</a>.</li>
<li>Changed the following issue from New to Tentatively NAD Future: <a href="lwg-active.html#1320">1320</a>.</li>
<li>Changed the following 3 issues from New to Tentatively Ready: <a href="lwg-active.html#1215">1215</a>, <a href="lwg-active.html#1253">1253</a>, <a href="lwg-active.html#1310">1310</a>.</li>
<li>Changed the following issue from Open to Tentatively Ready: <a href="lwg-active.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-active.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-active.html#1371">1371</a>, <a href="lwg-closed.html#1373">1373</a>, <a href="lwg-active.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-active.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-active.html#1401">1401</a>, <a href="lwg-closed.html#1406">1406</a>, <a href="lwg-active.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-active.html#1413">1413</a>, <a href="lwg-active.html#1418">1418</a>, <a href="lwg-active.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-active.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-active.html#1448">1448</a>, <a href="lwg-active.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-active.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-active.html#1478">1478</a>, <a href="lwg-active.html#1479">1479</a>, <a href="lwg-active.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-active.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-active.html#1494">1494</a>, <a href="lwg-closed.html#1495">1495</a>, <a href="lwg-closed.html#1496">1496</a>, <a href="lwg-active.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-active.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-active.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-active.html#2009">2009</a>, <a href="lwg-active.html#2010">2010</a>, <a href="lwg-active.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-active.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-active.html#1330">1330</a>, <a href="lwg-closed.html#1331">1331</a>, <a href="lwg-active.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-active.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-active.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-active.html#1252">1252</a>, <a href="lwg-active.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-active.html#1214">1214</a>, <a href="lwg-active.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><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="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="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 Concepts">NAD Concepts</a></b> - The LWG has reached consensus that
  the issue is NAD for now, but represents a real issue when the library is
  done with language-supported concepts.</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="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><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="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="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="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="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="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>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>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 J16 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#TC">TC</a>),
  or are closed without action other than a Record of Response
  (<a href="lwg-active.html#RR">RR</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#Deferred">Deferred</a>
 <b>Submitter:</b> Cosmin Truta <b>Opened:</b> 2009-07-04 <b>Last modified:</b> 2011-03-24</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#Deferred">Deferred</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>&#xB1HUGE_VALF</code>,
<code>&#xB1HUGE_VAL</code> and <code>&#xB1HUGE_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><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#Deferred">Deferred</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-07-17 <b>Last modified:</b> 2011-03-24</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#Deferred">Deferred</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><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&frasl;note pre-&frasl;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 <ins>&#x1d4aa;(<tt>n</tt>) +</ins> &#x1d4aa;(<tt><i>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 <ins>&#x1d4aa;(<tt>n</tt>) +</ins> &#x1d4aa;(<tt><i>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)</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 <ins>&#x1d4aa;(<tt>n</tt>) +</ins> &#x1d4aa;(<tt><i>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 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>implementation-defined</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>: Constant <ins>if <tt>n</tt> is not provided, otherwise linear in <tt>n</tt> to construct the 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>implementation-defined</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>Constant if <tt>n</tt> is not 
provided, else linear in <tt>n</tt> to construct the 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 
<tt>distance(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>implementation-defined</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>: Constant <ins>if <tt>n</tt> is not provided, otherwise linear in <tt>n</tt> to construct the 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>implementation-defined</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>Constant if <tt>n</tt> is not 
provided, else linear in <tt>n</tt> to construct the 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 
<tt>distance(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>implementation-defined</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>: Constant <ins>if <tt>n</tt> is not provided, otherwise linear in <tt>n</tt> to construct the 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>implementation-defined</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>Constant if <tt>n</tt> is not 
provided, else linear in <tt>n</tt> to construct the 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 
<tt>distance(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>implementation-defined</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>: Constant <ins>if <tt>n</tt> is not provided, otherwise linear in <tt>n</tt> to construct the 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>implementation-defined</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>Constant if <tt>n</tt> is not 
provided, else linear in <tt>n</tt> to construct the 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 
<tt>distance(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#Deferred">Deferred</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2009-09-19 <b>Last modified:</b> 2011-03-24</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#Deferred">Deferred</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.6.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><b>Proposed resolution:</b></p>
<p>
Consider to await the paper.
</p>





<hr>
<h3><a name="1214"></a>1214. Insufficient/inconsistent key immutability requirements for  associative containers</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="lwg-active.html#Deferred">Deferred</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2009-09-20 <b>Last modified:</b> 2011-03-24</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#Deferred">Deferred</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Scott Meyers' mentions on a recent posting on <a
href="http://groups.google.de/group/comp.std.c++/msg/6f9160fc428bcbea">c.s.c++</a>
some arguments that point to an incomplete resolution
of <a href="lwg-defects.html#103">103</a> and to an inconsistency of requirements on keys in ordered and
unordered associative
containers:
</p>

<blockquote>
<p>
1) <a href="lwg-defects.html#103">103</a> introduced the term immutable without defining it in a unique manner in
23.2.4 [associative.reqmts]/5:
</p>

<blockquote><p>
[..] Keys in an associative container are immutable.
</p></blockquote>

<p>
According to conventional dictionaries immutable is an unconditional way of
saying that something cannot be changed. So without any further explicit
allowance a user <em>always</em> runs into undefined behavior if (s)he attempts
to modify such a key. IMO this was not the intend of the committee to resolve
<a href="lwg-defects.html#103">103</a> in that way because the comments suggest an interpretation that
should give any user the freedom to modify the key in an <em>explicit</em> way
<em>provided</em> it would not affect the sort order in that container.
</p>

<p>
2) Another observation was that surprisingly no similar 'safety guards'
exists against unintentional key changes for the unordered associative
containers, specifically there is no such requirement as in
23.2.4 [associative.reqmts]/6 that "both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
iterators". But the need for such protection against unintentional
changes as well as the constraints in which manner any explicit
changes may be performed are both missing and necessary, because
such changes could potentially change the <em>equivalence</em> of keys that
is measured by the <tt>hasher</tt> and <tt>key_equal</tt>.
</p>

<p>
I suggest to fix the unconditional wording involved with "immutable keys"
by at least adding a hint for the reader that users <em>may</em> perform such
changes in an explicit manner <em>and</em> to perform similar wording changes
as <a href="lwg-defects.html#103">103</a> did for the ordered associative containers also for the unordered
containers.
</p>
</blockquote>

<p><i>[
2010-03-27 Daniel provides wording.
]</i></p>


<blockquote><p>
This update attempts to provide normative wording that harmonizes the key and
function object constraints of associative and unordered containers.
</p></blockquote>

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


<p>
We're uncomfortable with the first agenda item, and we can live with the second agenda 
item being applied before or after Madrid. 
</p>


<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Change 23.2.4 [associative.reqmts]/2 as indicated: <i>[This ensures that
associative containers make better clear what this "arbitrary" type is, as the
unordered containers do in 23.2.5 [unord.req]/3]</i>
</p>

<blockquote><p>
2 Each associative container is parameterized on <tt>Key</tt> and an ordering
relation <tt>Compare</tt> that induces a strict weak ordering (25.4) on elements
of <tt>Key</tt>. In addition, <tt>map</tt> and <tt>multimap</tt> associate an
arbitrary <ins><em>mapped type</em></ins><del>type</del> <tt>T</tt> with the
<tt>Key</tt>. The object of type <tt>Compare</tt> is called the <em>comparison
object</em> of a container.
</p></blockquote>
</li>

<li>
<p>
Change 23.2.4 [associative.reqmts]/5 as indicated: <i>[This removes the
too strong requirement that keys must not be changed at all and brings this line
in sync with 23.2.5 [unord.req]/7. We take care about the real
constraints by the remaining suggested changes. The rationale provided by LWG
<a href="lwg-defects.html#103">103</a> didn't really argue why that addition is necessary, and I
believe the remaining additions make it clear that any user changes have strong
restrictions]</i>:
</p>

<blockquote><p>
5 For <tt>set</tt> and <tt>multiset</tt> the value type is the same as the key
type. For <tt>map</tt> and <tt>multimap</tt> it is equal to <tt>pair&lt;const
Key, T&gt;</tt>. <del>Keys in an associative container are immutable.</del>
</p></blockquote>
</li>

<li>
<p>
Change 23.2.5 [unord.req]/3+4 as indicated: <i>[The current sentence of
p.4 has doesn't say something really new and this whole subclause misses to
define the concepts of the container-specific hasher <i>object</i> and predicate
<i>object</i>. We introduce the term <em>key equality predicate</em> which is
already used in the requirements table. This change does not really correct part
of this issue, but is recommended to better clarify the nomenclature and the
difference between the function objects and the function object <em>types</em>,
which is important, because both can potentially be stateful.]</i>
</p>

<blockquote>
<p>
3 Each unordered associative container is parameterized by <tt>Key</tt>, by a
function object type <tt>Hash</tt> that meets the <tt>Hash</tt> requirements
(20.2.4) and acts as a hash function for argument values of type <tt>Key</tt>,
and by a binary predicate <tt>Pred</tt> that induces an equivalence relation on
values of type <tt>Key</tt>. Additionally, <tt>unordered_map</tt> and
<tt>unordered_multimap</tt> associate an arbitrary <em>mapped type</em>
<tt>T</tt> with the <tt>Key</tt>.
</p>

<p>
4 <ins>The container's object of type <tt>Hash</tt> - denoted by
<tt>hash</tt> - is called the <em>hash function</em> of the container.
The container's object of type <tt>Pred</tt> - denoted by
<tt>pred</tt> - is called the <em>key equality predicate</em> of the
container.</ins><del>A hash function is a function object that takes a single
argument of type <tt>Key</tt> and returns a value of type
<tt>std::size_t</tt></del>.
</p>
</blockquote>
</li>

<li>
<p>
Change 23.2.5 [unord.req]/5 as indicated: <i>[This adds a similar
safe-guard as the last sentence of 23.2.4 [associative.reqmts]/3]</i>
</p>

<blockquote><p>
5 Two values <tt>k1</tt> and <tt>k2</tt> of type <tt>Key</tt> are considered
equivalent if the container's <ins>key equality
predicate</ins><del><tt>key_equal</tt> function object</del> returns
<tt>true</tt> when passed those values. If <tt>k1</tt> and <tt>k2</tt> are
equivalent, the <ins>container's</ins> hash function shall return the same value
for both. [<i>Note:</i> thus, when an unordered associative container is
instantiated with a non-default <tt>Pred</tt> parameter it usually needs a
non-default <tt>Hash</tt> parameter as well. &mdash; <i>end note</i>] <ins>For
any two keys <tt>k1</tt> and <tt>k2</tt> in the same container, calling
<tt>pred(k1, k2)</tt> shall always return the same value. For any key <tt>k</tt>
in a container, calling <tt>hash(k)</tt> shall always return the same
value.</ins>
</p></blockquote>
</li>

<li>
<p>
After 23.2.5 [unord.req]/7 add the following new paragraph: <i>[This
ensures the same level of compile-time protection that we already require for
associative containers. It is necessary for similar reasons, because any change
in the stored key which would change it's equality relation to others or would
change it's hash value such that it would no longer fall in the same bucket,
would break the container invariants]</i>
</p>

<blockquote>
<p>
7 For <tt>unordered_set</tt> and <tt>unordered_multiset</tt> the value type is
the same as the key type. For <tt>unordered_map</tt> and
<tt>unordered_multimap</tt> it is <tt>std::pair&lt;const Key, T&gt;</tt>.
</p>
<p>
<ins>For unordered containers where the value type is the same as the key type,
both <tt>iterator</tt> and <tt>const_iterator</tt> are constant iterators. It is
unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt> are the
same type. [<i>Note:</i> <tt>iterator</tt> and <tt>const_iterator</tt> have
identical semantics in this case, and <tt>iterator</tt> is convertible to
<tt>const_iterator</tt>. Users can avoid violating the One Definition Rule by
always using <tt>const_iterator</tt> in their function parameter lists. &mdash;
<i>end note</i>]</ins>
</p>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="1215"></a>1215. <tt>list::merge</tt> with unequal allocators</h3>
<p><b>Section:</b> 23.3.5.5 [list.ops] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-09-24 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#list.ops">issues</a> in [list.ops].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In Bellevue (I think), we passed
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>,
which, among other things, specifies that the behavior of
<tt>list::splice</tt> is undefined if the allocators of the two lists
being spliced do not compare equal. The same rationale should apply to
<tt>list::merge</tt>. The intent of <tt>list::merge</tt> (AFAIK) is to
move nodes from one sorted <tt>list</tt> into another sorted
<tt>list</tt> without copying the elements. This is possible only if the
allocators compare equal.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Relative to the August 2009 WP,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>,
change 23.3.5.5 [list.ops],
paragraphs 22-25 as follows:
</p>

<blockquote>
<pre>
void merge(list&amp;&amp; x);
template &lt;class Compare&gt; void merge(list&amp;&amp; x, Compare comp);
</pre>
<blockquote>
<p>
<i>Requires</i>: both the list and the argument list shall be sorted
according to operator&lt; or comp.
</p>
<p>
<i>Effects</i>: If <tt>(&amp;x == this)</tt> does nothing; otherwise, merges the
two sorted ranges <tt>[begin(), end())</tt> and <tt>[x.begin(),
x.end())</tt>. The result is a range in which the elements will be
sorted in non-decreasing order according to the ordering defined by
<tt>comp</tt>; that is, for every iterator <tt>i</tt>, in the range other than the
<tt>first</tt>, the condition <tt>comp(*i, *(i - 1)<ins>)</ins></tt> will be
<tt>false</tt>.
</p>
<p>
<i>Remarks</i>: Stable. If <tt>(&amp;x != this)</tt> the range <tt>[x.begin(), x.end())</tt> is
empty after the merge. <ins>No elements are copied by this operation.
The behavior is undefined if <tt>this-&gt;get_allocator() !=
x.get_allocator()</tt>.</ins>
</p>
<p>
<i>Complexity</i>: At most <tt>size() + x.size() - 1</tt> applications of <tt>comp</tt>
if <tt>(&amp;x != this)</tt>; otherwise, no applications of <tt>comp</tt> are performed. If an
exception is thrown other than by a comparison there are no effects.
</p>
</blockquote>
</blockquote>





<hr>
<h3><a name="1252"></a>1252. <tt>wbuffer_convert::state_type</tt> inconsistency</h3>
<p><b>Section:</b> 22.3.3.2.3 [conversions.buffer] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Bo Persson  <b>Opened:</b> 2009-10-21 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The synopsis for <tt>wbuffer_convert</tt> 22.3.3.2.3 [conversions.buffer]/2 contains
</p>

<blockquote><pre>
typedef typename Tr::state_type   state_type; 
</pre></blockquote>

<p>
making <tt>state_type</tt> a synonym for (possibly) some
<tt>char_traits&lt;x&gt;::state_type</tt>. 
</p>

<p>
However, in paragraph 9 of the same section, we have 
</p>

<blockquote><pre>
typedef typename Codecvt::state_type state_type;
</pre>

<blockquote><p>
The type shall be a synonym for <tt>Codecvt::state_type</tt>.
</p></blockquote>
</blockquote>

<p>
From what I can see, it might be hard to implement <tt>wbuffer_convert</tt> if 
the types were not both <tt>std::mbstate_t</tt>, but I cannot find a requirement 
that they must be the same type.
</p>

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


<p>
Howard to draft wording, move to Review. Run it by Bill. Need to move this in Madrid.
</p>

<p><i>[2011-03-06: Howard drafts wording]</i></p>


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


<p>Moved to Immediate</p>


<p><b>Proposed resolution:</b></p>
<p>Modify the <tt>state_type</tt> typedef in the synopsis of 22.3.3.2.3 [conversions.buffer] p.2 as shown
[This makes the synopsis consistent with 22.3.3.2.3 [conversions.buffer] p.9]:</p>

<blockquote><pre>
namespace std {
template&lt;class Codecvt,
  class Elem = wchar_t,
  class Tr = std::char_traits&lt;Elem&gt; &gt;
class wbuffer_convert
  : public std::basic_streambuf&lt;Elem, Tr&gt; {
public:
  typedef typename <del>Tr</del><ins>Codecvt</ins>::state_type state_type;
  [&hellip;]
};
}
</pre></blockquote>





<hr>
<h3><a name="1253"></a>1253. invalidation of iterators and <tt>emplace</tt> vs. <tt>insert</tt> inconsistence in assoc. containers</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> Boris Du&scaron;ek <b>Opened:</b> 2009-10-24 <b>Last modified:</b> 2011-03-24</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#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In the latest published draft
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>,
section 23.2.4 [associative.reqmts], paragraph 8, it is specified
that that <tt>insert</tt> does not invalidate any iterators. As per
23.2.1 [container.requirements.general], paragraph 12, this holds
true not only for <tt>insert</tt>, but <tt>emplace</tt> as well. This
gives the <tt>insert</tt> member a special treatment w.r.t.
<tt>emplace</tt> member in 23.2.4 [associative.reqmts], par. 8,
since both modify the container. For the sake of consistency, in 23.2.4 [associative.reqmts], par. 8: either reference to <tt>insert</tt> 
should be removed (i.e. count on 23.2.1 [container.requirements.general], 
par. 12), or reference to <tt>emplace</tt> be added (i.e. mention all 
members of assoc. containers that modify it).
</p>

<p><i>[
2009-11-18 Chris provided wording.
]</i></p>


<blockquote><p>
This suggested wording covers both the issue discussed, and a number of other
identical issues (namely <tt>insert</tt> being discussed without <tt>emplace</tt>). I'm happy to
go back and split and introduce a new issue if appropriate, but I think the
changes are fairly mechanical and obvious.
</p></blockquote>

<p><i>[
2010-01-23 Daniel Kr&uuml;gler and J. Daniel Garc&iacute;a updated wording to
make the use of <tt>hint</tt> consistent with <tt>insert</tt>.
]</i></p>


<p><i>[
2011-02-23 Daniel Kr&uuml;gler adapts wording to numbering changes to match the N3225 draft. During this
action it was found that 23.2.5 [unord.req] had been changed considerably
due to acceptance of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3068.pdf">N3068</a>
during the Pittsburgh meeting, such that the suggested wording change to
p. 6 can no longer be applied. The new wording is more general and should
now include <tt>insert()</tt> and <tt>emplace()</tt> calls as well ("mutating operations").
]</i></p>


<p><i>[2011-03-06 Daniel Kr&uuml;gler adapts wording to numbering changes to match the N3242 draft]</i></p>




<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Modify bullet 1 of 23.2.1 [container.requirements.general], p. 10:
</p>

<p>
10 Unless otherwise specified (see [associative.reqmts.except], [unord.req.except], [deque.modifiers], and [vector.modifiers])
all container types defined in this Clause meet the following additional
requirements:
</p>

<ul>
<li>
if an exception is thrown by an <tt>insert()</tt> <ins>or
<tt>emplace()</tt></ins> function while inserting a single element, that
function has no effects.
</li>
<li>...</li>
</ul>

</li>

<li>
<p>
Modify 23.2.4 [associative.reqmts], p. 4:
</p>

<blockquote><p>
4 An associative container supports <i>unique keys</i> if it may contain at most
one element for each key. Otherwise, it supports <i>equivalent keys</i>. The
<tt>set</tt> and <tt>map</tt> classes support unique keys; the <tt>multiset</tt>
and <tt>multimap</tt> classes support equivalent keys. For <tt>multiset</tt> and
<tt>multimap</tt>, <tt>insert</tt><ins>, <tt>emplace</tt>,</ins> and
<tt>erase</tt> preserve the relative ordering of equivalent elements.
</p></blockquote>

</li>

<li>
<p>
Modify Table 102 &mdash; Associative container requirements in 
23.2.4 [associative.reqmts]:
</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<br />pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>

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

<tr>
<td><tt>a_eq.emplace(args)</tt></td>
<td><tt>iterator</tt></td>
<td>[&hellip;] <i>Effects:</i> Inserts a <tt>T</tt> object <tt>t</tt> constructed with
<tt>std::forward&lt;Args&gt;(args)...</tt> and returns the iterator pointing to
the newly inserted element. <ins>If a range containing elements equivalent to
<tt>t</tt> exists in <tt>a_eq</tt>, <tt>t</tt> is inserted at the end of that
range.</ins></td>
<td>logarithmic</td>
</tr>

<tr>
<td><tt>a.emplace_hint(p, args)</tt></td>
<td><tt>iterator</tt></td>
<td>equivalent to <tt>a.emplace(std::forward&lt;Args&gt;(args)...)</tt>. Return
value is an iterator pointing to the element with the key equivalent to the
newly inserted element. <del>The <tt>const_iterator p</tt> is a hint pointing to
where the search should start.</del> <ins>The element is inserted as close as
possible to the position just prior to <tt>p</tt>.</ins> <del>Implementations
are permitted to ignore the hint.</del></td>
<td>logarithmic in general, but amortized constant if the element is inserted
right <del>after</del> <ins>before</ins> <tt>p</tt></td>
</tr>

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

</table>
</blockquote>

</li>

<li>
<p>
Modify 23.2.4 [associative.reqmts], p. 9:
</p>

<blockquote><p>
9 The <tt>insert</tt> <ins>and <tt>emplace</tt></ins> members shall not affect
the validity of iterators and references to the container, and the
<tt>erase</tt> members shall invalidate only iterators and references to the
erased elements.
</p></blockquote>

</li>

<li>
<p>
Modify 23.2.4.1 [associative.reqmts.except], p. 2:
</p>

<blockquote><p>
2 For associative containers, if an exception is thrown by any operation from
within an <tt>insert()</tt> <ins> or <tt>emplace()</tt></ins> function inserting
a single element, the <del><tt>insert()</tt> function</del> <ins>insertion</ins>
has no effect.
</p></blockquote>

</li>

<li>
<p>
Modify 23.2.5 [unord.req], p. 13 and p. 14:
</p>

<blockquote>
<p>
6 An unordered associative container supports <i>unique keys</i> if it may
contain at most one element for each key. Otherwise, it supports <i>equivalent
keys</i>. <tt>unordered_set</tt> and <tt>unordered_map</tt> support unique keys.
<tt>unordered_multiset</tt> and <tt>unordered_multimap</tt> support equivalent
keys. In containers that support equivalent keys, elements with equivalent keys
are adjacent to each other in the iteration order of the container. Thus, although 
the absolute order of elements in an unordered container is not specified, its 
elements are grouped into <i>equivalent-key groups</i> such that all elements of each 
group have equivalent keys. Mutating operations on unordered containers shall 
preserve the relative order of elements within each equivalent-key group unless 
otherwise specified.
</p>

<p>[&hellip;]</p>

<p>
13 The <tt>insert</tt> <ins>and <tt>emplace</tt></ins> members shall not affect
the validity of references to container elements, but may invalidate all
iterators to the container. The erase members shall invalidate only iterators
and references to the erased elements.
</p>

<p>
14 The <tt>insert</tt> <ins>and <tt>emplace</tt></ins> members shall not affect
the validity of iterators if <tt>(N+n) &lt; z * B</tt>, where <tt>N</tt> is the
number of elements in the container prior to the insert operation, <tt>n</tt> is
the number of elements inserted, <tt>B</tt> is the container's bucket count, and
<tt>z</tt> is the container's maximum load factor.
</p>
</blockquote>

</li>

<li>
<p>
Modify 23.2.5.1 [unord.req.except], p. 2:
</p>

<blockquote><p>
2 For unordered associative containers, if an exception is thrown by any
operation other than the container's hash function from within an
<tt>insert()</tt> <ins>or <tt>emplace()</tt></ins> function inserting a single
element, the <del><tt>insert()</tt></del> <ins>insertion</ins>
<del>function</del> has no effect.
</p></blockquote>

</li>
</ol>






<hr>
<h3><a name="1279"></a>1279. forbid <tt>[u|bi]nary_function</tt> specialization</h3>
<p><b>Section:</b> D.10.1 [depr.base] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2009-11-30 <b>Last modified:</b> 2011-03-25</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
A program should not be allowed to add specialization of class templates
<tt>unary_function</tt> and <tt>binary_function</tt>, in force of 17.6.4.2.1 [namespace.std]/1.
If a program were allowed to specialize these templates, the library could no
longer rely on them to provide the intended typedefs or there might be other
undesired interactions.
</p>

<p><i>[
2010-03-27 Daniel adds:
]</i></p>


<blockquote><p>
Accepting issue <a href="lwg-defects.html#1290">1290</a> would resolve this issue as NAD editorial.
</p></blockquote>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote><p>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3145.html">n3145</a> would resolve this issue as NAD editorial.
</p></blockquote>

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


<blockquote><p>
Pete: Is this issue actually addressed by N3198, or did deprecating unary/binary_function?
<p/>
We determined that this issue is NOT resolved and that it must be resolved or else 
N3198 could break code that does specialize unary&frasl;binary function.
<p/>
Matt: don't move to NAD
<p/>
Howard: I suggest we go further and move 1279 to ready for Madrid.
<p/>
Group: Agrees move 1279 to ready for Madrid 
</p></blockquote>

<p>
Previous proposed resolution:
</p>

<blockquote><p>
1 The following <del>classes</del> <ins>class templates</ins> are provided to
simplify the typedefs of the argument and result types<del>:</del><ins>. A
program shall not declare specializations of these templates.</ins>
</p></blockquote>

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


<blockquote><p>
This meeting outcome was not properly reflected in the proposed resolution. I
also adapted the suggested wording to the N3242 numbering and content state.
During this course of action it turned out that the first suggested wording
change has already been applied.
</p></blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change paragraph D.10.1 [depr.base]/1 as follows:
</p>

<blockquote><p>
1 The class templates <tt>unary_function</tt> and <tt>binary_function</tt> are deprecated. 
<ins>A program shall not declare specializations of these templates.</ins>
</p></blockquote>





<hr>
<h3><a name="1310"></a>1310. <tt>forward_list splice_after</tt> from lvalues</h3>
<p><b>Section:</b> 23.3.4.6 [forwardlist.ops] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2010-02-05 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>
We've moved <a href="lwg-defects.html#1133">1133</a> to Tentatively Ready and I'm fine with that.
</p>

<p>
<a href="lwg-defects.html#1133">1133</a> adds lvalue-references to the <tt>splice</tt> signatures for <tt>list</tt>.  So now
<tt>list</tt> can <tt>splice</tt> from lvalue and rvalue lists (which was the intent of the
original move papers btw).  During the discussion of this issue it was mentioned
that if we want to give the same treatment to <tt>forward_list</tt>, that should be a
separate issue.
</p>

<p>
This is that separate issue.
</p>

<p>
Consider the following case where you want to splice elements from one place in
a <tt>forward_list</tt> to another.  Currently this must be coded like so:
</p>

<blockquote><pre>
fl.splice_after(to_here, std::move(fl), from1, from2);
</pre></blockquote>

<p>
This looks pretty shocking to me.  I would expect to be able to code instead:
</p>

<blockquote><pre>
fl.splice_after(to_here, fl, from1, from2);
</pre></blockquote>

<p>
but we currently don't allow it.
</p>

<p>
When I say <tt>move(fl)</tt>, I consider that as saying that I don't care about
the value of <tt>fl</tt> any more (until I assign it a new value).  But in the
above example, this simply isn't true.  I do care about the value of <tt>fl</tt>
after the move, and I'm not assigning it a new value.  I'm merely permuting its
current value.
</p>

<p>
I propose adding <tt>forward_list&amp;</tt> overloads to the 3
<tt>splice_after</tt> members.  For consistency's sake (principal of least
surprise) I'm also proposing to overload <tt>merge</tt> this way as well.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add to the synopsis of 23.3.4.1 [forwardlist.overview]:
</p>

<blockquote><pre>
template &lt;class T, class Allocator = allocator&lt;T&gt; &gt;
class forward_list {
public:
  ...
  // <i>[forwardlist.ops], forward_list operations:</i>
  <ins>void splice_after(const_iterator p, forward_list&amp; x);</ins>
  void splice_after(const_iterator p, forward_list&amp;&amp; x);
  <ins>void splice_after(const_iterator p, forward_list&amp; x, const_iterator i);</ins>
  void splice_after(const_iterator p, forward_list&amp;&amp; x, const_iterator i);
  <ins>void splice_after(const_iterator p, forward_list&amp; x,
                    const_iterator first, const_iterator last);</ins>
  void splice_after(const_iterator p, forward_list&amp;&amp; x,
                    const_iterator first, const_iterator last);
  ...
  <ins>void merge(forward_list&amp; x);</ins>
  void merge(forward_list&amp;&amp; x);
  <ins>template &lt;class Compare&gt; void merge(forward_list&amp; x, Compare comp);</ins>
  template &lt;class Compare&gt; void merge(forward_list&amp;&amp; x, Compare comp);
  ...
};
</pre></blockquote>

<p>
Add to the signatures of 23.3.4.6 [forwardlist.ops]:
</p>

<blockquote>
<pre>
<ins>void splice_after(const_iterator p, forward_list&amp; x);</ins>
void splice_after(const_iterator p, forward_list&amp;&amp; x);
</pre>
<blockquote>
<p>1 ...</p>
</blockquote>

<pre>
<ins>void splice_after(const_iterator p, forward_list&amp; x, const_iterator i);</ins>
void splice_after(const_iterator p, forward_list&amp;&amp; x, const_iterator i);
</pre>
<blockquote>
<p>4 ...</p>
</blockquote>

<pre>
<ins>void splice_after(const_iterator p, forward_list&amp; x,
                const_iterator first, const_iterator last);</ins>
void splice_after(const_iterator p, forward_list&amp;&amp; x,
                const_iterator first, const_iterator last);
</pre>
<blockquote>
<p>7 ...</p>
</blockquote>

<pre>
<ins>void merge(forward_list&amp; x);</ins>
void merge(forward_list&amp;&amp; x);
<ins>template &lt;class Compare&gt; void merge(forward_list&amp; x, Compare comp);</ins>
template &lt;class Compare&gt; void merge(forward_list&amp;&amp; x, Compare comp);
</pre>
<blockquote>
<p>16 ...</p>
</blockquote>

</blockquote>






<hr>
<h3><a name="1320"></a>1320. Header for <tt>iter_swap</tt></h3>
<p><b>Section:</b> 24.3 [iterator.synopsis] <b>Status:</b> <a href="lwg-active.html#NAD Future">Tentatively NAD Future</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2010-02-16 <b>Last modified:</b> 2011-03-24</p>
<p><b>Discussion:</b></p>
<p>
The <tt>iter_swap</tt> function template appears in the
<tt>&lt;algorithm&gt;</tt> header, yet its main use is in building further
algorithms, not calling existing ones. The main clients are implementers of data
structures and their iterators, so it seems most appropriate to place the
template in the <tt>&lt;iterator&gt;</tt> header instead.
</p>

<p>
Note that this is not an issue for implementers of the standard library, as they
rarely use the standard headers directly, designing a more fine-grained set of
headers for their own internal use.  This option is not available to customers
of the standard library.
</p>

<p>
Note that we cannot remove <tt>iter_swap</tt> from <tt>&lt;algorithm&gt;</tt>
without breaking code, but there is no reason we cannot offer the same
declaration via two standard headers.  Alternatively, require
<tt>&lt;algorithm&gt;</tt> to <tt>#include &lt;iterator&gt;</tt>, but
introducing the dependency on the iterator adaptors seems un-necessary.
</p>

<p><i>[
]</i></p>


<p>
Discussed possibly moving to <tt>&lt;utility&gt;</tt> but don't like that. Some not seeing this 
as a defect, and want to keep it in <tt>&lt;algorithm&gt;</tt>. No one seems to feel strongly 
about moving to <tt>&lt;iterator&gt;</tt>.
</p>


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

<p>
Add the declaration of <tt>iter_swap</tt> to the <tt>&lt;iterator&gt;</tt>
header synopsis (24.3 [iterator.synopsis]), with a note that it is
documented in clause 25 [algorithms].
</p>

<blockquote><pre>
...
template &lt;class T, size_t N&gt; T* end(T (&amp;array)[N]);

<ins><i>// documented in 25 [algorithms]</i>
template&lt;class ForwardIterator1, class ForwardIterator2&gt;
  void iter_swap(ForwardIterator1 a, ForwardIterator2 b);</ins>
</pre></blockquote>






<hr>
<h3><a name="1330"></a>1330. Move container requirements into requirements tables</h3>
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="lwg-active.html#Deferred">Deferred</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2010-03-10 <b>Last modified:</b> 2011-03-24</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#Deferred">Deferred</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Abstract:
</p>
<p>
In general, it seems that in a couple of places container behavior is
not described in requirement tables although it is a general behavior.
</p>

<p>
History:
</p>

<p>
Issue <a href="lwg-defects.html#676">676</a> added move semantics to unordered containers.
For the added insert functions the Editor requested to put their
semantic description into a requirements table rather than describing
them for each container individually. The text however was taken from
the associative containers, where we also have the semantics for each
container described. Also, <a href="lwg-defects.html#1034">1034</a> is to some extend
requesting a clarification of the requirement tables and it turned out
that in other places we have the same problem (e.g. we have no general
requirement for type pointer and const_pointer although each container
has them with issue <a href="lwg-defects.html#1306">1306</a>).
</p>

<p>
From my personal list of functions in requirement tables
and containers, the following types/functions are missing in
requirement tables:
</p>

<ul>
<li>
<tt>pointer</tt>, <tt>const_pointer</tt> in Table 91 (container requirements)
</li>
<li>
<p>
all copy constructors, copy constructors with allocator,
 assignment operators, and insert operators
 with move semantics for associative and unordered containers
</p>
<blockquote><pre>
ContType c1(c2&amp;&amp;)
ContType c1(c2&amp;&amp;,alloc)
c1 = c2&amp;&amp;
c.insert(val&amp;&amp;)
c.insert(pos,val&amp;&amp;)
</pre></blockquote>
</li>
</ul>

<p>
As a special case, we lack the following requirements for all sequence
containers BUT array (so special wording or a new container category is
required):
</p>

<ul>
<li>
<p>
constructor with only a size argument
</p>
<blockquote><pre>
ContType c(num)
</pre></blockquote>
</li>
<li>
<p>
copy constructor with allocator and move semantics
</p>
<blockquote><pre>
ContType c1(c2&amp;&amp;,alloc)
</pre></blockquote>
</li>
<li>
<p>
all constructors that insert multiple elements with additional allocator
</p>
<blockquote><pre>
ContType c(num, val,alloc)
ContType c(beg, end,alloc)
ContType c(initlist,alloc)
</pre></blockquote>
</li>
<li>
<p>
all resize functiuons:
</p>
<blockquote><pre>
c.resize(num)
c.resize(num,val)
</pre></blockquote>
</li>
</ul>

<p>
Note that we also might have to add additional requirements on other
places for sequence containers because having an allocator requires
additional statements for the treatment of the allocators. E.g. swap for
containers with allocators is not specified in any requirement table.
</p>

<p>
And finally, if we have the requirements in the requirements tables, we
can remove the corresponding descriptions for the individual container.
However, note that sequence container requirements have NO complexity
column, so that we still need container specific descriptions for the
functions listed there.
</p>

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

<p>
While there is consensus that further cleaning up the container requirement
tables would be a good thing, there is no feeling that this <em>must</em>
be done in time for 0x.  The issue remains open, but Deferred.
</p>




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





<hr>
<h3><a name="1332"></a>1332. Let Hash objects throw!</h3>
<p><b>Section:</b> 17.6.3.4 [hash.requirements] <b>Status:</b> <a href="lwg-active.html#Voting">Voting</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2010-03-26 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Voting">Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The currently added <tt>Hash</tt> requirements demand in Table 40 &mdash; <tt>Hash</tt>
requirements [hash]:
</p>

<blockquote>
<table border="1">

<caption>Table 40 &mdash; Hash requirements [hash]</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Requirement</th>
</tr>

<tr>
<td><tt>h(k)</tt></td>
<td><tt>size_t</tt></td>
<td>Shall not throw exceptions. [..]</td>
</tr>

</table>
</blockquote>

<p>
While it surely is a generally accepted idea that hash function objects
<i>should</i> not throw exceptions, this basic constraint for such a fundamental
requirement set does neither match the current library policy nor real world
cases:
</p>

<ol>
<li>
There are little known situations where a swap or move operation may throw an
exception and in some popular domains such functions are <em>required</em> not
to throw. But the library invested already efforts for good reasons to require
"working" container implementations in the presence of throwing move or swap
operations, see e.g. 23.2.4.1 [associative.reqmts.except], 23.2.5.1 [unord.req.except].
</li>

<li>
The container library is already specified to cope with potentially throwing
comparers, predicates, <i>and</i> hash function objects, see above.
</li>

<li>
<p>
The new definition goes beyond the original hash requirements as specified
by SGI library in regard to the exception requirement:
</p>
<blockquote><p>
<a href="http://www.sgi.com/tech/stl/HashFunction.html">http://www.sgi.com/tech/stl/HashFunction.html</a>
</p></blockquote>
</li>

<li>
There are indeed real-world examples of potentially throwing hash functions,
typically when the proxy pattern is used and when the to-be hashed proxied
instance is some <i>volatile</i> object, e.g. a file or internet resource, that
might suddenly be unavailable at the time of hashing.
</li>

<li>
With the new <tt>noexcept</tt> language facility libraries can still take
advantage of no-throw guarantees of hasher functions with stricter guarantees.
</li>
</ol>

<p>
Even though the majority of all known move, swap, and hash functions won't throw
and in some cases <em>must</em> not throw, it seems like unnecessary
over-constraining the definition of a Hash functor not to propagate exceptions
in any case and it contradicts the general principle of C++ to impose such a
requirement for this kind of fundamental requirement.
</p>

<p><i>[
2010-11-11 Daniel asks the working group whether they would prefer a replacement
for the second bullet of the proposed resolution (a result of discussing this
with Alberto) of the form:
]</i></p>


<p>
Add to 20.8.12 [unord.hash]/1 a new bullet:
</p>

<blockquote>
<p>
1 The unordered associative containers defined in Clause 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>, the
instantiation <tt>hash&lt;Key&gt;</tt> shall:
</p>
<ul>
<li>
satisfy the <tt>Hash</tt> requirements (20.2.4), with <tt>Key</tt> as the
function call argument type, the <tt>DefaultConstructible</tt> requirements
(33), the <tt>CopyAssignable</tt> requirements (37),
</li>
<li>
be swappable (20.2.2) for lvalues,
</li>
<li>
provide two nested types <tt>result_type</tt> and <tt>argument_type</tt> which
shall be synonyms for <tt>size_t</tt> and <tt>Key</tt>, respectively,
</li>
<li>
satisfy the requirement that if <tt>k1 == k2</tt> is true, <tt>h(k1) ==
h(k2)</tt> is also true, where <tt>h</tt> is an object of type
<tt>hash&lt;Key&gt;</tt> and <tt>k1</tt> and <tt>k2</tt> are objects of type
<tt>Key</tt><ins>,</ins><del>.</del>
</li>
<li>
<ins>satisfy the requirement <tt>noexcept(h(k)) == true</tt>, where <tt>h</tt> is an object
of type <tt>hash&lt;Key&gt;</tt> and <tt>k</tt> is an object of type <tt>Key</tt>, unless 
<tt>hash&lt;Key&gt;</tt> is a user-defined specialization that depends on at least one user-defined type.</ins>
</li>
</ul>
</blockquote>



<p><i>[Batavia: Closed as NAD Future, then reopened. See the wiki for Tuesday.]</i></p>


<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Change Table 26 &mdash; <tt>Hash</tt> requirements [tab:hash] as indicated:
</p>

<blockquote>
<table border="1">

<caption>Table 26 &mdash; <tt>Hash</tt> requirements [tab:hash]</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Requirement</th>
</tr>

<tr>
<td><tt>h(k)</tt></td>
<td><tt>size_t</tt></td>
<td><del>Shall not throw exceptions.</del> [&hellip;]</td>
</tr>

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

<li>
<p>
Add to 20.8.12 [unord.hash] p. 1 a new bullet:
</p>

<blockquote>
<p>
1 The unordered associative containers defined in Clause 23.5 [unord] 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>, the
instantiation <tt>hash&lt;Key&gt;</tt> shall:
</p>
<ul>
<li>
satisfy the <tt>Hash</tt> requirements ([hash.requirements]), with <tt>Key</tt> as the
function call argument type, the <tt>DefaultConstructible</tt> requirements
(Table [defaultconstructible]), the <tt>CopyAssignable</tt> requirements (Table [copyassignable]),
</li>
<li>
be swappable ([swappable.requirements]) for lvalues,
</li>
<li>
provide two nested types <tt>result_type</tt> and <tt>argument_type</tt> which
shall be synonyms for <tt>size_t</tt> and <tt>Key</tt>, respectively,
</li>
<li>
satisfy the requirement that if <tt>k1 == k2</tt> is true, <tt>h(k1) ==
h(k2)</tt> is also true, where <tt>h</tt> is an object of type
<tt>hash&lt;Key&gt;</tt> and <tt>k1</tt> and <tt>k2</tt> are objects of type
<tt>Key</tt><ins>,</ins><del>.</del>
</li>
<li>
<ins>satisfy the requirement that the expression <tt>h(k)</tt>, where <tt>h</tt>
is an object of type <tt>hash&lt;Key&gt;</tt> and <tt>k</tt> is an object of
type <tt>Key</tt>, shall not throw an exception, unless
<tt>hash&lt;Key&gt;</tt> is a user-defined specialization that depends on at
least one user-defined type.</ins>
</li>
</ul>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="1349"></a>1349. [FCD] <tt>swap</tt> should not throw</h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-65</b></p>
<p>
Nothrowing <tt>swap</tt> operations are key to many C++ idioms,
notably the common copy/swap idiom to provide the
strong exception safety guarantee.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>


<p>
Where possible, all library types should provide a
<tt>swap</tt> operation with an exception specification
guaranteeing no exception shall propagate.
Where <tt>noexcept(true)</tt> cannot be guaranteed to
not terminate the program, and the <tt>swap</tt> in
questions is a template, an exception specification
with the appropriate conditional expression could
be specified.
</p>

<p><i>[2011-03-13: Daniel comments and drafts wording]</i></p>


<p>During a survey of the library some main categories for
potential <tt>noexcept</tt> <tt>swap</tt> function could be isolated:</p>

<ol>
<li>Free <tt>swap</tt> functions that are specified in terms of already
<tt>noexcept</tt> <tt>swap</tt> member functions, like that of <tt>valarray</tt>.</li>

<li>Free <tt>swap</tt> of <tt>std::function</tt>, and member and free <tt>swap</tt> 
functions of stream buffers and streams where considered but rejected as good candidates, 
because of the danger to potentially impose requirements of existing implementations. 
These functions could be reconsidered as candidates in the future.</li>
</ol>

<p>Negative list:</p>

<ol>
<li>Algorithms related to swap, like <tt>iter_swap</tt>, have <em>not</em> been touched,
because there are no fundamental exceptions constraints on iterator operations in general
(only for specific types, like library container iterators)</li>
</ol>

<p>While evaluating the current state of <tt>swap</tt> functions 
of library components it was observed that several conditional <tt>noexcept</tt>
functions have turned into unconditional ones, e.g. in the
header <tt>&lt;utility&gt;</tt> synopsis:</p>

<blockquote><pre>
template&lt;class T&gt; void swap(T&amp; a, T&amp; b) noexcept;
</pre></blockquote>

<p>The suggested resolution shown below also attempts to fix
these cases.</p>

<p><i>[2011-03-22 Daniel redrafts to satisfy new criteria for applying <tt>noexcept</tt>.
Parts resolved by N3263-v2 and D3267 are not added here.]</i></p>




<p><b>Proposed resolution:</b></p>
<ol>
<li><p>Edit 20.2 [utility] p. 2, header <tt>&lt;utility&gt;</tt> synopsis <em>and</em> 
20.2.2 [utility.swap] before p. 1, as indicated (The intent is to fix an editorial
omission):</p>

<blockquote><pre>
template&lt;class T&gt; void swap(T&amp; a, T&amp; b) noexcept<ins>(<i>see below</i>)</ins>;
</pre></blockquote>
</li>

<li><p>Edit the prototype declaration in 20.3.2 [pairs.pair] before p. 34 as indicated (The intent 
is to fix an editorial omission):</p>

<blockquote><pre>
void swap(pair&amp; p) noexcept<ins>(<i>see below</i>)</ins>;
</pre></blockquote>
</li>

<li><p>Edit 20.4.1 [tuple.general] p. 2 header <tt>&lt;tuple&gt;</tt> synopsis <em>and</em> 
20.4.2.9 [tuple.special] before p. 1 as indicated (The intent is to fix an editorial omission):</p>

<blockquote><pre>
template &lt;class... Types&gt;
void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y) noexcept<ins>(<i>see below</i>)</ins>;
</pre></blockquote>
</li>

<li><p>Edit 20.4.2 [tuple.tuple], class template <tt>tuple</tt> synopsis <em>and</em>
20.4.2.3 [tuple.swap] before p. 1 as indicated (The intent is to fix an editorial omission):</p>

<blockquote><pre>
void swap(tuple&amp;) noexcept<ins>(<i>see below</i>)</ins>;
</pre></blockquote>
</li>

<li><p>Edit 20.6.2 [memory.syn] p. 1, header <tt>&lt;memory&gt;</tt> synopsis as indicated (The 
intent is to fix an editorial omission of the proposing paper N3195).</p>

<blockquote><pre>
template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b) <ins>noexcept</ins>;
</pre></blockquote>
</li>

<li><p>Edit header <tt>&lt;valarray&gt;</tt> synopsis, 26.6.1 [valarray.syn] <em>and</em> 
26.6.3.4 [valarray.special] before p. 1 as indicated 
<em>[Drafting comment: The corresponding member swap is already noexcept]</em>:</p>

<blockquote><pre>
template&lt;class T&gt; void swap(valarray&lt;T&gt;&amp;, valarray&lt;T&gt;&amp;) <ins>noexcept</ins>;
</pre></blockquote>
</li>

</ol>





<hr>
<h3><a name="1371"></a>1371. [FCD] standard exceptions require stronger no-throw guarantees</h3>
<p><b>Section:</b> 19 [diagnostics] <b>Status:</b> <a href="lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</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><b>Addresses GB-75</b></p>
<p>
None of the exception types defined in clause 19 are
allowed to throw an exception on copy or move
operations, but there is no clear specification that the
operations have an exception specification to prove it.
Note that the implicitly declared constructors, taking the
exception specification from their base class (ultimately
<tt>std::exception</tt>) will implicitly generate a <tt>noexcept</tt>
exception specification if all of their data members
similarly declare <tt>noexcept</tt> operations. As the
representation is unspecified, we cannot assume nonthrowing
operations unless we explicitly state this as a
constraint on the implementation.
</p>

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<p>
Add a global guarantee that all exception types
defined in clause 19 that rely on implicitly declared
operations have a non-throwing exception
specification on those operations.
</p>

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

<p>
This is addressed by the current words in 18.8.1 [exception], p2
</p>
<blockquote><p>
Each standard library class <tt>T</tt> that derives from class <tt>exception</tt> 
shall have a publicly accessible copy constructor and a publicly accessible copy
assignment operator that do not exit with an exception.
</p></blockquote>



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





<hr>
<h3><a name="1374"></a>1374. [FCD] Clarify moved-from objects are &quot;toxic&quot;</h3>
<p><b>Section:</b> 17.6.3.1 [utility.arg.requirements] <b>Status:</b> <a href="lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</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#Tentatively NAD">Tentatively NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-85</b></p>
<p>
20.2.1 Table 34 "MoveConstructible requirements" says
"Note: rv remains a valid object. Its state is unspecified".
Some components give stronger guarantees. For
example, moved-from <tt>shared_ptr</tt>s are guaranteed <tt>empty</tt>
(20.9.11.2.1/25).
In general, what the standard really should say (preferably
as a global blanket statement) is that moved-from objects
can be destroyed and can be the destination of an
assignment. Anything else is radioactive. For example,
containers can be "emptier than empty". This needs to be
explicit and required generally.
</p>
<p>
Note: The last time that one of us mentioned "emptier
than empty" (i.e. containers missing sentinel nodes, etc.)
the objection was that containers can store sentinel nodes
inside themselves in order to avoid dynamically allocating
them. This is unacceptable because
</p>
<p>
(a) it forces existing implementations (i.e. Dinkumware's, Microsoft's,
IBM's,  etc.) to change for no good reason (i.e. permitting more
operations on moved-from objects), and 
</p>
<p>
(b) it invalidates end-iterators when swapping containers. (The Working
Paper currently permits end-iterator invalidation, which we
consider to be wrong, but that's a separate argument. In
any event, <em>mandating</em> end-iterator invalidation is very
different from permitting it.)
</p>

<p><i>[
Resolution proposed in ballot comment
]</i></p>

<p>
State as a general requirement that moved-from
objects can be destroyed and can be the
destination of an assignment. Any other use is
undefined behavior.
</p>


<p><b>Proposed resolution:</b></p>
<p>Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3241.html">N3241</a></p>





<hr>
<h3><a name="1385"></a>1385. [FCD] <tt>tuple_cat</tt> should be a single variadic signature</h3>
<p><b>Section:</b> 20.4.2.4 [tuple.creation] <b>Status:</b> <a href="lwg-active.html#Voting">Voting</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#tuple.creation">issues</a> in [tuple.creation].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Voting">Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-88</b></p>
<p>
The <tt>tuple_cat</tt> template consists of four overloads and that
can concatenate only two <tt>tuple</tt>s. A single variadic
signature that can concatenate an arbitrary number of
<tt>tuple</tt>s would be preferred.
</p>

<p><i>[
Resolution proposed by ballot comment:
]</i></p>


<blockquote><p>
Adopt a simplified form of the proposal in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2975.pdf">n2975</a>,
restricted to <tt>tuple</tt>s and neither requiring nor outlawing support for other <tt>tuple</tt>-like types.
</p></blockquote>

<p><i>[
2010 Rapperswil: Alisdair to provide wording.
]</i></p>


<p><i>[
2010-11-06: Daniel comments and proposes some alternative wording:
]</i></p>


<p>
There are some problems in the wording: First, even though the result type <tt>tuple&lt;<i>see below</i>&gt;</tt>
implies it, the specification of the contained tuple element types is missing. Second, the term &quot;<tt>tuple</tt> 
protocol&quot; is not defined anywhere and I see no reason why this normative wording should not be a non-normative
note. We could at least give a better approximation, maybe "tuple-like protocol" as indicated from header
<tt>&lt;utility&gt;</tt> synopsis. Further, it seems to me that the effects need to contain a combination of <tt>std::forward</tt>
with the call of <tt>get</tt>. Finally I suggest to replace the requirements <tt>Move/CopyConstructible</tt>
by proper usage of <tt>is_constructible</tt>, as indicated by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.
</p>

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

<p>
Moved to Ready with Daniel's improved wording.
</p>


<p><b>Proposed resolution:</b></p>
<p>Note: This alternate proposed resolution works only if <a href="lwg-defects.html#1191">1191</a> has been accepted.</p>

<ol>
<li>Change 20.4.1 [tuple.general] p. 2, header <tt>&lt;tuple&gt;</tt> synopsis, as indicated:
<blockquote><pre>
namespace std {

...

// <i>20.4.2.4, tuple creation functions:</i>
const unspecified ignore;

template &lt;class... Types&gt;
  tuple&lt;<i>VTypes</i>...&gt; make_tuple(Types&amp;&amp;...);
  template &lt;class... Types&gt;
  tuple&lt;<i>ATypes</i>...&gt; forward_as_tuple(Types&amp;&amp;...);
  
template&lt;class... Types&gt;
  tuple&lt;Types&amp;...&gt; tie(Types&amp;...);
  
<del>template &lt;class... TTypes, class... UTypes&gt;
  tuple&lt;TTypes..., UTypes...&gt; tuple_cat(const tuple&lt;TTypes...&gt;&amp;, const tuple&lt;UTypes...&gt;&amp;);
template &lt;class... TTypes, class... UTypes&gt;
  tuple&lt;TTypes..., UTypes...&gt; tuple_cat(tuple&lt;TTypes...&gt;&amp;&amp;, const tuple&lt;UTypes...&gt;&amp;);
template &lt;class... TTypes, class... UTypes&gt;
  tuple&lt;TTypes..., UTypes...&gt; tuple_cat(const tuple&lt;TTypes...&gt;&amp;, tuple&lt;UTypes...&gt;&amp;&amp;);
template &lt;class... TTypes, class... UTypes&gt;
  tuple&lt;TTypes..., UTypes...&gt; tuple_cat(tuple&lt;TTypes...&gt;&amp;&amp;, tuple&lt;UTypes...&gt;&amp;&amp;);</del>
<ins>template &lt;class... Tuples&gt;
  tuple&lt;<i>CTypes</i>...&gt; tuple_cat(Tuples&amp;&amp;...);</ins>

...

</pre></blockquote>
</li>
<li>Change 20.4.2.4 [tuple.creation] as indicated:
<blockquote>
<pre><del>template &lt;class... TTypes, class... UTypes&gt;
  tuple&lt;TTypes..., UTypes...&gt; tuple_cat(const tuple&lt;TTypes...&gt;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);</del></pre>
<blockquote><p><del>
8 <i>Requires</i>: All the types in <tt>TTypes</tt> shall be <tt>CopyConstructible</tt> (Table 35). All the types in 
<tt>UTypes</tt> shall be <tt>CopyConstructible</tt> (Table 35).
</del></p></blockquote>
<blockquote><p><del>
9 <i>Returns</i>: A <tt>tuple</tt> object constructed by copy constructing its first <tt>sizeof...(TTypes)</tt> elements 
from the corresponding elements of <tt>t</tt> and copy constructing its last <tt>sizeof...(UTypes)</tt> elements from the 
corresponding elements of <tt>u</tt>.
</del></p></blockquote>
<pre><del>template &lt;class... TTypes, class... UTypes&gt;
  tuple&lt;TTypes..., UTypes...&gt; tuple_cat(tuple&lt;TTypes...&gt;&amp;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);</del></pre>
<blockquote><p><del>
10 <i>Requires</i>: All the types in <tt>TTypes</tt> shall be <tt>MoveConstructible</tt> (Table 34). All the types in 
<tt>UTypes</tt> shall be <tt>CopyConstructible</tt> (Table 35).
</del></p></blockquote>
<blockquote><p><del>
11 <i>Returns</i>: A <tt>tuple</tt> object constructed by move constructing its first <tt>sizeof...(TTypes)</tt> elements 
from the corresponding elements of <tt>t</tt> and copy constructing its last <tt>sizeof...(UTypes)</tt> elements from the 
corresponding elements of <tt>u</tt>.
</del></p></blockquote>
<pre><del>template &lt;class... TTypes, class... UTypes&gt;
  tuple&lt;TTypes..., UTypes...&gt; tuple_cat(const tuple&lt;TTypes...&gt;&amp; t, tuple&lt;UTypes...&gt;&amp;&amp; u);</del></pre>
<blockquote><p><del>
12 <i>Requires</i>: All the types in <tt>TTypes</tt> shall be <tt>CopyConstructible</tt> (Table 35). All the types in 
<tt>UTypes</tt> shall be <tt>MoveConstructible</tt> (Table 34).
</del></p></blockquote>
<blockquote><p><del>
13 <i>Returns</i>: A <tt>tuple</tt> object constructed by copy constructing its first <tt>sizeof...(TTypes)</tt> elements 
from the corresponding elements of <tt>t</tt> and move constructing its last <tt>sizeof...(UTypes)</tt> elements from the 
corresponding elements of <tt>u</tt>.
</del></p></blockquote>
<pre><del>template &lt;class... TTypes, class... UTypes&gt;
  tuple&lt;TTypes..., UTypes...&gt; tuple_cat(tuple&lt;TTypes...&gt;&amp;&amp; t, tuple&lt;UTypes...&gt;&amp;&amp; u);</del></pre>
<blockquote><p><del>
14 <i>Requires</i>: All the types in <tt>TTypes</tt> shall be <tt>MoveConstructible</tt> (Table 34). All the types in 
<tt>UTypes</tt> shall be <tt>MoveConstructible</tt> (Table 34).
</del></p></blockquote>
<blockquote><p><del>
15 <i>Returns</i>: A <tt>tuple</tt> object constructed by move constructing its first <tt>sizeof...(TTypes)</tt> elements 
from the corresponding elements of <tt>t</tt> and move constructing its last <tt>sizeof...(UTypes)</tt> elements from the 
corresponding elements of <tt>u</tt>.
</del></p></blockquote>
<pre><ins>template &lt;class... Tuples&gt;
  tuple&lt;<i>CTypes</i>...&gt; tuple_cat(Tuples&amp;&amp;... tpls);
</ins></pre>
<blockquote><p><ins>
8 Let <tt>Ti</tt> be the <tt><i>i</i></tt><sup>th</sup> type in <tt>Tuples</tt>, <tt>Ui</tt> be <tt>remove_reference&lt;Ti&gt;::type</tt>,
and <tt>tp<sub><i>i</i></sub></tt> be the <tt><i>i</i></tt><sup>th</sup> parameter in the function parameter pack <tt>tpls</tt>, where all 
indexing is zero-based in the following paragraphs of this sub-clause [tuple.creation].
</ins></p></blockquote>
<blockquote><p><ins>
9 <i>Requires</i>: For all <tt><i>i</i></tt>, <tt>Ui</tt> shall be the type <i>cv<sub><tt>i</tt></sub>&nbsp;</i><tt>tuple&lt;Args<sub><i>i</i></sub>...&gt;</tt>, 
where <i>cv<sub><tt>i</tt></sub></i> is the (possibly empty) <tt><i>i</i></tt><sup>th</sup> <i>cv</i>-qualifier-seq, and 
<tt>Args<sub><i>i</i></sub></tt> is the parameter pack representing the element types in <tt>Ui</tt>. Let <tt>Aik</tt> be the 
<tt><i>k<sub>i</sub></i></tt><sup>th</sup> type in <tt>Args<sub><i>i</i></sub></tt>, then for all <tt>Aik</tt> the following 
requirements shall be satisfied: If <tt>Ti</tt> is deduced as an lvalue reference type, then 
<tt>is_constructible&lt;Aik, <i>cv<sub>i</sub>&nbsp;</i>Aik&amp;&gt;::value == true</tt>, otherwise 
<tt>is_constructible&lt;Aik, <i>cv<sub>i</sub>&nbsp;</i>Aik&amp;&amp;&gt;::value == true</tt>.
</ins></p></blockquote>
<blockquote><p><ins>
10 <i>Remarks</i>: The types in <tt><i>CTypes</i></tt> shall be equal to the ordered sequence of the expanded types
<tt>Args<sub>0</sub>..., Args<sub>1</sub>..., Args<sub><i>n</i>-1</sub>...</tt>, where <tt><i>n</i></tt> equals 
<tt>sizeof...(Tuples)</tt>. Let <tt><i>e<sub>i</sub></i>...</tt> be the <tt><i>i</i></tt><sup>th</sup> ordered 
sequence of tuple elements of the result <tt>tuple</tt> object corresponding to the type sequence 
<tt>Args<sub><i>i</i></sub></tt>.
</ins></p></blockquote>
<blockquote><p><ins>
11 <i>Returns</i>: A <tt>tuple</tt> object constructed by initializing
the <tt><i>k<sub>i</sub></i></tt><sup>th</sup> type element <tt>eik</tt> in <tt><i>e<sub>i</sub></i>...</tt>
with <tt>get&lt;<i>k<sub>i</sub></i>&gt;(std::forward&lt;Ti&gt;(tp<sub>i</sub>))</tt>
for each valid <tt><i>k<sub>i</sub></i></tt> and each element group <tt><i>e<sub>i</sub></i></tt> in order. 
</ins></p></blockquote>
<blockquote><p><ins>
12 [<i>Note</i>: An implementation may support additional types in the parameter pack <tt>Tuples</tt>, such as
<tt>pair</tt> and <tt>array</tt> that support the <tt>tuple</tt>-like protocol. &mdash; <i>end note</i>]
</ins></p></blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="1401"></a>1401. [FCD] <tt>unique_ptr&lt;T&gt; == nullptr</tt></h3>
<p><b>Section:</b> 20.6 [memory] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#memory">issues</a> in [memory].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-99</b></p>
<p>
One reason that the <tt>unique_ptr</tt> constructor taking a
<tt>nullptr_t</tt> argument is not <tt>explicit</tt> is to allow conversion
of <tt>nullptr</tt> to <tt>unique_ptr</tt> in contexts like equality
comparison. Unfortunately <tt>operator==</tt> for <tt>unique_ptr</tt> is a
little more clever than that, deducing template parameters for both
arguments. This means that <tt>nullptr</tt> does not get deduced
as <tt>unique_ptr</tt> type, and there are no other comparison
functions to match.
</p>

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote><p>
Add the following signatures to 20.6 [memory] p.1, <tt>&lt;memory&gt;</tt>
header synopsis:
</p><blockquote><pre>
template&lt;typename T, typename D&gt;
bool operator==(const unique_ptr&lt;T, D&gt; &amp; lhs, nullptr_t);
template&lt;typename T, typename D&gt;
bool operator==(nullptr_t, const unique_ptr&lt;T, D&gt; &amp; rhs);
template&lt;typename T, typename D&gt;
bool operator!=(const unique_ptr&lt;T, D&gt; &amp; lhs, nullptr_t);
template&lt;typename T, typename D&gt;
bool operator!=(nullptr_t, const unique_ptr&lt;T, D&gt; &amp; rhs);
</pre></blockquote>
</blockquote>

<p><i>[
2010-11-02 Daniel comments and provides a proposed resolution:
]</i></p>


<blockquote><p>
The same problem applies to <tt>shared_ptr</tt> as well: In both cases there are no
conversions considered because the comparison functions are templates. I agree with
the direction of the proposed resolution, but I believe it would be very surprising
and inconsistent, if given a smart pointer object <tt>p</tt>, the expression
<tt>p == nullptr</tt> would be provided, but not <tt>p &lt; nullptr</tt> and the
other relational operators. According to 5.9 [expr.rel] they are defined
if null pointer values meet other pointer values, even though the result is unspecified
for all except some trivial ones. But null pointer values are nothing special here: 
The Library already defines the relational operators for both <tt>unique_ptr</tt> and 
<tt>shared_ptr</tt> and the outcome of comparing non-null pointer values will be equally 
unspecified. If the idea of supporting <tt>nullptr_t</tt> arguments for relational
operators is not what the committee prefers, I suggest at least to consider to remove 
the existing relational operators for both <tt>unique_ptr</tt> and <tt>shared_ptr</tt>
for consistency. But that would not be my preferred resolution of this issue.
<p/>
The number of overloads triple the current number, but I think it is much clearer to 
provide them explicitly instead of adding wording that attempts to say that "sufficient overloads" are
provided. The following proposal makes the declarations explicit.
<p/>
Additionally, the proposal adds the missing declarations for some <tt>shared_ptr</tt>
comparison functions for consistency.
</p></blockquote>

<p><i>[
2010-11-03 Daniel adds:
]</i></p>


<p>
Issue <a href="lwg-defects.html#1297">1297</a> is remotely related. The following proposed resolution splits
<a href="#1401_extra_bullet">this bullet</a> into sub-bullets A and B. Sub-bullet A would 
also solve <a href="lwg-defects.html#1297">1297</a>, but sub-bullet B would not.
<p/>
A further remark in regard to the proposed semantics of the ordering of <tt>nullptr</tt>
against other pointer(-like) values: One might think that the following definition might
be superior because of simplicity:
</p>
<blockquote><pre>
template&lt;class T&gt;
bool operator&lt;(const shared_ptr&lt;T&gt;&amp; a, nullptr_t);
template&lt;class T&gt;
bool operator&gt;(nullptr_t, const shared_ptr&lt;T&gt;&amp; a);
</pre><blockquote><p>
<i>Returns</i>: <tt>false</tt>.
</p></blockquote></blockquote>
<p>
The underlying idea behind this approach is the assumption that nullptr corresponds
to the least ordinal pointer value. But this assertion does not hold for all supported
architectures, therefore this approach was not followed because it would lead to
the inconsistency, that the following assertion could fire: 
</p>
<blockquote><pre>
shared_ptr&lt;int&gt; p(new int);
shared_ptr&lt;int&gt; null;
bool v1 = p &lt; nullptr;
bool v2 = p &lt; null;
assert(v1 == v2);
</pre></blockquote>

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


<p>The current issue state is not acceptable, because the Batavia meeting
did not give advice whether choice A or B of bullet 3 should be applied.
Option B will now be removed and if this resolution is accepted, issue
<a href="lwg-defects.html#1297">1297</a> should be declared as resolved by <a href="lwg-active.html#1401">1401</a>.
This update also resyncs the wording with N3242.</p>



<p><b>Proposed resolution:</b></p>
<p>
Wording changes are against N3242.
</p>
<ol>
<li>Change 20.6.2 [memory.syn] p. 1, header <tt>&lt;memory&gt;</tt> synopsis as indicated.
<tt>noexcept</tt> specifications are only added, where the guarantee exists, that the function
shall no throw an exception (as replacement of &quot;<i>Throws</i>: Nothing&quot;. Note that
the <tt>noexcept</tt> additions to the <tt>shared_ptr</tt> comparisons are editorial, because
they are already part of the accepted paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3195.htm">n3195</a>:
<blockquote><pre>
namespace std {
  [&hellip;]
  // <i>[unique.ptr] Class unique_ptr:</i>
  template &lt;class T&gt; class default_delete;
  template &lt;class T&gt; class default_delete&lt;T[]&gt;;
  template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr;
  template &lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt;;

  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);
  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);
  template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator&lt;(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
  template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator&lt;=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
  template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator&gt;(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
  template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator&gt;=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);

  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator==(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t) noexcept;</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator==(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x) noexcept;</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator!=(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t) noexcept;</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator!=(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x) noexcept;</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator&lt;(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t);</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator&lt;(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x);</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator&lt;=(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t);</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator&lt;=(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x);</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator&gt;(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t);</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator&gt;(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x);</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator&gt;=(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t);</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator&gt;=(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x);</ins>
  
  // <i>[util.smartptr.weakptr], Class bad_weak_ptr:</i>
  class bad_weak_ptr;

  // <i>[util.smartptr.shared], Class template shared_ptr:</i>
  template&lt;class T&gt; class shared_ptr;

  // <i>[util.smartptr.shared.cmp], shared_ptr comparisons:</i>
  template&lt;class T, class U&gt;
  bool operator==(shared_ptr&lt;T&gt; const&amp; a, shared_ptr&lt;U&gt; const&amp; b) <ins> noexcept</ins>;
  template&lt;class T, class U&gt;
  bool operator!=(shared_ptr&lt;T&gt; const&amp; a, shared_ptr&lt;U&gt; const&amp; b) <ins> noexcept</ins>;
  template&lt;class T, class U&gt;
  bool operator&lt;(shared_ptr&lt;T&gt; const&amp; a, shared_ptr&lt;U&gt; const&amp; b) <ins> noexcept</ins>;
  template&lt;class T, class U&gt;
  bool operator&gt;(shared_ptr&lt;T&gt; const&amp; a, shared_ptr&lt;U&gt; const&amp; b) <ins> noexcept</ins>;
  template&lt;class T, class U&gt;
  bool operator&lt;=(shared_ptr&lt;T&gt; const&amp; a, shared_ptr&lt;U&gt; const&amp; b) <ins> noexcept</ins>;
  template&lt;class T, class U&gt;
  bool operator&gt;=(shared_ptr&lt;T&gt; const&amp; a, shared_ptr&lt;U&gt; const&amp; b) <ins> noexcept</ins>;

  <ins>template&lt;class T&gt;</ins>
  <ins>bool operator==(shared_ptr&lt;T&gt; const&amp; a, nullptr_t) noexcept;</ins>
  <ins>template&lt;class T&gt;</ins>
  <ins>bool operator==(nullptr_t, shared_ptr&lt;T&gt; const&amp; a) noexcept;</ins>
  <ins>template&lt;class T&gt;</ins>
  <ins>bool operator!=(shared_ptr&lt;T&gt; const&amp; a, nullptr_t) noexcept;</ins>
  <ins>template&lt;class T&gt;</ins>
  <ins>bool operator!=(nullptr_t, shared_ptr&lt;T&gt; const&amp; a) noexcept;</ins>
  <ins>template&lt;class T&gt;</ins>
  <ins>bool operator&lt;(shared_ptr&lt;T&gt; const&amp; a, nullptr_t) noexcept;</ins>
  <ins>template&lt;class T&gt;</ins>
  <ins>bool operator&lt;(nullptr_t, shared_ptr&lt;T&gt; const&amp; a) noexcept;</ins>
  <ins>template&gt;class T&gt;</ins>
  <ins>bool operator&gt;(shared_ptr&lt;T&gt; const&amp; a, nullptr_t) noexcept;</ins>
  <ins>template&gt;class T&gt;</ins>
  <ins>bool operator&gt;(nullptr_t, shared_ptr&lt;T&gt; const&amp; a) noexcept;</ins>
  <ins>template&lt;class T&gt;</ins>
  <ins>bool operator&lt;=(shared_ptr&lt;T&gt; const&amp; a, nullptr_t) noexcept;</ins>
  <ins>template&lt;class T&gt;</ins>
  <ins>bool operator&lt;=(nullptr_t, shared_ptr&lt;T&gt; const&amp; a) noexcept;</ins>
  <ins>template&gt;class T&gt;</ins>
  <ins>bool operator&gt;=(shared_ptr&lt;T&gt; const&amp; a, nullptr_t) noexcept;</ins>
  <ins>template&gt;class T&gt;</ins>
  <ins>bool operator&gt;=(nullptr_t, shared_ptr&lt;T&gt; const&amp; a) noexcept;</ins>

  [&hellip;]
}
</pre></blockquote>
</li>
<li>Change the synopsis just after 20.7.1 [unique.ptr] p. 6 as indicated:
<blockquote><pre>
namespace std {
  [&hellip;]
  
  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);
  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);
  template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator&lt;(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
  template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator&lt;=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
  template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator&gt;(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
  template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator&gt;=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);

  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator==(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t) noexcept;</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator==(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x) noexcept;</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator!=(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t) noexcept;</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator!=(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x) noexcept;</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator&lt;(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t);</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator&lt;(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x);</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator&lt;=(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t);</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator&lt;=(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x);</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator&gt;(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t);</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator&gt;(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x);</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator&gt;=(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t);</ins>
  <ins>template &lt;class T, class D&gt;</ins>
  <ins>bool operator&gt;=(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x);</ins>

}
</pre></blockquote>
</li>
<li><a name="1401_extra_bullet">This bullet does now only suggest the first approach:</a>
<p>Change 20.7.1.4 [unique.ptr.special] p. 4-7 as indicated and add a series of prototype
descriptions:</p>
<blockquote><pre>
template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator&lt;(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
</pre>

<blockquote>
<p>
<ins>? <i>Requires:</i> Let <tt>CT</tt> be <tt>common_type&lt;unique_ptr&lt;T1,
D1&gt;::pointer, unique_ptr&lt;T2, D2&gt;::pointer&gt;::type</tt>. Then
the specialization <tt>less&lt;CT&gt</tt> shall be a function object type ([function.objects]) 
that induces a strict weak ordering ([alg.sorting]) on the pointer values.</ins>
</p>

<p>
4 <i>Returns:</i> <tt><ins>less&lt;CT&gt;()(x.get(), y.get())</ins><del>x.get()
&lt; y.get()</del></tt>.
</p>

<p>
<ins>? <i>Remarks:</i> If <tt>unique_ptr&lt;T1, D1&gt;::pointer</tt> is not
implicitly convertible to <tt>CT</tt> or <tt>unique_ptr&lt;T2,
D2&gt;::pointer</tt> is not implicitly convertible to <tt>CT</tt>, the program
is ill-formed.</ins>
</p>
</blockquote>

<pre>
template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator&lt;=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
</pre>

<blockquote><p>
5 <i>Returns:</i> <tt><ins>!(y &lt; x)</ins><del>x.get() &lt;= y.get()</del></tt>.
</p></blockquote>

<pre>
template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator&gt;(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
</pre>

<blockquote><p>
6 <i>Returns:</i> <tt><ins>(y &lt; x)</ins><del>x.get() &gt; y.get()</del></tt>.
</p></blockquote>

<pre>
template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator&gt;=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
</pre>

<blockquote><p>
7 <i>Returns:</i> <tt><ins>!(x &lt; y)</ins><del>x.get() &gt;= y.get()</del></tt>.
</p></blockquote>
</blockquote>

<blockquote><pre>
<ins>template &lt;class T, class D&gt;</ins>
<ins>bool operator==(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t) noexcept;</ins>
<ins>template &lt;class T, class D&gt;</ins>
<ins>bool operator==(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x) noexcept;</ins>
</pre><blockquote><p>
<ins>? <i>Returns</i>: <tt>!x</tt>.</ins>
</p></blockquote></blockquote>

<blockquote><pre>
<ins>template &lt;class T, class D&gt;</ins>
<ins>bool operator!=(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t) noexcept;</ins>
<ins>template &lt;class T, class D&gt;</ins>
<ins>bool operator!=(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x) noexcept;</ins>
</pre><blockquote><p>
<ins>? <i>Returns</i>: <tt>(bool) x</tt>.</ins>
</p></blockquote></blockquote>

<blockquote><pre>
<ins>template &lt;class T, class D&gt;</ins>
<ins>bool operator&lt;(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t);</ins>
<ins>template &lt;class T, class D&gt;</ins>
<ins>bool operator&gt;(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x);</ins>
</pre>
<blockquote><p>
<ins>? <i>Requires:</i> The specialization <tt>less&lt;unique_ptr&lt;T, D&gt;::pointer&gt</tt> 
shall be a function object type ([function.objects]) that induces a strict weak ordering ([alg.sorting])
on the pointer values.</ins>
</p></blockquote>
<blockquote><p>
<ins>? <i>Returns</i>: <tt>less&lt;unique_ptr&lt;T, D&gt;::pointer&gt;()(x.get(), nullptr)</tt>.</ins>
</p></blockquote></blockquote>

<blockquote><pre>
<ins>template &lt;class T, class D&gt;</ins>
<ins>bool operator&lt;(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x);</ins>
<ins>template &lt;class T, class D&gt;</ins>
<ins>bool operator&gt;(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t);</ins>
</pre>
<blockquote><p>
<ins>? <i>Requires:</i> The specialization <tt>less&lt;unique_ptr&lt;T, D&gt;::pointer&gt</tt> 
shall be a function object type ([function.objects]) that induces a strict weak ordering ([alg.sorting])
on the pointer values.</ins>
</p></blockquote>
<blockquote><p>
<ins>? <i>Returns</i>: <tt>less&lt;unique_ptr&lt;T, D&gt;::pointer&gt;()(nullptr, x.get())</tt>.</ins>
</p></blockquote></blockquote>

<blockquote><pre>
<ins>template &lt;class T, class D&gt;</ins>
<ins>bool operator&lt;=(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t);</ins>
<ins>template &lt;class T, class D&gt;</ins>
<ins>bool operator&gt;=(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x);</ins>
</pre><blockquote><p>
<ins>? <i>Returns</i>: <tt>!(nullptr &lt; x)</tt>.</ins>
</p></blockquote></blockquote>

<blockquote><pre>
<ins>template &lt;class T, class D&gt;</ins>
<ins>bool operator&lt;=(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; x);</ins>
<ins>template &lt;class T, class D&gt;</ins>
<ins>bool operator&gt;=(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t);</ins>
</pre><blockquote><p>
<ins>? <i>Returns</i>: <tt>!(x &lt; nullptr)</tt>.</ins>
</p></blockquote></blockquote>


</li>
<li>Change 20.7.2.2 [util.smartptr.shared] p. 1, class template <tt>shared_ptr</tt>
synopsis as indicated. For consistency reasons the remaining normal relation
operators are added as well:
<blockquote><pre>
namespace std {

  [&hellip;]

  // <i>[util.smartptr.shared.cmp], shared_ptr comparisons:</i>
  template&lt;class T, class U&gt;
  bool operator==(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;U&gt;&amp; b) noexcept;
  template&lt;class T, class U&gt;
  bool operator!=(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;U&gt;&amp; b) noexcept;
  template&lt;class T, class U&gt;
  bool operator&lt;(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;U&gt;&amp; b) noexcept;
  <ins>template&lt;class T, class U&gt;</ins>
  <ins>bool operator&gt;(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;U&gt;&amp; b) noexcept;</ins>
  <ins>template&lt;class T, class U&gt;</ins>
  <ins>bool operator&lt;=(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;U&gt;&amp; b) noexcept;</ins>
  <ins>template&lt;class T, class U&gt;</ins>
  <ins>bool operator&gt;=(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;U&gt;&amp; b) noexcept;</ins>

  <ins>template&lt;class T&gt;</ins>
  <ins>bool operator==(const shared_ptr&lt;T&gt;&amp; a, nullptr_t) noexcept;</ins>
  <ins>template&lt;class T&gt;</ins>
  <ins>bool operator==(nullptr_t, const shared_ptr&lt;T&gt;&amp; a) noexcept;</ins>
  <ins>template&lt;class T&gt;</ins>
  <ins>bool operator!=(const shared_ptr&lt;T&gt;&amp; a, nullptr_t) noexcept;</ins>
  <ins>template&lt;class T&gt;</ins>
  <ins>bool operator!=(nullptr_t, const shared_ptr&lt;T&gt;&amp; a) noexcept;</ins>
  <ins>template&lt;class T&gt;</ins>
  <ins>bool operator&lt;(const shared_ptr&lt;T&gt;&amp; a, nullptr_t) noexcept;</ins>
  <ins>template&lt;class T&gt;</ins>
  <ins>bool operator&lt;(nullptr_t, const shared_ptr&lt;T&gt;&amp; a) noexcept;</ins>
  <ins>template&gt;class T&gt;</ins>
  <ins>bool operator&gt;(const shared_ptr&lt;T&gt;&amp; a, nullptr_t) noexcept;</ins>
  <ins>template&gt;class T&gt;</ins>
  <ins>bool operator&gt;(nullptr_t, const shared_ptr&lt;T&gt;&amp; a) noexcept;</ins>
  <ins>template&lt;class T&gt;</ins>
  <ins>bool operator&lt;=(const shared_ptr&lt;T&gt;&amp; a, nullptr_t) noexcept;</ins>
  <ins>template&lt;class T&gt;</ins>
  <ins>bool operator&lt;=(nullptr_t, const shared_ptr&lt;T&gt;&amp; a) noexcept;</ins>
  <ins>template&gt;class T&gt;</ins>
  <ins>bool operator&gt;=(const shared_ptr&lt;T&gt;&amp; a, nullptr_t) noexcept;</ins>
  <ins>template&gt;class T&gt;</ins>
  <ins>bool operator&gt;=(nullptr_t, const shared_ptr&lt;T&gt;&amp; a) noexcept;</ins>

  [&hellip;]
}
</pre></blockquote>
</li>
<li>Add the following series of prototype specifications at the very end of 20.7.2.2.7 [util.smartptr.shared.cmp].
For mixed comparison the general &quot;generation&quot; rule of 20.2.1 [operators] p. 10 does not apply, 
therefore all of them are defined. Below wording takes advantage of the simplified definition of the
<em>composite pointer type</em> if one partner is a null pointer constant:
<blockquote><pre>
<ins>template&lt;class T&gt;</ins>
<ins>bool operator==(const shared_ptr&lt;T&gt;&amp; a, nullptr_t) noexcept;</ins>
<ins>template&lt;class T&gt;</ins>
<ins>bool operator==(nullptr_t, const shared_ptr&lt;T&gt;&amp; a) noexcept;</ins>
</pre><blockquote><p>
<ins>? <i>Returns</i>: <tt>!a</tt>.</ins>
</p></blockquote></blockquote>

<blockquote><pre>
<ins>template&lt;class T&gt;</ins>
<ins>bool operator!=(const shared_ptr&lt;T&gt;&amp; a, nullptr_t) noexcept;</ins>
<ins>template&lt;class T&gt;</ins>
<ins>bool operator!=(nullptr_t, const shared_ptr&lt;T&gt;&amp; a) noexcept;</ins>
</pre><blockquote><p>
<ins>? <i>Returns</i>: <tt>(bool) a</tt>.</ins>
</p></blockquote></blockquote>

<blockquote><pre>
<ins>template&lt;class T&gt;</ins>
<ins>bool operator&lt;(const shared_ptr&lt;T&gt;&amp; a, nullptr_t) noexcept;</ins>
<ins>template&lt;class T&gt;</ins>
<ins>bool operator&gt;(nullptr_t, const shared_ptr&lt;T&gt;&amp; a) noexcept;</ins>
</pre><blockquote><p>
<ins>? <i>Returns</i>: <tt>less&lt;T*&gt;()(a.get(), nullptr)</tt>.</ins>
</p></blockquote></blockquote>

<blockquote><pre>
<ins>template&lt;class T&gt;</ins>
<ins>bool operator&lt;(nullptr_t, const shared_ptr&lt;T&gt;&amp; a) noexcept;</ins>
<ins>template&lt;class T&gt;</ins>
<ins>bool operator&gt;(const shared_ptr&lt;T&gt;&amp; a, nullptr_t) noexcept;</ins>
</pre><blockquote><p>
<ins>? <i>Returns</i>: <tt>less&lt;T*&gt;()(nullptr, a.get())</tt>.</ins>
</p></blockquote></blockquote>

<blockquote><pre>
<ins>template&lt;class T&gt;</ins>
<ins>bool operator&lt;=(const shared_ptr&lt;T&gt;&amp; a, nullptr_t) noexcept;</ins>
<ins>template&lt;class T&gt;</ins>
<ins>bool operator&gt;=(nullptr_t, const shared_ptr&lt;T&gt;&amp; a) noexcept;</ins>
</pre><blockquote><p>
<ins>? <i>Returns</i>: <tt>!(nullptr &lt; a)</tt>.</ins>
</p></blockquote></blockquote>

<blockquote><pre>
<ins>template&lt;class T&gt;</ins>
<ins>bool operator&lt;=(nullptr_t, const shared_ptr&lt;T&gt;&amp; a) noexcept;</ins>
<ins>template&lt;class T&gt;</ins>
<ins>bool operator&gt;=(const shared_ptr&lt;T&gt;&amp; a, nullptr_t) noexcept;</ins>
</pre><blockquote><p>
<ins>? <i>Returns</i>: <tt>!(a &lt; nullptr)</tt>.</ins>
</p></blockquote></blockquote>

</li>
</ol>





<hr>
<h3><a name="1408"></a>1408. [FCD] Allow recycling of pointers after <tt>undeclare_no_pointers</tt></h3>
<p><b>Section:</b> 20.6.4 [util.dynamic.safety] <b>Status:</b> <a href="lwg-active.html#Voting">Voting</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#util.dynamic.safety">issues</a> in [util.dynamic.safety].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Voting">Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-103</b></p>
<p>
The precondition to calling <tt>declare_no_pointers</tt> is that no
bytes in the range "have been previously registered" with
this call. As written, this precondition includes bytes in
ranges, even after they have been explicitly unregistered
with a later call to <tt>undeclare_no_pointers</tt>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Update 20.6.4 [util.dynamic.safety] p.9:
</p>
<blockquote><pre>
void declare_no_pointers(char *p, size_t n);
</pre><blockquote><p>
<tt>9</tt> <em>Requires</em>: No bytes in the specified range <del>have been
previously registered</del><ins>are currently registered</ins> with <tt>declare_no_pointers()</tt>.
If the specified range is in an allocated object, then it must be entirely within a single allocated object.
The object must be live until the corresponding <tt>undeclare_no_pointers()</tt> call. [..]
</p></blockquote></blockquote>





<hr>
<h3><a name="1413"></a>1413. [FCD] Specify whether <tt>high_resolution_clock</tt> is a distinct type or a typedef</h3>
<p><b>Section:</b> 20.11.7.3 [time.clock.hires] <b>Status:</b> <a href="lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</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><b>Addresses US-112</b></p>
<p>
What it means for <tt>high_resolution_clock</tt> to be a synonym
is undefined. If it may or may not be a typedef, then
certain classes of programs become unportable.
</p>

<p><i>[
Resolution proposed in ballot comment
]</i></p>

<p>
Require that it be a distinct class type.
</p>

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

<p>
This is not a defect.  Threre are a number of places in the standard where
we allow implentations to choose their preferred technique, the most obvious
example being the <tt>iterator</tt>/<tt>const_iterator</tt> types of <tt>set</tt>.
</p>
<p>
Typically, this means it is not portable to declare function overloads that differ
only in their use of these types.
</p>



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





<hr>
<h3><a name="1418"></a>1418. [FCD] Effects of <tt>resize(size())</tt> on a <tt>deque</tt></h3>
<p><b>Section:</b> 23.3.3.3 [deque.capacity] <b>Status:</b> <a href="lwg-active.html#Voting">Voting</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Voting">Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-113</b></p>
<p>
There is no mention of what happens if <tt>sz==size()</tt>. While
it obviously does nothing I feel a standard needs to say
this explicitely.
</p>


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

<p>
Accepted with a simplified resolution turning one of the <tt>&lt;</tt>
comparisons into <tt>&lt;=.</tt>
</p>

<p><b>Proposed resolution:</b></p>
<p>Ammend [deque.capacity]</p>
<p><tt>void resize(size_type sz);</tt></p>
<p>
<i>Effects</i>: If <tt>sz &lt;<ins>=</ins> size()</tt>, equivalent to <tt>erase(begin() +
sz, end());</tt>. If <tt>size() &lt; sz</tt>, appends <tt>sz - size()</tt> <del>default 
constructed</del><ins>value initialized</ins> elements to the sequence.
</p>





<hr>
<h3><a name="1420"></a>1420. [FCD] Effects of <tt>resize(size())</tt> on a <tt>list</tt></h3>
<p><b>Section:</b> 23.3.5.3 [list.capacity] <b>Status:</b> <a href="lwg-active.html#Voting">Voting</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#list.capacity">issues</a> in [list.capacity].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Voting">Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-115</b></p>
<p>
There is no mention of what happens if <tt>sz==size()</tt>. While
it obviously does nothing I feel a standard needs to say
this explicitely.
</p>

<p><i>[
Resolution proposed in ballot comment
]</i></p>

<p>
Express the semantics as pseudo-code similarly
to the way it is done for the copying overload that
follows (in p3). Include an else clause that does
nothing and covers the <tt>sz==size()</tt> case.
</p>

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

<p>
Accepted with a simplified resolution turning one of the <tt>&lt;</tt>
comparisons into <tt>&lt;=.</tt>
</p>




<p><b>Proposed resolution:</b></p>
<p>
Ammend [list.capacity] p1:
</p>
<blockquote>
<p><tt>void resize(size_type sz);</tt></p>
<blockquote><p>
<i>Effects</i>: If <tt>sz &lt;<ins>=</ins> size()</tt>, equivalent to <tt>list&lt;T&gt;::iterator
it = begin(); advance(it, sz); erase(it, end());</tt>. If
<tt>size() &lt; sz</tt>, appends <tt>sz - size()</tt> <del>default constructed</del>
<ins>value initialized</ins> elements to the sequence<del></del>.
</p></blockquote>
</blockquote>






<hr>
<h3><a name="1438"></a>1438. [FCD] No definition for <tt>base()</tt></h3>
<p><b>Section:</b> 26.5.4.2 [rand.adapt.disc] <b>Status:</b> <a href="lwg-active.html#Voting">Voting</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#rand.adapt.disc">issues</a> in [rand.adapt.disc].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Voting">Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-126</b></p>

<p>Each adaptor has a member function called <tt>base()</tt> which has no definition.</p>

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote><p>
Give it the obvious definition.
</p></blockquote>

<p><i>[
2010-11-03 Daniel comments and provides a proposed resolution:
]</i></p>


<p>The following proposal adds <tt>noexcept</tt> specifiers to the declarations of
the <tt>base()</tt> functions as replacement for a &quot;<i>Throws</i>: Nothing&quot; element.
</p>

<p><i>[
2010 Batavia: The working group reviewed this issue, and recommended to add the following to the Proposed Resolution.
]</i></p>

<ul><li>
Append to paragraph 1 of [rand.req.adapt] (or at the Editor's discretion insert as a new paragraph following that paragraph): 
The expression <tt>a.base()</tt> shall be valid and shall return a const reference to <tt>a</tt>'s base engine. 
</li>
</ul>
<p>
After further review, the working group concurred with the Proposed Resolution.
</p>


<p><i>[Batavia: waiting for WEB to review wording]</i></p>




<p><b>Proposed resolution:</b></p>
<ol>
<li>
Add the following sentence to the end of 26.5.1.5 [rand.req.adapt]/1:
<blockquote><p>
A <i>random number engine adaptor</i> (commonly shortened to <i>adaptor</i>) <tt>a</tt> of type <tt>A</tt> is a
random number engine that takes values produced by some other random number engine, and applies an algorithm to
those values in order to deliver a sequence of values with different randomness properties. An engine <tt>b</tt>
of type <tt>B</tt> adapted in this way is termed a <i>base engine</i> in this context.<ins> The expression
<tt>a.base()</tt> shall be valid and shall return a const reference to <tt>a</tt>'s base engine.</ins>
</p></blockquote>
</li>
<li>Change in [rand.adapt.disc]/3, class template <tt>discard_block_engine</tt> synopsis, the following declaration:
<blockquote><pre>
// <em>property functions</em>
const Engine&amp; base() const <ins>noexcept</ins>;
</pre></blockquote>
</li>
<li>Add the following new prototype description at the end of sub-clause 26.5.4.2 [rand.adapt.disc]:
<blockquote>
<pre><ins>const Engine&amp; base() const noexcept;</ins>
</pre>
<blockquote><p>
<ins>? <i>Returns</i>: <tt>e</tt>.</ins>
</p></blockquote>
</blockquote>
</li>
<li>Change in [rand.adapt.ibits]/4, class template <tt>independent_bits_engine</tt> synopsis, the following declaration:
<blockquote><pre>
// <em>property functions</em>
const Engine&amp; base() const <ins>noexcept</ins>;
</pre></blockquote>
</li>
<li>Add the following new prototype description at the end of sub-clause 26.5.4.3 [rand.adapt.ibits]:
<blockquote>
<pre><ins>const Engine&amp; base() const noexcept;</ins>
</pre>
<blockquote><p>
<ins>? <i>Returns</i>: <tt>e</tt>.</ins>
</p></blockquote>
</blockquote>
</li>
<li>Change in 26.5.4.4 [rand.adapt.shuf]/3, class template <tt>shuffle_order_engine</tt> synopsis, the following declaration:
<blockquote><pre>
// <em>property functions</em>
const Engine&amp; base() const <ins>noexcept</ins>;
</pre></blockquote>
</li>
<li>Add the following new prototype description at the end of sub-clause 26.5.4.4 [rand.adapt.shuf]:
<blockquote>
<pre><ins>const Engine&amp; base() const noexcept;</ins>
</pre>
<blockquote><p>
<ins>? <i>Returns</i>: <tt>e</tt>.</ins>
</p></blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="1448"></a>1448. [FCD] Concerns about <tt>basic_stringbuf::str(basic_string)</tt> postconditions</h3>
<p><b>Section:</b> 27.8.2.3 [stringbuf.members] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-124</b></p>

<p>
N3092 27.8.2.3 [stringbuf.members] contains this text specifying the postconditions of
<tt>basic_stringbuf::str(basic_string)</tt>:
</p>
<blockquote><p>
Postconditions: If <tt>mode &amp; ios_base::out</tt> is <tt>true</tt>,
<tt>pbase()</tt> points to the first underlying character and <tt>epptr() >=
pbase() + s.size()</tt> holds; in addition, if <tt>mode &amp; ios_base::in</tt>
is <tt>true</tt>, <tt>pptr() == pbase() + s.data()</tt> holds, otherwise
<tt>pptr() == pbase()</tt> is <tt>true</tt>. [...]
</p></blockquote>
<p>
Firstly, there's a simple mistake: It should be <tt>pbase() + s.length()</tt>,
not <tt>pbase() + s.data()</tt>.
</p>
<p>
Secondly, it doesn't match existing implementations. As far as I can tell,
GCC 4.5 does not test for <tt>mode &amp; ios_base::in</tt> in the second part
of that sentence, but for <tt>mode &amp; (ios_base::app | ios_base_ate)</tt>,
and Visual C++ 9 for <tt>mode &amp; ios_base::app</tt>. Besides, the wording of
the C++0x draft doesn't make any sense to me. I suggest changing the second part
of the sentence to one of the following:
</p>
<p>
Replace <tt>ios_base::in</tt> with <tt>(ios_base::ate | ios_base::app)</tt>,
but this would require Visual C++ to change (replacing only with
<tt>ios_base::ate</tt> would require GCC to change, and would make
<tt>ios_base::app</tt> completely useless with <tt>stringstreams</tt>):
</p>
<p>
in addition, if <tt>mode &amp; (ios_base::ate | ios_base::app)</tt> is <tt>true</tt>,
<tt>pptr() == pbase() + s.length()</tt> holds, otherwise <tt>pptr() == pbase()</tt>
is <tt>true</tt>.
</p>
<p>
Leave <tt>pptr()</tt> unspecified if <tt>mode &amp; ios_base::app</tt>, but not
<tt>mode &amp; ios_base::ate</tt> (implementations already differ in this case, and it
is always possible to use <tt>ios_base::ate</tt> to get the effect of appending, so it
is not necessary to require any implementation to change):
</p>
<p>
in addition, if <tt>mode &amp; ios_base::ate</tt> is <tt>true</tt>,
<tt>pptr() == pbase() + s.length()</tt> holds, if neither <tt>mode &amp; ios_base::ate</tt>
nor <tt>mode &amp; ios_base::app</tt> is <tt>true</tt>, <tt>pptr() == pbase()</tt> holds,
otherwise <tt>pptr() >= pbase() &amp;&amp; pptr() &lt;= pbase() + s.length()</tt>
(which of the values in this range is unspecified).
</p>
<p>
Slightly stricter:
</p>
<p>
in addition, if <tt>mode &amp; ios_base::ate</tt> is <tt>true</tt>,
<tt>pptr() == pbase() + s.length()</tt> holds, if neither
<tt>mode &amp; ios_base::ate</tt> nor <tt>mode &amp; ios_base::app</tt> is <tt>true</tt>,
<tt>pptr() == pbase()</tt> holds, otherwise <tt>pptr() == pbase() || pptr() == pbase() + s.length()</tt>
(which of these two values is unspecified). A small table might help to better explain the three cases.
BTW, at the end of the postconditions is this text: &quot;<tt>egptr() == eback() + s.size()</tt> hold&quot;.
Is there a perference for <tt>basic_string::length</tt> or <tt>basic_string::size</tt>? It doesn't really
matter, but it looks a bit inconsistent.
</p>

<p><i>[2011-03-09: Nicolai Josuttis comments and drafts wording]</i></p>


<p>First, it seems the current wording is just an editorial mistake.
When we added issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>
to the draft standard (in <a href="http://www.open-std.org/jtc1/sc22/wg21/prot/14882fdis/n1733.pdf">n1733</a>), 
the wording in the issue:
</p>

<blockquote><p>
If <tt>mode &amp; ios_base::out</tt> is true, initializes the output sequence
such that <tt>pbase()</tt> points to the first underlying character, <tt>epptr()</tt> 
points one past the last underlying character, and if <tt>(mode &amp; ios_base::ate)</tt> is true,
<tt>pptr()</tt> is set equal to <tt>epptr()</tt> else <tt>pptr()</tt> is set equal to 
<tt>pbase()</tt>.
</p></blockquote>

<p>became:</p>

<blockquote><p>
If <tt>mode &amp; ios_base::out</tt> is true, initializes the output sequence
such that <tt>pbase()</tt> points to the first underlying character, <tt>epptr()</tt> 
points one past the last underlying character, and <tt>pptr()</tt> is equal to <tt>epptr()</tt>
if <tt>mode &amp; ios_base::in</tt> is true, otherwise <tt>pptr()</tt> is equal to 
<tt>pbase()</tt>.
</p></blockquote>

<p>
which beside some changes of the order of words changed
</p>
<blockquote><pre>
ios_base::ate
</pre></blockquote>
<p>
into
</p>
<blockquote><pre>
ios_base::in
</pre></blockquote>
<p>
So, from this point of view, clearly <tt>mode &amp; ios_base::ate</tt> was meant.
</p>

<p>
Nevertheless, with this proposed resolution we'd have no wording regarding <tt>ios_base::app</tt>.
Currently the only statements about <tt>app</tt> in the Standard are just in two tables:
</p>
<ul>
<li>Table 125 &mdash; &quot;<tt>openmode</tt> effects&quot; says that the effect of 
<tt>app</tt> is "seek to end before each write"
</li>

<li>Table 132 &mdash; &quot;File open modes&quot; says that the stdio equivalent 
for <tt>app</tt> is <tt>"a"</tt>
</li>
</ul>
<p>
Indeed we seem to have different behavior currently in respect to <tt>app</tt>: For
</p>

<blockquote><pre>
stringstream s2(ios_base::out|ios_base::in|ios_base::app);
s2.str("s2 hello");
s1 &lt;&lt; "more";
</pre></blockquote>

<ul>
<li>Visual C++ 10 does overwrite (=> <tt>"moreello"</tt>)</li>
<li>G++ 4.5 does append (=> <tt>"s2 hellomore"</tt>)</li>
</ul>

<p>BTW, for fstreams, both implementations append when <tt>app</tt> is set:
If <tt>f2.txt</tt> has contents <tt>"xy"</tt>,</p>

<blockquote><pre>
fstream f2("f2.txt",ios_base::out|ios_base::in|ios_base::app);
f1 &lt;&lt; "more";
</pre></blockquote>

<p>appends <tt>"more"</tt> so that the contents is <tt>"xymore"</tt>.</p>

<p>So IMO <tt>app</tt> should set the write pointer to the end so that each writing 
appends.
<p/>
I don't know whether what the standard says is enough. You can argue the 
statement in Table 125 clearly states that such a buffer should always append, 
which of course also applies to <tt>str()</tt> of stringbuffer.
<p/>
Nevertheless, it doesn't hurt IMO if we clarify the behavior of <tt>str()</tt>
here in respect to <tt>app</tt>.
</p>

<p><i>[2011-03-10: P.J.Plauger comments:]</i></p>


<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>

<p><i>[Madrid meeting: It was observed that a different issue should be opened that
clarifies the meaning of <tt>app</tt> for <tt>stringstream</tt>]</i></p>



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

<p>Change 27.8.2.3 [stringbuf.members] p. 3 as indicated:</p>

<blockquote><pre>
void str(const basic_string&lt;charT,traits,Allocator&gt;&amp; s);
</pre><blockquote>
<p>
2 <i>Effects</i>: Copies the content of <tt>s</tt> into the <tt>basic_stringbuf</tt> 
underlying character sequence and initializes the input and output sequences according 
to <tt>mode</tt>.
<p/>
3 <i>Postconditions</i>: If <tt>mode &amp; ios_base::out</tt> is true, <tt>pbase()</tt> 
points to the first underlying character and <tt>epptr() &gt;= pbase() + s.size()</tt> 
holds; in addition, if <tt>mode &amp; <del>ios_base::in</del><ins>ios_base::ate</ins></tt> 
is true, <tt>pptr() == pbase() + <del>s.data()</del><ins>s.size()</ins></tt> holds, 
otherwise <tt>pptr() == pbase()</tt> is true. If <tt>mode &amp; ios_base::in</tt> 
is true, <tt>eback()</tt> points to the first underlying character, and both 
<tt>gptr() == eback() and egptr() == eback() + s.size()</tt> 
hold.
</p>
</blockquote></blockquote>





<hr>
<h3><a name="1450"></a>1450. [FCD] Contradiction in regex_constants</h3>
<p><b>Section:</b> 28.5.2 [re.matchflag] <b>Status:</b> <a href="lwg-active.html#Deferred">Deferred</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Deferred">Deferred</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-127</b></p>

<p>
The Bitmask Type requirements in 17.5.2.1.3 [bitmask.types] p.3 say that
all elements on a bitmask type have distinct values, but
28.5.2 [re.matchflag] defines <tt>regex_constants::match_default</tt> and
<tt>regex_constants::format_default</tt> as elements of the
bitmask type <tt>regex_constants::match_flag_type</tt>, both with
value 0. This is a contradiction.
</p>

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote><p>
One of the bitmask elements should be removed
from the declaration and should be defined
separately, in the same manner as
<tt>ios_base::adjustfield</tt>, <tt>ios_base::basefield</tt> and
<tt>ios_base::floatfield</tt> are defined by 27.5.3.1.2 [ios::fmtflags] p.2
and Table 120. These are constants of a bitmask
type, but are not distinct elements, they have
more than one value set in the bitmask.
<tt>regex_constants::format_default</tt> should be
specified as a constant with the same value as
<tt>regex_constants::match_default</tt>.
</p></blockquote>

<p><i>[
2010-10-31 Daniel comments:
]</i></p>

<p>
Strictly speaking, a bitmask type cannot have any element of value 0 at all, because
any such value would contradict the requirement expressed in 17.5.2.1.3 [bitmask.types] p. 3:
</p>
<blockquote><p>
for any pair <em>Ci</em> and <em>Cj</em>, <em>Ci</em> &amp; <em>Ci</em> is nonzero
</p></blockquote>
<p>
So, actually <em>both</em> <tt>regex_constants::match_default</tt> and
<tt>regex_constants::format_default</tt> are only constants of the type
<tt>regex_constants::match_flag_type</tt>, and no bitmask elements.
</p>

<p><i>[
2010-11-03 Daniel comments and provides a proposed resolution:
]</i></p>


<p>The proposed resolution is written against N3126 and considered as a further improvement
of the fixes suggested by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3110.html">n3110</a>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add the following sentence to 28.5.2 [re.matchflag]  paragraph 1:
</p>
<blockquote><p>
1 The type <tt>regex_constants::match_flag_type</tt> is an implementation-defined bitmask type (17.5.2.1.3).
Matching a regular expression against a sequence of characters [first,last) proceeds according to the
rules of the grammar specified for the regular expression object, modified according to the effects listed in
Table 136 for any bitmask elements set. <ins>Type <tt>regex_constants::match_flag_type</tt> also defines the 
constants <tt>regex_constants::match_default</tt> and <tt>regex_constants::format_default</tt>.</ins>
</p></blockquote>





<hr>
<h3><a name="1474"></a>1474. [FCD] weak compare-and-exchange confusion</h3>
<p><b>Section:</b> 29.6.5 [atomics.types.operations.req] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Duplicate of:</b> <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></p>
<p><b>Discussion:</b></p>



<p><b>Addresses US-175, US-165, CH-23, GB-135</b></p>
<p>
29.6.5 [atomics.types.operations.req] p. 25: The first sentence is grammatically incorrect.
</p>
<p><i>[
2010-10-28 Daniel adds:
]</i></p>

<p>
Duplicate issue <a href="lwg-closed.html#1475">1475</a> also has a proposed resolution, but both issues are resolved with
below proposed resolution.
</p>

<p><i>[
2011-02-15 Howard fixes numbering, Hans improves the wording
]</i></p>


<p><i>[2011-02-24 Reflector discussion]</i></p>

<p>
Moved to Tentatively Ready after 6 votes.
</p> 


<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>Change 29.6.5 [atomics.types.operations.req] p. 23 as indicated:</p>

<blockquote><p>
[ <em>Note</em>: <ins>For example, t</ins><del>T</del>he effect of 
<del>the compare-and-exchange operations</del><ins><tt>atomic_compare_exchange_strong</tt></ins> is
</p><blockquote><pre>
if (memcmp(object, expected, sizeof(*object)) == 0)
  memcpy(object, &amp;desired, sizeof(*object));
else
  memcpy(expected, object, sizeof(*object));
</pre></blockquote>
<p> &mdash; <em>end note</em> ] [..]</p>
</blockquote>
</li>

<li>
<p>Change 29.6.5 [atomics.types.operations.req] p. 25 as indicated:</p>
<blockquote><p>
25 <em>Remark</em>: <del>The weak compare-and-exchange operations may fail spuriously, that is, return false while
leaving the contents of memory pointed to by <tt>expected</tt> before the operation is the same that same
as that of the <tt>object</tt> and the same as that of <tt>expected</tt> after the operation</del><ins>A weak 
compare-and-exchange operation may fail spuriously. That is, even when the contents of memory referred to by 
<tt>expected</tt> and <tt>object</tt> are equal, it may return false and store back to <tt>expected</tt> the same 
memory contents that were originally there.</ins>. [ <em>Note</em>: This spurious
failure enables implementation of compare-and-exchange on a broader class of machines, e.g., loadlocked
store-conditional machines. A consequence of spurious failure is that nearly all uses of weak
compare-and-exchange will be in a loop.
<p/>
When a compare-and-exchange is in a loop, the weak version will yield better performance on some
platforms. When a weak compare-and-exchange would require a loop and a strong one would not, the
strong one is preferable. &mdash; <em>end note</em> ]
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="1478"></a>1478. [FCD] Clarify race conditions in atomics initialization</h3>
<p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-136</b></p>
<p>
GB requests normative clarification in 29.6 [atomics.types.operations] p.4 that
concurrent access constitutes a race, as already done on p.6 and p.7.
</p>
<p><i>[
Resolution proposed in ballot comment:
]</i></p>


<blockquote><p>
Initialisation of atomics:
<p/>
We believe the intent is that for any atomics there is a distinguished
initialisation write, but that this need not happens-before all the
other operations on that atomic - specifically so that the
initialisation write might be non-atomic and hence give rise to a data
race, and hence undefined behaviour, in examples such as this (from
Hans):
</p>
<blockquote><pre>
atomic&lt;atomic&lt;int&gt; *&gt; p
f()                      |
{ atomic&lt;int&gt;x;          | W_na x
  p.store(&amp;x,mo_rlx);    | W_rlx p=&amp;x
}                        |
</pre></blockquote><p>
(where na is nonatomic and rlx is relaxed). We suspect also that no
other mixed atomic/nonatomic access to the same location is intended
to be permitted. Either way, a note would probably help.
</p></blockquote>

<p><i>[2011-02-26: Hans comments and drafts wording]</i></p>


<p>I think the important point here is to clarify that races on atomics
are possible, and can be introduced as a result of non-atomic
initialization operations.  There are other parts of this that remain unclear
to me, such as whether there are other ways to introduce data races on atomics,
or whether the races with initialization also introduce undefined behavior
by the 3.8 lifetime rules.  But I don't think that it is necessary to resolve
those issues before releasing the standard.  That's particularly true
since we've introduced <tt>atomic_init</tt>, which allows easier ways to
construct initialization races.
</p>

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

<p>Accepted to be applied immediately to the WP</p>



<p><b>Proposed resolution:</b></p>
<ol>
<li><p>Update 29.6.5 [atomics.types.operations.req] p. 5 as follows:</p>

<blockquote><pre>
constexpr A::A(C desired);
</pre><blockquote><p>
5 <i>Effects</i>: Initializes the object with the value <tt>desired</tt>. <del>[ <i>Note</i>: 
Construction is not atomic. &mdash; <i>end note</i> ]</del><ins> Initialization is not an 
atomic operation (1.10) [intro.multithread]. [<i>Note</i>: It is possible to have an
access to an atomic object <tt>A</tt> race with its construction, for example
by communicating the address of the just-constructed object <tt>A</tt> to another thread 
via <code>memory_order_relaxed</code> atomic operations on a suitable atomic pointer variable, 
and then immediately accessing <tt>A</tt> in the receiving thread.  This results in undefined 
behavior. &mdash; <i>end note</i>]</ins>
</p></blockquote></blockquote>
</li>

<li><p>In response to the editor comment to 29.6.5 [atomics.types.operations.req] p. 8: 
The first <i>Effects</i> element is the correct and intended one:</p>

<blockquote><pre>
void atomic_init(volatile A *object, C desired);
void atomic_init(A *object, C desired);
</pre><blockquote><p>
8 <i>Effects</i>: Non-atomically initializes <tt>*object</tt> with value <tt>desired</tt>.
This function shall only be applied to objects that have been default constructed, and then only once.
[ <i>Note</i>: these semantics ensure compatibility with C. &mdash; <i>end note</i> ] [ <i>Note</i>: 
Concurrent access from another thread, even via an atomic operation, constitutes a data 
race. &mdash; <i>end note</i> ] <del>[<i>Editor's note</i>: The preceding text is from the WD as 
amended by N3196. N3193 makes different changes, marked up in the paper as follows:]
<i>Effects</i>: Dynamically initializes an atomic variable. Non-atomically That is, non-atomically assigns the
value desired to <tt>*object</tt>. [ <i>Note</i>: this operation may need to initialize 
locks. &mdash; <i>end note</i> ] Concurrent access from another thread, even via an atomic 
operation, constitutes a data race.</del>
</p></blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="1479"></a>1479. [FCD] Fence functions should be <tt>extern "C"</tt></h3>
<p><b>Section:</b> 29.8 [atomics.fences] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#atomics.fences">active issues</a> in [atomics.fences].</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.fences">issues</a> in [atomics.fences].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-179</b></p>
<p>
The fence functions (29.8 [atomics.fences] p.5 + p.6) should be <tt>extern "C"</tt>, for <tt>C</tt> compatibility.
</p>

<p><i>[2011-02-16 Reflector discussion]</i></p>

<p>
Moved to Tentatively Ready after 6 votes.
</p>



<p><b>Proposed resolution:</b></p>
<ol>
<li>Change 29.2 [atomics.syn], header <tt>&lt;atomic&gt;</tt> synopsis as indicated:
<blockquote><pre>
namespace std {
  [..]
  // <em>29.8, fences</em>
  <ins>extern "C"</ins> void atomic_thread_fence(memory_order);
  <ins>extern "C"</ins> void atomic_signal_fence(memory_order);  
}
</pre></blockquote>
</li>
<li><p>Change 29.8 [atomics.fences], p. 5 and p. 6 as indicated:</p>
<blockquote><pre>
<ins>extern "C"</ins> void atomic_thread_fence(memory_order);
</pre><blockquote><p>
5 <em>Effects</em>: depending on the value of <tt>order</tt>, this operation: [..]
</p></blockquote></blockquote>
<blockquote><pre>
<ins>extern "C"</ins> void atomic_signal_fence(memory_order);  
</pre><blockquote><p>
6 <em>Effects</em>: equivalent to <tt>atomic_thread_fence(order)</tt>, except that synchronizes with relationships are
established only between a thread and a signal handler executed in the same thread.
</p></blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="1480"></a>1480. [FCD] Atomic fences don't have <em>synchronizes with</em> relation</h3>
<p><b>Section:</b> 29.8 [atomics.fences] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#atomics.fences">active issues</a> in [atomics.fences].</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.fences">issues</a> in [atomics.fences].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-137</b></p>
<p>
Thread fence not only establish synchronizes with relationships,
there are semantics of fences that are expressed not in
terms of <em>synchronizes with</em> relationships (for example see 29.3 [atomics.order] p.5).
These semantics also need to apply to the use of
<tt>atomic_signal_fence</tt> in a restricted way.
</p>
<p><i>[Batavia: Concurrency group discussed issue, and is OK with the proposed resolution.]</i></p>


<p><i>[2011-02-26 Reflector discussion]</i></p>

<p>
Moved to Tentatively Ready after 5 votes.
</p> 


<p><b>Proposed resolution:</b></p>
<p>Change 29.8 [atomics.fences] p. 6 as indicated:</p>
<blockquote><pre>
void atomic_signal_fence(memory_order);  
</pre><blockquote><p>
6 <em>Effects</em>: equivalent to <tt>atomic_thread_fence(order)</tt>, except that <del>synchronizes 
with relationships</del><ins>the resulting ordering constraints</ins> are established only between a 
thread and a signal handler executed in the same thread.
</p></blockquote></blockquote>





<hr>
<h3><a name="1487"></a>1487. [FCD] Clock related operations exception specifications conflict</h3>
<p><b>Section:</b> 30.3.2 [thread.thread.this] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.thread.this">issues</a> in [thread.thread.this].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses CH-25</b></p>
<p>
Clock related operations are currently not required not to
throw. So "Throws: Nothing." is not always true.
</p>
<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote><p>
Either require clock related operations not to throw
(in 20.10) or change the Throws clauses in 30.3.2.
Also possibly add a note that <tt>abs_time</tt> in the past
or negative <tt>rel_time</tt> is allowed.
</p></blockquote>

<p><i>[2011-02-10: Howard Hinnant provides a resolution proposal]</i></p>


<p><i>[Previous proposed resolution:]</i></p>

<ol>
<li>
<p>Change the Operational semantics of <tt>C1::now()</tt> in 20.11.3 [time.clock.req], 
Table 59 &mdash; <tt>Clock</tt> requirements as follows:
</p>

<blockquote>
<table border="1">
<caption>Table 59 &mdash; <tt>Clock</tt> requirements</caption>
<tr>
<th>
Expression
</th>

<th>
Return type
</th>

<th>
Operational semantics
</th>

</tr>

<tr>
<td><tt>C1::now()</tt></td>

<td><tt>C1::time_point</tt></td>

<td>Returns a <tt>time_point</tt> object<br/>
representing the current point in time.<br/>
<ins>Shall not throw an exception.</ins></td>
</tr>

</table>
</blockquote>


</li>
</ol>

<p><i>[2011-02-19: Daniel comments and suggests an alternative wording]</i></p>


<p>Imposing the no-throw requirement on <tt>C1::now()</tt> of any clock time
is an overly radical step: It has the indirect consequences that representation
types for <tt>C1::rep</tt> can never by types with dynamic memory managment,
e.g. my <tt>big_int</tt>, which are currently fully supported by the time
utilities. Further-on this strong constraint does not even solve the problem
described in the issue, because we are still left with the fact that any
of the arithmetic operations of <tt>C1::rep</tt>, <tt>C1::duration</tt>,
and <tt>C1::time_point</tt> may throw exceptions.
</p>
<p>The alternative proposal uses the following strategy: The general <tt>Clock</tt>
requirements remain untouched, but we require that any functions of the library-provided
clocks from sub-clause 20.11.7 [time.clock] and their associated types shall not
throw exceptions. Second, we replace existing <tt>noexcept</tt> specifications of
functions from Clause 30 that depend on durations, clocks, or time points by wording that
clarifies that these functions can only throw, if the operations of user-provided durations,
clocks, or time points used as arguments to these functions throw exceptions.
</p>

<p><i>[2011-03-23 Daniel and Peter check and simplify the proposed resolution resulting in this paper]</i></p>


<p>There is an inherent problem with <tt>std::time_point</tt> that it doesn't seem to have an equivalent value 
for <tt>((time_t)-1)</tt> that gets returned by C's <tt>time()</tt> function to signal a problem, e.g., because 
the underlying hardware is unavailable. After a lot of thinking and checks we came to the resolution that 
<tt>timepoint::max()</tt> should be the value to serve as a value signaling errors in cases where we
prefer to stick with no-throw conditions. Of-course, user-provided representation types don't need to
follow this approach if they prefer exceptions to signal such failures.
<p/>
the functions <tt>now()</tt> and <tt>from_time_t()</tt> can remain <tt>noexcept</tt> with the solution to 
return <tt>timepoint::max()</tt> in case the current time cannot be determined or <tt>(time_t)-1</tt> is passed 
in, respectively.
<p/>
Based on the previous proposed solution to LWG 1487 we decided that the new <tt>TrivialClock</tt> requirements 
should define that <tt>now()</tt> mustn't throw and return <tt>timepoint::max()</tt> to signal a problem. That 
is in line with the C standard where <tt>(time_t)-1</tt> signals a problem. Together with a fix to a - we assumed - 
buggy specifcation in 20.11.3 p2 which uses "happens-before" relationship with something that isn't any action:
</p>
<blockquote><p>
2 In Table 59 <tt>C1</tt> and <tt>C2</tt> denote clock types. <tt>t1</tt> and <tt>t2</tt> are values returned by 
<tt>C1::now()</tt> where the call returning <tt>t1</tt> happens before (1.10) the call returning <tt>t2</tt> and 
both of these calls happen before <tt>C1::time_point::max()</tt>. 
</p></blockquote>

<p><i>[2011-03-23 Review with Concurrency group suggested further simplifications and Howard pointed out, that
we do not need time_point::max() as a special value.]</i></p>


<p>also the second "happens before" will be changed to "occurs before" in the english meaning. this is
to allow a steady clock to wrap.
<p/>
Peter updates issue accordingly to discussion.
</p>

<p><i>[Note to the editor: we recommend removal of the following redundant paragraphs in 
 30.5.2 [thread.condition.condvarany] p. 18 to p. 21, p. 27, p. 28, p. 30, and p. 31 that are 
defining details for the wait functions that are given by the <i>Effects</i> element. 
]</i></p>


<p><i>[Note to the editor: we recommend removal of the following redundant paragraphs in 
30.5.1 [thread.condition.condvar]: p24-p26, p33-p34, and p36-p37 that are defining details for the 
<tt>wait_for</tt> functions. We believe these paragraphs are redundant with respect to the <i>Effects</i> clauses that 
define semantics based on <tt>wait_until</tt>. An example of such a specification is the <tt>wait()</tt> with a predicate.
]</i></p>



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

<ol>
<li><p>Change p2 in 20.11.3 [time.clock.req] as follows</p>
<blockquote><p>
2 In Table 59 <tt>C1</tt> and <tt>C2</tt> denote clock types. <tt>t1</tt> and 
<tt>t2</tt> are values returned by <tt>C1::now()</tt> where the call returning <tt>t1</tt> 
happens before (1.10) the call returning <tt>t2</tt> and both of these calls <del>happen</del>
<ins>occur</ins> before <tt>C1::time_point::max()</tt>. 
<ins>[ <i>Note</i>: This means <tt>C1</tt> didn't wrap around between <tt>t1</tt> and <tt>t2</tt> &mdash; <i>end note</i> ]</ins>
</p></blockquote>
</li>

<li><p>Add the following new requirement set at the end of sub-clause 20.11.3 [time.clock.req]: [<i>Comment</i>:
This requirement set is <strong>intentionally</strong> incomplete. The reason for
this incompleteness is the based on the fact, that if we would make it right for C++0x, we would end up defining
something like a complete <tt>ArithmeticLike</tt> concept for <tt>TC::rep</tt>, <tt>TC::duration</tt>, and <tt>TC::time_point</tt>. 
But this looks out-of scope for C++0x to me. The effect is that we essentially do not exactly say, which arithmetic 
or comparison operations can be used in the time-dependent functions from Clause 30, even though I expect that
all declared functions of <tt>duration</tt> and <tt>time_point</tt> are well-formed and well-defined. &mdash; <i>end comment</i>]</p>
<blockquote><p>
3 [ <i>Note</i>: the relative difference in durations between those reported by a given clock and the SI definition is
a measure of the quality of implementation. &mdash; <i>end note</i> ]
</p></blockquote>

<blockquote><p>
<ins>? A type <tt>TC</tt> meets the <tt><i>TrivialClock</i></tt> requirements if:</ins>
</p>
<ul>
<li><p>
<ins><tt>TC</tt> satisfies the <tt>Clock</tt> requirements (20.11.3 [time.clock.req]),</ins>
</p></li>
<li><p>
<ins>the types <tt>TC::rep</tt>, <tt>TC::duration</tt>, and <tt>TC::time_point</tt> satisfy 
the requirements of <tt>EqualityComparable</tt> ( [equalitycomparable]), <tt>LessThanComparable</tt> 
( [lessthancomparable]), <tt>DefaultConstructible</tt> ( [defaultconstructible]), 
<tt>CopyConstructible</tt> ( [copyconstructible]), <tt>CopyAssignable</tt> ( [copyassignable]), 
<tt>Destructible</tt> ( [destructible]), and of numeric types ([numeric.requirements]) [<i>Note</i>: This means in 
particular, that operations of these types will not throw exceptions &mdash; <i>end note</i> ],</ins>
</p></li>
<li><p>
<ins>lvalues of the types <tt>TC::rep</tt>, <tt>TC::duration</tt>, and <tt>TC::time_point</tt> are swappable 
(17.6.3.2 [swappable.requirements]),</ins>
</p></li>
<li><p>
<ins>the function <tt>TC::now()</tt> does not throw exceptions, and</ins>
</p></li>
<li><p>
<ins>the type <tt>TC::time_point::clock</tt> meets the <tt>TrivialClock</tt> requirements, recursively.</ins>
</p></li>
</ul>
</blockquote>
</li>

<li>
<p>Modify 20.11.7 [time.clock] p. 1 as follows:</p>

<blockquote><p>
1 - The types defined in this subclause shall satisfy the <tt><ins>Trivial</ins>Clock</tt> requirements (20.11.1). 
</p></blockquote>
</li>

<li>
<p>Modify 20.11.7.1 [time.clock.system] p. 1, class <tt>system_clock</tt> synopsis, as follows:</p>

<blockquote><pre>
class system_clock {
public:
  typedef <i>see below</i> rep;
  typedef ratio&lt;<i>unspecified</i> , <i>unspecified</i> &gt; period;
  typedef chrono::duration&lt;rep, period&gt; duration;
  typedef chrono::time_point&lt;system_clock&gt; time_point;
  static const bool is_monotonic is_steady = <i>unspecified</i>;
  static time_point now() <ins>noexcept</ins>;
  // Map to C API
  static time_t to_time_t (const time_point&amp; t) <ins>noexcept</ins>;
  static time_point from_time_t(time_t t) <ins>noexcept</ins>;
};
</pre></blockquote>

</li>

<li>
<p>Modify the prototype declarations in 20.11.7.1 [time.clock.system] p. 3 + p. 4 as indicated (This 
edit also fixes the miss of the <tt>static</tt> specifier in these prototype declarations):</p>

<blockquote><pre>
<ins>static</ins> time_t to_time_t(const time_point&amp; t) <ins>noexcept</ins>;
</pre>

<pre>
<ins>static</ins> time_point from_time_t(time_t t) <ins>noexcept</ins>;
</pre>
</blockquote>

</li>

<li>
<p>Modify 20.11.7.2 [time.clock.steady] p. 1, class <tt>steady_clock</tt> synopsis, as follows:</p>

<blockquote><pre>
class steady_clock {
public:
  typedef <i>unspecified</i> rep;
  typedef ratio&lt;<i>unspecified</i> , <i>unspecified</i> &gt; period;
  typedef chrono::duration&lt;rep, period&gt; duration;
  typedef chrono::time_point&lt;<i>unspecified</i>, duration&gt; time_point;
  static const bool is_monotonic is_steady = true;

  static time_point now() <ins>noexcept</ins>;
};
</pre></blockquote>

</li>

<li>
<p> Modify 20.11.7.3 [time.clock.hires] p. 1, class <tt>high_resolution_clock</tt> synopsis, as follows:</p>

<blockquote><pre>
class high_resolution_clock {
public:
  typedef <i>unspecified</i> rep;
  typedef ratio&lt;<i>unspecified</i> , <i>unspecified</i> &gt; period;
  typedef chrono::duration&lt;rep, period&gt; duration;
  typedef chrono::time_point&lt;<i>unspecified</i>, duration&gt; time_point;
  static const bool is_monotonic is_steady = <i>unspecified</i>;

  static time_point now() <ins>noexcept</ins>;
};
</pre></blockquote>

</li>

<li><p>Add a new paragraph at the end of 30.2.4 [thread.req.timing]:</p>

<blockquote><p>
6 The resolution of timing provided by an implementation depends on both operating system and hardware.
The finest resolution provided by an implementation is called the <i>native resolution</i>.
</p></blockquote>

<blockquote><p>
<ins>? Implementation-provided clocks that are used for these functions shall meet the <tt>TrivialClock</tt>
requirements (20.11.3 [time.clock.req]).</ins>
</p></blockquote>
</li>

<li>
<p>Edit the synopsis of 30.3.2 [thread.thread.this] before p. 1. 
<comment>Note, this duplicates edits also in D/N3267:</comment>
</p>

<blockquote><pre>
template &lt;class Clock, class Duration&gt;
void sleep_until(const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time) <del>noexcept</del>;
template &lt;class Rep, class Period&gt;
void sleep_for(const chrono::duration&lt;Rep, Period&gt;&amp; rel_time) <del>noexcept</del>;
</pre></blockquote>
</li>

<li>
<p>Modify the prototype specifications in 30.3.2 [thread.thread.this] before p. 4 and p. 6 and
re-add a <i>Throws</i> element following the <i>Synchronization</i> elements at p. 5 and p. 7:</p>

<blockquote><pre>
template &lt;class Clock, class Duration&gt;
void sleep_until(const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time) <del>noexcept</del>;
</pre><blockquote><p>
4 - [...]
<p/>
5 - <i>Synchronization</i>: None.
<p/>
<ins>? - <i>Throws</i>: Nothing if <tt>Clock</tt> satisfies the <tt>TrivialClock</tt> requirements (20.11.3 [time.clock.req]) and
operations of <tt>Duration</tt> do not throw exceptions.
[<i>Note</i>: Instantiations of time point types and clocks supplied by the implementation as specified in 20.11.7 [time.clock] 
do not throw exceptions. &mdash; <i>end note</i>]</ins>
</p>
</blockquote></blockquote>

<blockquote><pre>
template &lt;class Rep, class Period&gt;
void sleep_for(const chrono::duration&lt;Rep, Period&gt;&amp; rel_time) <del>noexcept</del>;
</pre><blockquote><p>
6 [...]
<p/>
7 <i>Synchronization</i>: None.
<p/>
<ins>? <i>Throws</i>: Nothing if operations of <tt>chrono::duration&lt;Rep, Period&gt;</tt> do not throw exceptions.
[<i>Note</i>: Instantiations of duration types supplied by the implementation as specified in 20.11.7 [time.clock] 
do not throw exceptions. &mdash; <i>end note</i>]</ins>
</p>
</blockquote></blockquote>
</li>

<li><p>Fix a minor incorrectness in p. 5: Duration types need to compare against <tt>duration&lt;&gt;::zero()</tt>,
not <tt>0</tt>:</p>

<blockquote><p>
3 The expression <tt>m.try_lock_for(rel_time)</tt> shall be well-formed and have the following semantics:
<p/>
[...]
<p/>
5 <i>Effects</i>: The function attempts to obtain ownership of the mutex within the relative timeout (30.2.4)
specified by <tt>rel_time</tt>. If the time specified by <tt>rel_time</tt> is less than or equal to <del><tt>0</tt></del><ins><tt>rel_time.zero()</tt></ins>, 
the function attempts to obtain ownership without blocking (as if by calling <tt>try_lock()</tt>). The function shall return
within the timeout specified by <tt>rel_time</tt> only if it has obtained ownership of the mutex object.
[ <i>Note</i>: As with <tt>try_lock()</tt>, there is no guarantee that ownership will be obtained if the lock is
available, but implementations are expected to make a strong effort to do so. &mdash; <i>end note</i> ]
</p>
</blockquote>
</li>

<li><p>Modify the class <tt>timed_mutex</tt> synopsis in 30.4.1.3.1 [thread.timedmutex.class] as indicated:
<comment>Note, this duplicates edits also in D/N3267:</comment>
</p>

<blockquote><pre>
class timed_mutex {
public:
  [...]
  template &lt;class Rep, class Period&gt;
    bool try_lock_for(const chrono::duration&lt;Rep, Period&gt;&amp; rel_time) <del>noexcept</del>;
  template &lt;class Clock, class Duration&gt;
    bool try_lock_until(const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time) <del>noexcept</del>;
  [...]
};
</pre></blockquote>
</li>

<li><p>Modify the class <tt>recursive_timed_mutex</tt> synopsis in 30.4.1.3.2 [thread.timedmutex.recursive] as indicated:
<comment>Note, this duplicates edits also in D/N3267:</comment>
</p>

<blockquote><pre>
class recursive_timed_mutex {
public:
  [...]
  template &lt;class Rep, class Period&gt;
    bool try_lock_for(const chrono::duration&lt;Rep, Period&gt;&amp; rel_time) <del>noexcept</del>;
  template &lt;class Clock, class Duration&gt;
    bool try_lock_until(const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time) <del>noexcept</del>;
  [...]
};
</pre></blockquote>
</li>

<li><p>Modify the class template <tt>unique_lock</tt> synopsis in 30.4.2.2 [thread.lock.unique] as indicated.
<comment>Note, this duplicates edits also in D/N3267:</comment>
</p>

<blockquote><pre>
template &lt;class Mutex&gt;
class unique_lock {
public:
  [...]
  template &lt;class Clock, class Duration&gt;
    unique_lock(mutex_type&amp; m, const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time) <del>noexcept</del>;
  template &lt;class Rep, class Period&gt;
    unique_lock(mutex_type&amp; m, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time) <del>noexcept</del>;
  [...]
};
</pre></blockquote>
</li>

<li><p>Modify the constructor prototypes in 30.4.2.2.1 [thread.lock.unique.cons] before p. 14 and p. 17 
<comment>Note, this duplicates edits also in D/N3267:</comment>
</p>

<blockquote><pre>
template &lt;class Clock, class Duration&gt;
  unique_lock(mutex_type&amp; m, const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time) <del>noexcept</del>;
</pre></blockquote>

<blockquote><pre>
template &lt;class Rep, class Period&gt;
  unique_lock(mutex_type&amp; m, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time) <del>noexcept</del>;
</pre></blockquote>
</li>


</ol>






<hr>
<h3><a name="1494"></a>1494. [FCD] Term "are serialized" not defined</h3>
<p><b>Section:</b> 30.4.4.2 [thread.once.callonce] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-190</b></p>
<p>
The term "are serialized" is never defined (30.4.4.2 [thread.once.callonce] p. 2).
</p>
<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<p>
Remove the sentence with "are serialized" from
paragraph 2. Add "Calls to <tt>call_once</tt> on the same
<tt>once_flag</tt> object shall not introduce data races
(17.6.4.8)." to paragraph 3.
</p>

<p><i>[
2010-11-01 Daniel translates NB comment into wording
]</i></p>



<p><i>[
2011-02-17: Hans proposes an alternative resolution
]</i></p>


<p><i>[
2011-02-25: Hans, Clark, and Lawrence update the suggested wording
]</i></p>


<p><i>[2011-02-26 Reflector discussion]</i></p>

<p>
Moved to Tentatively Ready after 5 votes.
</p> 


<p><b>Proposed resolution:</b></p>
<p>Change 30.4.4.2 [thread.once.callonce] p.2+3 as indicated:</p>

<blockquote><pre>
template&lt;class Callable, class ...Args&gt;
void call_once(once_flag&amp; flag, Callable&amp;&amp; func, Args&amp;&amp;... args);
</pre><blockquote><p>
[..]
<p/>
2 <em>Effects</em>: <del>Calls to <tt>call_once</tt> on the same <tt>once_flag</tt> object are serialized.
If there has been a prior effective call to <tt>call_once</tt> on the same <tt>once_flag object</tt>, the call to <tt>call_once</tt> 
returns without invoking <tt>func</tt>. If there has been no prior effective call to <tt>call_once</tt> 
on the same <tt>once_flag</tt> object, <tt>INVOKE(decay_copy( std::forward&lt;Callable&gt;(func)), 
decay_copy(std::forward&lt;Args&gt;(args))...)</tt> is executed. The call to <tt>call_once</tt> is effective 
if and only if <tt>INVOKE(decay_copy( std::forward&lt;Callable&gt;(func)), decay_copy(std::forward&lt;Args&gt;(args))...)</tt> 
returns without throwing an exception. If an exception is thrown it is propagated to the caller.</del>
<ins>An execution of <code>call_once</code> that does not call its <code>func</code> is a passive execution.
An execution of <code>call_once</code> that calls its <code>func</code> is an active execution.
An active execution shall call <code><var>INVOKE</var>(decay_copy(std::forward&lt;Callable&gt;(func)),
decay_copy(std::forward&lt;Args&gt;(args))...)</code>. If such a call to <code>func</code> throws an exception,
the execution is exceptional, otherwise it is returning.
An exceptional execution shall propagate the exception to the caller of <code>call_once</code>.
Among all executions of <code>call_once</code> for any given <code>once_flag</code>: at most one shall be a 
returning execution; if there is a returning execution, it shall be the last active execution; and
there are passive executions only if there is a returning execution.
[<i>Note:</i> Passive executions allow other threads to reliably observe the results produced by the 
earlier returning execution. &mdash; <i>end note</i>]</ins>
<p/>
3 <em>Synchronization</em>: <del>The completion of an effective call to <tt>call_once</tt> on a <tt>once_flag</tt> 
object <em>synchronizes with</em> (1.10 [intro.multithread]) all subsequent calls to <tt>call_once</tt> 
on the same <tt>once_flag</tt> object.</del><ins>For any given <code>once_flag</code>: all active executions occur in a total 
order; completion of an active execution synchronizes with (1.10 [intro.multithread]) the start of 
the next one in this total order; and the returning execution synchronizes with the return from all passive 
executions.</ins>
</p></blockquote></blockquote>






<hr>
<h3><a name="1497"></a>1497. [FCD] <tt>lock()</tt> postcondition can not be generally achieved</h3>
<p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.condition">issues</a> in [thread.condition].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses CH-30</b></p>
<p>
If <tt>lock.lock()</tt> throws an exception, the postcondition can not be generally achieved.
</p>
<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote><p>
Either state that the postcondition might not be achieved, depending on the error condition, or
state that <tt>terminate()</tt> is called in this case.
</p></blockquote>

<p><i>[
2010-08-13 Peter Sommerlad comments and provides wording
]</i></p>


<blockquote><p>
30.5.1 [thread.condition.condvar], 30.5.2 [thread.condition.condvarany]
<p/>
p. 13, last bullet, and corresponding paragraphs in all wait functions
<p/>
Problem:<br/>
Condition variable wait might fail, because the lock cannot be acquired when notified.
CH-30 says: "If lock.lock() throws an exception, the postcondition can not be generally achieved."
CH-30 proposes: "Either state that the postcondition might not be achieved, depending on the error 
condition, or state that terminate() is called in this case."
<p/>
The discussion in Rapperswil concluded that calling <tt>terminate()</tt> might be too drastic in 
this case and a corresponding exception should be thrown&#47;passed on and one should use a lock type 
that allows querying its status, which <tt>unique_lock</tt> allows for <tt>std::condition_variable</tt>
<p/>
We also had some additional observations while discussing in Rapperswil:
</p>
<ul>
<li>in 30.5.1 [thread.condition.condvar] <tt>wait</tt> with predicate and <tt>wait_until</tt> with 
predicate lack the precondition, postcondition and Error conditions sections. the lack of the precondition 
would allow to call <tt>pred()</tt> without holding the lock.
</li>
<li>in 30.5.1 [thread.condition.condvar] <tt>wait_until</tt> and <tt>wait_for</tt> and 
30.5.2 [thread.condition.condvarany] <tt>wait_for</tt> still specify an 
error condition for a violated precondition. This should be removed.
</li>
</ul>
<p>
and add the following proposed solution:
</p>
</blockquote>

<p><i>[2011-02-27: Daniel adapts numbering to n3225]</i></p>



<p><b>Proposed resolution:</b></p>
<ol>
<li>Change 30.5.1 [thread.condition.condvar] as indicated:
<blockquote><pre>
void wait(unique_lock&lt;mutex&gt;&amp; lock);
</pre></blockquote>
<blockquote><p>
 9 <i>Requires</i>: <tt>lock</tt><ins><tt>.owns_lock()</tt> is <tt>true</tt> and <tt>lock.mutex()</tt></ins> is locked by the calling thread, and either
</p>
<ul>
<li>no other thread is waiting on this <tt>condition_variable</tt> object or
</li>
<li><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt> arguments supplied by all concurrently
waiting (via <tt>wait</tt> or <tt>timed_wait</tt>) threads.
</li>
</ul>
</blockquote>
[..]
<blockquote><p>
11 <em>Postcondition</em>: <tt>lock</tt><ins><tt>.owns_lock()</tt> is <tt>true</tt> and <tt>lock.mutex()</tt></ins> is locked by the calling thread.
</p></blockquote>
[..]
<blockquote><pre>
template &lt;class Predicate&gt;
void wait(unique_lock&lt;mutex&gt;&amp; lock, Predicate pred);
</pre></blockquote>
<blockquote><p>
<ins>?? <i>Requires</i>: <tt>lock.owns_lock()</tt> is <tt>true</tt> and <tt>lock.mutex()</tt> is locked by the calling thread, and either</ins>
</p>
<ul>
<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins>
</li>
<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt> arguments supplied by all concurrently
waiting (via <tt>wait</tt> or <tt>timed_wait</tt>) threads.</ins>
</li>
</ul>
</blockquote>
<blockquote><p>
14 <i>Effects</i>:
</p><blockquote><pre>
while (!pred())
  wait(lock);
</pre></blockquote>
</blockquote>

<blockquote><p>
<ins>?? <i>Postcondition</i>: <tt>lock.owns_lock()</tt> is <tt>true</tt> and <tt>lock.mutex()</tt> is locked by the calling thread.</ins>
</p></blockquote>
<blockquote><p>
<ins>?? <i>Throws</i>: <tt>std::system_error</tt> when an exception is required (30.2.2).</ins>
</p></blockquote>
<blockquote><p>
<ins>?? <em>Error conditions</em>:</ins>
</p>
<ul>
<li><ins>equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.</ins>
</li>
</ul>
</blockquote>

<blockquote><pre>
template &lt;class Clock, class Duration&gt;
cv_status wait_until(unique_lock&lt;mutex&gt;&amp; lock,
  const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
</pre></blockquote>
<blockquote><p>
15 <i>Requires</i>: <tt>lock</tt><ins><tt>.owns_lock()</tt> is <tt>true</tt> and <tt>lock.mutex()</tt></ins> is locked by the calling thread, and either
</p>
<ul>
<li>no other thread is waiting on this <tt>condition_variable</tt> object or
</li>
<li><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt> arguments supplied by all concurrently
waiting (via <tt>wait</tt>, <tt>wait_for</tt>, or <tt>wait_until</tt>) threads.
</li>
</ul>
</blockquote><p>
[..]
</p><blockquote><p>
17 <em>Postcondition</em>: <tt>lock</tt><ins><tt>.owns_lock()</tt> is <tt>true</tt> and <tt>lock.mutex()</tt></ins> is locked by the calling thread.
</p></blockquote>
[..]
<blockquote><p>
20 <em>Error conditions</em>:
</p>
<ul>
<li><del><tt>operation_not_permitted</tt> &mdash; if the thread does not own the lock.</del>
</li>
<li>equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
</li>
</ul>
</blockquote>
<blockquote><pre>
template &lt;class Rep, class Period&gt;
cv_status wait_for(unique_lock&lt;mutex&gt;&amp; lock,
  const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
</pre></blockquote>
<blockquote><p>
21 <i>Requires</i>: <tt>lock</tt><ins><tt>.owns_lock()</tt> is <tt>true</tt> and <tt>lock.mutex()</tt></ins> is locked by the calling thread, and either
</p>
<ul>
<li>no other thread is waiting on this <tt>condition_variable</tt> object or
</li>
<li><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt> arguments supplied by all concurrently
waiting (via <tt>wait</tt>, <tt>wait_for</tt>, or <tt>wait_until</tt>) threads.
</li>
</ul>
</blockquote><p>
[..]
</p><blockquote><p>
24 <em>Postcondition</em>: <tt>lock</tt><ins><tt>.owns_lock()</tt> is <tt>true</tt> and <tt>lock.mutex()</tt></ins> is locked by the calling thread.
</p></blockquote>
[..]
<blockquote><p>
26 <em>Error conditions</em>:
</p>
<ul>
<li><del><tt>operation_not_permitted</tt> &mdash; if the thread does not own the lock.</del>
</li>
<li>equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
</li>
</ul>
</blockquote>
<blockquote><pre>
template &lt;class Clock, class Duration, class Predicate&gt;
bool wait_until(unique_lock&lt;mutex&gt;&amp; lock,
  const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time,
    Predicate pred);
</pre></blockquote>
<blockquote><p>
<ins>?? <i>Requires</i>: <tt>lock.owns_lock()</tt> is <tt>true</tt> and <tt>lock.mutex()</tt> is locked by the calling thread, and either</ins>
</p>
<ul>
<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins>
</li>
<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt> arguments supplied by all concurrently
waiting (via <tt>wait</tt> or <tt>timed_wait</tt>) threads.</ins>
</li>
</ul>
</blockquote>
<blockquote><p>
27 <i>Effects</i>:
</p><blockquote><pre>
while (!pred())
  if (wait_until(lock, abs_time) == cv_status::timeout)
    return pred();
return true;
</pre></blockquote>
</blockquote>
<blockquote><p>
28 <i>Returns</i>: <tt>pred()</tt>
</p></blockquote>

<blockquote><p>
<ins>?? <i>Postcondition</i>: <tt>lock.owns_lock()</tt> is <tt>true</tt> and <tt>lock.mutex()</tt> is locked by the calling thread.</ins>
</p></blockquote>

<blockquote><p>
29 [ <i>Note</i>: The returned value indicates whether the predicate evaluates to true regardless of whether the
timeout was triggered. &mdash; <i>end note</i> ]
</p></blockquote>

<blockquote><p>
<ins>?? <i>Throws</i>: <tt>std::system_error</tt> when an exception is required (30.2.2).</ins>
</p></blockquote>
<blockquote><p>
<ins>?? <em>Error conditions</em>:</ins>
</p>
<ul>
<li><ins>equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.</ins>
</li>
</ul>
</blockquote>

<blockquote><pre>
template &lt;class Rep, class Period, class Predicate&gt;
bool wait_for(unique_lock&lt;mutex&gt;&amp; lock,
  const chrono::duration&lt;Rep, Period&gt;&amp; rel_time,
    Predicate pred);
</pre></blockquote>
<blockquote><p>
30 <i>Requires</i>: <tt>lock</tt><ins><tt>.owns_lock()</tt> is <tt>true</tt> and <tt>lock.mutex()</tt></ins> is locked by the calling thread, and either
</p>
<ul>
<li>no other thread is waiting on this <tt>condition_variable</tt> object or
</li>
<li><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt> arguments supplied by all concurrently
waiting (via <tt>wait</tt>, <tt>wait_for</tt>, or <tt>wait_until</tt>) threads.
</li>
</ul>
</blockquote><p>
[..]
</p><blockquote><p>
33 <em>Postcondition</em>: <tt>lock</tt><ins><tt>.owns_lock()</tt> is <tt>true</tt> and <tt>lock.mutex()</tt></ins> is locked by the calling thread.
</p></blockquote><p>
[..]
</p><blockquote><p>
37 <em>Error conditions</em>:
</p>
<ul>
<li><del><tt>operation_not_permitted</tt> &mdash; if the thread does not own the lock.</del>
</li>
<li>equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
</li>
</ul>
</blockquote>

</li>

<li>Change 30.5.2 [thread.condition.condvarany] as indicated:
<p/>
[..]
<blockquote><pre>
template &lt;class Lock, class Predicate&gt;
void wait(Lock&amp; lock, Predicate pred);
</pre></blockquote>
<blockquote><p>
<ins>[<i>Note</i>: if any of the wait functions exits with an exception it is indeterminate if the <tt>Lock</tt> is held. 
One can use a <tt>Lock</tt> type that allows to query that, such as the <tt>unique_lock</tt> wrapper. &mdash; <i>end note</i>]</ins>
</p></blockquote>
<blockquote><p>
11 <i>Effects</i>:
</p><blockquote><pre>
while (!pred())
  wait(lock);
</pre></blockquote>
</blockquote><p>
[..]
</p><blockquote><p>
31 <em>Error conditions</em>:
</p>
<ul>
<li><del><tt>operation_not_permitted</tt> &mdash; if the thread does not own the lock.</del>
</li>
<li>equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
</li>
</ul>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="1514"></a>1514. [FCD] <tt>packaged_task</tt> constructors need review</h3>
<p><b>Section:</b> 30.6.9.1 [futures.task.members] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-03-24</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#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-207</b></p>
<p>
The constructor that takes <tt>R(*)(ArgTypes...)</tt> is not
needed; the constructor that takes a callable type works
for this argument type. More generally, the constructors
for packaged_task should parallel those for function.
</p>
<p><i>[
US-207 Suggested Resolution:
]</i></p>


<blockquote><p>
Review the constructors for packaged_task and
provide the same ones as function, except where
inappropriate.
</p></blockquote>

<p><i>[
2010-10-22 Howard provides wording, as requested by the LWG in Rapperswil.
]</i></p>


<p><i>[2011-02-10 Reflector discussion]</i></p>

<p>
Moved to Tentatively Ready after 5 votes.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Alter the list of constructors in both 30.6.9 [futures.task] and in 30.6.9.1 [futures.task.members] as indicated:
</p>
<blockquote>
<pre><del>template &lt;class F&gt;
explicit packaged_task(F f);
template &lt;class F, class Allocator&gt;
explicit packaged_task(allocator_arg_t, const Allocator&amp; a, F f);
explicit packaged_task(R(*f)(ArgTypes...));</del>
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);
</pre>
</blockquote>





<hr>
<h3><a name="1521"></a>1521. Requirements on internal pointer representations in containers</h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Deferred">Deferred</a>
 <b>Submitter:</b> Mike Spertus <b>Opened:</b> 2010-10-16 <b>Last modified:</b> 2011-03-24</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#Deferred">Deferred</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-104, US-141</b></p>

<p>
The standard doesn't say that containers should use abstract pointer 
types internally. Both Howard and Pablo agree that this is the intent. 
Further, it is necessary for containers to be stored, for example, in 
shared memory with an interprocess allocator (the type of scenario that 
allocators are intended to support).
</p>
<p>
In spite of the (possible) agreement on intent, it is necessary to make 
this explicit:
</p>
<p>
An implementations may like to store the result of dereferencing the 
pointer (which is a raw reference) as an optimization, but that prevents 
the data structure from being put in shared memory, etc. In fact, a 
container could store raw references to the allocator, which would be a 
little weird but conforming as long as it has one by-value copy. 
Furthermore, pointers to locales, ctypes, etc. may be there, which also 
prevents the data structure from being put in shared memory, so we 
should make explicit that a container does not store raw pointers or 
references at all.
</p>

<p><i>[
Pre-batavia
]</i></p>

<p>
This issue is being opened as part of the response to NB comments US-104/141. 
See paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3171.pdf">N3171</a>
in the pre-Batavia mailing. 
</p>

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


<p>Deferred</p>



<p><b>Proposed resolution:</b></p>
<p>
Add to the end of 23.2.1 [container.requirements.general] p. 8:
</p>
<blockquote><p>
[..] 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. <ins>The container may not store internal objects whose 
types are of the form  <tt>T *</tt> or <tt>T &amp;</tt> except insofar as they are part of the 
item type or members.</ins>
</p></blockquote>





<hr>
<h3><a name="1524"></a>1524. [FCD] Allocation functions are missing <i>happens-before</i> requirements and guarantees</h3>
<p><b>Section:</b> 18.6.1.4 [new.delete.dataraces] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2011-02-26 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#new.delete.dataraces">issues</a> in [new.delete.dataraces].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-34</b></p>

<p>Technical details:
<p/>
When the same unit of storage is allocated and deallocated repeatedly, operations on it can't be allowed to
race between the allocator and the user program. But I don't see any mention of <i>happens-before</i> in the
descriptions of allocation and deallocation functions.
<p/>
Proposed resolution (not wording yet):
</p>
<ul>
<li><p>The call to an allocation function returning a pointer <tt>P</tt> must happen-before the matching
deallocation call with <tt>P</tt> as a parameter. Otherwise the behavior is undefined. I don't know whether
receiving <tt>P</tt> with <tt>memory_order_consume</tt> fits this requirement. <tt>memory_order_relaxed</tt> does not.</p>
</li>
<li><p>If some memory is passed to a deallocation function, the implementation must ensure that the
deallocation call happens-before any allocation call that returns the same memory address.</p>
</li>
</ul>

<p><i>[2011-02-26: Hans comments and drafts wording]</i></p>


<p>The second requirement already exists, almost verbatim, as 18.6.1.4 [new.delete.dataraces] p. 1. 
I think this is where the statement belongs.  However, this paragraph requires work to correctly address 
the first part of the issue.
</p>

<p><i>[Adopted at Madrid, 2011-03]</i></p>




<p><b>Proposed resolution:</b></p>
<p>Change 18.6.1.4 [new.delete.dataraces] p. 1 as follows:</p>

<blockquote><p>
1 <del>The library versions of <tt>operator new</tt> and <tt>operator delete</tt>, user replacement versions of global 
<tt>operator new</tt> and <tt>operator delete</tt>, and the C standard library functions <tt>calloc</tt>, <tt>malloc</tt>, 
<tt>realloc</tt>, and <tt>free</tt> shall not introduce data races (1.10 [intro.multithread]) as a result 
of concurrent calls from different threads.</del><ins> For purposes of determining the existence of data races,
the library versions of <tt>operator new</tt>, user replacement versions of global <tt>operator new</tt>, and the C 
standard library functions <tt>calloc</tt> and <tt>malloc</tt> shall behave as though they accessed and modified only 
the storage referenced by the return value. The library versions of <tt>operator delete</tt>, user replacement
versions of <tt>operator delete</tt>, and the C standard library function <tt>free</tt> shall behave as though they 
accessed and modified only the storage referenced by their first argument. The C standard library <tt>realloc</tt> 
function shall behave as though it accessed and modified only the storage referenced by its first argument and by 
its return value.</ins> Calls to these functions that allocate or deallocate a particular unit of storage 
shall occur in a single total order, and each such deallocation call shall happen before the next allocation 
(if any) in this order.
</p></blockquote>





<hr>
<h3><a name="1525"></a>1525. [FCD] Effects of <tt>resize(size())</tt> on a <tt>vector</tt></h3>
<p><b>Section:</b> 23.3.6.3 [vector.capacity] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2011-03-24 <b>Last modified:</b> 2011-03-25</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-117</b></p>

<p>23.3.6.3 [vector.capacity] p. 9 (Same as for 23.3.3.3 [deque.capacity] p. 1 i.e. 
<tt>deque::resize</tt>). There is no mention of what happens if <tt>sz==size()</tt>. While 
it obviously does nothing I feel a standard needs to say this explicitely.</p>
<p>Suggested resolution:</p>
<p>Append "If <tt>sz == size()</tt>, does nothing" to the effects.</p>

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


<p>During the edit of this issue some non-conflicting overlap with <a href="lwg-active.html#2033">2033</a> became obvious. 
<tt>CopyInsertable</tt> should be <tt>MoveInsertable</tt> and there is missing the <tt>DefaultConstructible</tt> 
requirements, but this should be fixed by <a href="lwg-active.html#2033">2033</a>.</p>


<p><b>Proposed resolution:</b></p>
<p>Change 23.3.6.3 [vector.capacity] p. 9 as follows:</p>

<blockquote><pre>
void resize(size_type sz);
</pre>
<blockquote><p>
9 <i>Effects</i>: If <tt>sz &lt;<ins>=</ins> size()</tt>, equivalent to <tt>erase(begin() + sz, end());</tt>. 
If <tt>size() &lt; sz</tt>, appends <tt>sz - size()</tt> value-initialized elements to the sequence.
<p/>
10 <i>Requires</i>: <tt>T</tt> shall be <tt>CopyInsertable</tt> into <tt>*this</tt>.
</p></blockquote></blockquote>





<hr>
<h3><a name="1526"></a>1526. [FCD] 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#Deferred">Deferred</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2011-03-24 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Deferred">Deferred</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><b>Rationale:</b></p>No consensus to make a change at this time

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





<hr>
<h3><a name="2000"></a>2000. Missing definition of <tt>packaged_task</tt> specialization of <tt>uses_allocator</tt></h3>
<p><b>Section:</b> 30.6.9.2 [futures.task.nonmembers] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2010-08-29 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>
[futures.task.nonmembers]/3 says:
</p>
<blockquote><pre>
   template &lt;class R, class Alloc&gt;
     struct uses_allocator&lt;packaged_task&lt;R&gt;, Alloc&gt;;
</pre></blockquote>
<p>
This is a declaration, but should be a definition.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change [futures.task.nonmembers]/3:
</p>

<blockquote><pre>
   template &lt;class R, class Alloc&gt;
     struct uses_allocator&lt;packaged_task&lt;R&gt;, Alloc&gt;<del>;</del>
        <ins>: true_type {};</ins>
</pre></blockquote>





<hr>
<h3><a name="2001"></a>2001. Class template <tt>basic_regex</tt> uses non existent <tt>string_type</tt></h3>
<p><b>Section:</b> 28.8.3 [re.regex.assign] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> Volker Lukas <b>Opened:</b> 2010-10-21 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In working draft N3126, subclause 28.8.3 [re.regex.assign], paragraphs 12, 13 and 19, 
the name <tt>string_type</tt> is used. This is presumably a typedef for <tt>basic_string&lt;value_type&gt;</tt>, where 
<tt>value_type</tt> is the character type used by <tt>basic_regex</tt>. The <tt>basic_regex</tt> 
template however defines no such typedef, and neither does the <tt>&lt;regex&gt;</tt> 
header or the <tt>&lt;initializer_list&gt;</tt> header included by <tt>&lt;regex&gt;</tt>.
</p>

<p><i>[
2010-11-03 Daniel comments and suggests alternative wording:
]</i></p>

<blockquote><p>
The proposed resolution needs to use <tt>basic_string&lt;<strong>charT</strong>&gt;</tt> instead of <tt>basic_string&lt;char&gt;</tt>
</p></blockquote>

<p>
Previous Proposed Resolution:
<p/>
Make the following changes to [re.regex.assign]:
</p>
<blockquote>
<pre>
basic_regex&amp; assign(const charT* ptr, flag_type f = regex_constants::ECMAScript);
</pre>
<blockquote><p>
12 <i>Returns</i>: <tt>assign(<del>string_type</del><ins>basic_string&lt;charT&gt;</ins>(ptr), f)</tt>. 
</p></blockquote>

<pre>
basic_regex&amp; assign(const charT* ptr, size_t len,
  flag_type f = regex_constants::ECMAScript);
</pre>
<blockquote><p>
13 <i>Returns</i>: <tt>assign(<del>string_type</del><ins>basic_string&lt;charT&gt;</ins>(ptr, len), f)</tt>.
</p></blockquote>

<pre>
[..]

template &lt;class InputIterator&gt; 
  basic_regex&amp; assign(InputIterator first, InputIterator last, 
                          flag_type f = regex_constants::ECMAScript);
</pre>

<blockquote><p>
18 <i>Requires</i>: The type <tt>InputIterator</tt> shall satisfy the requirements for an Input Iterator (24.2.3).
</p></blockquote>

<blockquote><p>
19 <i>Returns</i>: <tt>assign(<del>string_type</del><ins>basic_string&lt;charT&gt;</ins>(first, last), f)</tt>.
</p></blockquote>

</blockquote>

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


<p>
Unsure if we should just give <tt>basic_regex</tt> a <tt>string_type</tt> typedef. Looking for when <tt>string_type</tt> was 
introduced into <tt>regex</tt>. Howard to draft wording for <tt>typedef typename traits::string_type string_type</tt>, then move to Review. 
</p>

<p><i>[
2011-02-16: Daniel comments and provides an alternative resolution.
]</i></p>


<p>
I'm strongly in favour with the Batavia idea to provide a separate <tt>string_type</tt> within
<tt>basic_regex</tt>, but it seems to me that the issue resultion should add one more
important typedef, namely that of the traits type! Currently, <tt>basic_regex</tt> is the
<em>only</em> template that does not publish the type of the associated traits type. Instead
of opening a new issue, I added this suggestion as part of the proposed wording.
</p>

<p><i>[2011-02-24 Reflector discussion]</i></p>

<p>
Moved to Tentatively Ready after 6 votes.
</p> 


<p><b>Proposed resolution:</b></p>
<p>
Change the class template <tt>basic_regex</tt> synopsis, 28.8 [re.regex] p. 3, as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class charT,
            class traits = regex_traits&lt;charT&gt; &gt;
  class basic_regex {
  public:
    // types:
    typedef charT value_type;
    <ins>typedef traits traits_type;</ins>
    <ins>typedef typename traits::string_type string_type;</ins>
    typedef regex_constants::syntax_option_type flag_type;
    typedef typename traits::locale_type locale_type;

    [..]
  };
}
</pre></blockquote>






<hr>
<h3><a name="2003"></a>2003. String exception inconsistency in erase.</h3>
<p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jos&eacute; Daniel Garc&iacute;a S&aacute;nchez <b>Opened:</b> 2010-10-21 <b>Last modified:</b> 2011-03-24</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>
Clause 21.4.1 [string.require]p3 states:
</p>
<blockquote><p>
No <tt>erase()</tt> or <tt>pop_back()</tt> member function shall throw
any exceptions.
</p></blockquote>
<p>
However in 21.4.6.5 [string::erase] p2 the first version of <tt>erase</tt> has
</p>
<blockquote><p>
<i>Throws</i>: <tt>out_of_range</tt> if <tt>pos > size()</tt>.
</p></blockquote>

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


<p>
Beman: Don't want to just change this, can we just say "unless otherwise specified"?
<p/>
Alisdair: Leave open, but update proposed resolution to say something like "unless otherwise specified".
<p/>
General agreement that it should be corrected but not a stop-ship.
<p/>
Action: Update proposed wording for issue 2003 as above, but leave Open. 
</p>


<p><b>Proposed resolution:</b></p>
<p>
Update [string.require]p/3:
</p>
<blockquote><p>
3 No <del><tt>erase()</tt> or</del> <tt>pop_back()</tt> member function
shall throw any exceptions.
</p></blockquote>





<hr>
<h3><a name="2004"></a>2004. <tt>duration::operator*</tt> has template parameters in funny order</h3>
<p><b>Section:</b> 20.11.5.5 [time.duration.nonmember] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2010-10-14 <b>Last modified:</b> 2011-03-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#time.duration.nonmember">active issues</a> in [time.duration.nonmember].</p>
<p><b>View all other</b> <a href="lwg-index.html#time.duration.nonmember">issues</a> in [time.duration.nonmember].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In [time] and [time.duration.nonmember] we have:
</p>
<blockquote><pre>
template &lt;class Rep1, class Period, class Rep2>
    duration&lt;typename common_type&lt;Rep1, Rep2>::type, Period>
        operator*(const Rep1&amp; s, const duration&lt;Rep2, Period>&amp; d);
</pre></blockquote>
<p>
Everywhere else, we always have <tt>&lt;rep, period></tt> in that order for a given
type. But here, we have <tt>Period</tt> and <tt>Rep2</tt> in reverse order for
<tt>&lt;Rep2, Period></tt>. This is probably of little importance, since the
template parameters are seldom spelled out for a function like this. But changing it
now will eliminate a potential source of future errors and confusion.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the signature in [time] and [time.duration.nonmember] to:
</p>
<blockquote><pre>
template &lt;class Rep1, class <del>Period</del><ins>Rep2</ins>, class <del>Rep2</del><ins>Period</ins>>
    duration&lt;typename common_type&lt;Rep1, Rep2>::type, Period>
        operator*(const Rep1&amp; s, const duration&lt;Rep2, Period>&amp; d);
</pre></blockquote>





<hr>
<h3><a name="2005"></a>2005. <tt>unordered_map::insert(T&amp;&amp;)</tt> protection should apply to <tt>map</tt> too</h3>
<p><b>Section:</b> 23.4.4.4 [map.modifiers], 23.4.5.3 [multimap.modifiers] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2010-10-14 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In [unord.map.modifiers], the signature:
</p>
<blockquote><pre>
template &lt;class P&gt;
    pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);
</pre></blockquote>
<p>
now has an added Remarks paragraph:
</p>
<blockquote><p>
<i>Remarks</i>: This signature shall not participate in overload resolution unless <tt>P</tt>
is implicitly convertible to <tt>value_type</tt>.
</p></blockquote>
<p>
The same is true for <tt>unordered_multimap</tt>.
<p/>
But neither <tt>map</tt> nor <tt>multimap</tt> have this constraint, even though it is a
Good Thing(TM) in those cases as well.
</p>

<p><i>[
The submitter suggests: Add the same Remarks clause to [map.modifiers] and [multimap.modifiers].
]</i></p>


<p><i>[
2010-10-29 Daniel comments:
]</i></p>


<p>
I believe both paragraphs need more cleanup: First, the current Requires element conflict with the Remark; 
second, it seems to me that the whole single Requires element is intended to be split into a Requires
and an Effects element; third, the reference to <tt>tuple</tt> is incorrect (noticed by Paolo Carlini);
fourth, it refers to some non-existing <tt>InputIterator</tt> parameter relevant for a completely different
overload; sixth, the return type of the overload with hint is wrong.
The following proposed resolution tries to solve these issues as well and uses similar wording as for
the corresponding unordered containers. Unfortunately it has some redundancy over Table&nbsp;99, but I did
not remove the specification because of the more general template parameter <tt>P</tt> - the Table&nbsp;99 
requirements apply only for an argument <em>identical</em> to <tt>value_type</tt>.
<p/>
Proposed resolution:
</p>

<ol>
<li>Change 23.4.4.4 [map.modifiers] around p. 1 as indicated:
<blockquote><pre>
template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);
template &lt;class P&gt; <del>pair&lt;</del>iterator<del>, bool&gt;</del> insert(const_iterator position, P&amp;&amp; x);
</pre><blockquote><p>
1 <em>Requires</em>: <del><tt>P</tt> shall be convertible to </del><tt>value_type</tt><ins> is constructible 
from <tt>std::forward&lt;P&gt;(x)</tt>.</ins>.
<p/>
<del>If <tt>P</tt> is instantiated as a reference type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt> is considered
to be an rvalue as it is converted to <tt>value_type</tt> and inserted into the map. Specifically, in
such cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or <tt>mapped_type</tt> unless the conversion
from <tt>P</tt> specifically requires it (e.g., if <tt>P</tt> is a <tt>tuple&lt;const key_type, mapped_type&gt;</tt>, then <tt>key_type</tt>
must be <tt>CopyConstructible</tt>). The signature taking <tt>InputIterator</tt> parameters 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>.</del><br/>
<ins>? <em>Effects</em>: Inserts <tt>x</tt> converted to <tt>value_type</tt> if and only if there is no element in the container with
key equivalent to the key of <tt>value_type(x)</tt>. For the second form, the iterator <tt>position</tt> is a hint pointing to where the
search should start.</ins>
<p/>
<ins>? <em>Returns</em>: For the first form, the <tt>bool</tt> component of the returned <tt>pair</tt> object indicates whether the 
insertion took place and the iterator component - or for the second form the returned iterator - points to the element with key equivalent 
to the key of <tt>value_type(x)</tt>.</ins>
<p/>
<ins>? <em>Complexity</em>: Logarithmic in general, but amortized constant if <tt>x</tt> is inserted right before <tt>position</tt>.</ins>
<p/>
<ins>? <em>Remarks</em>: These signatures shall not participate in overload resolution unless <tt>P</tt> 
is implicitly convertible to <tt>value_type</tt>.</ins>
</p>
</blockquote></blockquote>
</li>
<li>Change 23.4.5.3 [multimap.modifiers] around p. 1 as indicated:
<blockquote><pre>
template &lt;class P&gt; iterator insert(P&amp;&amp; x);
template &lt;class P&gt; iterator insert(const_iterator position, P&amp;&amp; x);
</pre><blockquote><p>
1 <em>Requires</em>: <del><tt>P</tt> shall be convertible to </del><tt>value_type</tt> <ins>is constructible from 
<tt>std::forward&lt;P&gt;(x)</tt></ins>.
<p/>
<del>If <tt>P</tt> is instantiated as a reference type, then the argument <tt>x</tt> is copied from. Otherwise 
<tt>x</tt> is considered to be an rvalue as it is converted to <tt>value_type</tt> and inserted into the map. 
Specifically, in such cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or <tt>mapped_type</tt> 
unless the conversion from <tt>P</tt> specifically requires it (e.g., if <tt>P</tt> is a <tt>tuple&lt;const key_type, mapped_type&gt;</tt>, 
then <tt>key_type</tt> must be <tt>CopyConstructible</tt>). The signature taking <tt>InputIterator</tt> parameters 
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>.</del><br/>
<ins>? <em>Effects</em>: Inserts <tt>x</tt> converted to <tt>value_type</tt>. For the second form, the iterator <tt>position</tt> 
is a hint pointing to where the search should start.</ins>
<p/>
<ins>? <em>Returns</em>: An iterator that points to the element with key equivalent to the key of <tt>value_type(x)</tt>.</ins>
<p/>
<ins>? <em>Complexity</em>: Logarithmic in general, but amortized constant if <tt>x</tt> is inserted right before <tt>position</tt>.</ins>
<p/>
<ins>? <em>Remarks</em>: These signatures shall not participate in overload resolution unless <tt>P</tt> 
is implicitly convertible to <tt>value_type</tt>.</ins>
</p>
</blockquote></blockquote>
</li>
</ol>

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


<p>
We need <tt>is_convertible</tt>, not <tt>is_constructible</tt>, both in ordered and unordered containers. 
</p>



<p><b>Proposed resolution:</b></p>
<ol>
<li>Add a new Remarks element after 23.4.4.4 [map.modifiers] p. 1:
<blockquote><pre>
template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);
template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(const_iterator position, P&amp;&amp; x);
</pre><blockquote><p>
1 <em>Requires</em>: <tt>P</tt> shall be convertible to <tt>value_type</tt>.
<p/>
If <tt>P</tt> is instantiated as a reference type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt> is considered
to be an rvalue as it is converted to <tt>value_type</tt> and inserted into the map. Specifically, in
such cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or <tt>mapped_type</tt> unless the conversion
from <tt>P</tt> specifically requires it (e.g., if <tt>P</tt> is a <tt>tuple&lt;const key_type, mapped_type&gt;</tt>, then <tt>key_type</tt>
must be <tt>CopyConstructible</tt>). The signature taking <tt>InputIterator</tt> parameters 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/>
<ins>? <em>Remarks</em>: These signatures shall not participate in overload resolution unless <tt>P</tt> 
is implicitly convertible to <tt>value_type</tt>.</ins>
</p>
</blockquote></blockquote>
</li>
<li>Change 23.4.5.3 [multimap.modifiers] around p. 1 as indicated:
<blockquote><pre>
template &lt;class P&gt; iterator insert(P&amp;&amp; x);
template &lt;class P&gt; iterator insert(const_iterator position, P&amp;&amp; x);
</pre><blockquote><p>
1 <em>Requires</em>: <tt>P</tt> shall be convertible to <tt>value_type</tt>.
<p/>
If <tt>P</tt> is instantiated as a reference type, then the argument <tt>x</tt> is copied from. Otherwise 
<tt>x</tt> is considered to be an rvalue as it is converted to <tt>value_type</tt> and inserted into the map. 
Specifically, in such cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or <tt>mapped_type</tt> 
unless the conversion from <tt>P</tt> specifically requires it (e.g., if <tt>P</tt> is a <tt>tuple&lt;const key_type, mapped_type&gt;</tt>, 
then <tt>key_type</tt> must be <tt>CopyConstructible</tt>). The signature taking <tt>InputIterator</tt> parameters 
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/>
<ins>? <em>Remarks</em>: These signatures shall not participate in overload resolution unless <tt>P</tt> 
is implicitly convertible to <tt>value_type</tt>.</ins>
</p>
</blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="2006"></a>2006. <tt>emplace</tt> broken for associative containers</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2010-10-18 <b>Last modified:</b> 2011-03-24</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#Tentatively NAD">Tentatively NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current definition of <tt>emplace(args)</tt> for associative containers as
described in Table 99 is:
</p>
<blockquote>
<p>
<i>Requires</i>: <tt>T</tt> shall be constructible from <tt>args</tt>.
<p/>
<i>Effects</i>: Inserts a <tt>T</tt> object <tt>t</tt> constructed with
<tt>std::forward&lt;Args&gt;(args)...</tt> if and only if there is no element
in the container with key equivalent to the key of <tt>t</tt>.  The <tt>bool</tt>
component of the returned <tt>pair</tt> is <tt>true</tt> if and only if the
insertion takes place, and the iterator component of the <tt>pair</tt>
points to the element with key equivalent to the key of <tt>t</tt>.
</p>
</blockquote>
<p>
There is similar language in Table 100 for unordered associative containers.
<p/>
The first issue is editorial: <tt>T</tt> should be <tt>value_type</tt> throughout
both tables.
<p/>
The major issue is that, if the container is <tt>map</tt>, <tt>multimap</tt>,
<tt>unordered_map</tt>, or <tt>unordered_multimap</tt>, then the only way to
construct an object of <tt>value_type</tt> is to supply exactly two arguments
for <tt>Key</tt> and <tt>Value</tt>, a <tt>pair&lt;Key,Value&gt;</tt>, or a
<tt>piecewise_construct_t</tt> followed by two <tt>tuple</tt>s.  The original
<tt>emplace()</tt> proposal would have allowed you to specify a <tt>Key</tt>
value followed by any number of constructor arguments for <tt>Value</tt>.
When we removed the variadic constructor to <tt>pair</tt>, this ability went
away.  I don't think that was deliberate.
<p/>
Fixing this is non-trivial, I think. I think that <tt>emplace()</tt> for <tt>map</tt>
and <tt>multimap</tt> need several overloads: one for each overloaded constructor in
<tt>pair&lt;Key,Value&gt;</tt>, and one for the <tt>emplace(Key, valueargs...)</tt> case.
And it probably needs some SFINAE meta-programming to ensure that the last case
doesn't override any of the other ones.  Alternatively, one could say that
there are exactly two cases: <tt>emplace(args)</tt> where <tt>pair&lt;Key,Value&gt;</tt>
is constructible from <tt>args</tt>, and <tt>emplace(args)</tt> where <tt>Key</tt> is
constructible form the first <tt>arg</tt> and <tt>Value</tt> is constructible from the
rest.
<p/>
Alternatively, the status quo is to use <tt>piecewise_construct_t</tt> if you want to
construct an object.
</p>

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


<p>
N3178 was looked at in session and moved to NAD.
</p>


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





<hr>
<h3><a name="2007"></a>2007. Incorrect specification of return value for <tt>map&lt;&gt;::at()</tt></h3>
<p><b>Section:</b> 23.4.4.3 [map.access] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2010-11-01 <b>Last modified:</b> 2011-03-24</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#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In [map.access]/9, the <i>Returns</i> clause for <tt>map&lt;Key, T&gt;::at(x)</tt> says 
that it returns "a reference to the element whose key is equivalent to <tt>x</tt>." That can't be right. 
The signature for <tt>at()</tt> says that its return type is <tt>T</tt>, but the elements 
of <tt>map&lt;Key, T&gt;</tt> have type <tt>pair&lt;const K, T&gt;</tt>.  (I checked [unord.map.elem] 
and found that its specification of <tt>at()</tt> is correct. This is a problem for <tt>map</tt> only.)
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the wording in [map.access]/9 so it's identical to what we already say for <tt>operator[]</tt>, 
which is unambiguous and correct.
</p>
<blockquote><p>
<i>Returns</i>: A reference to the <del>element whose key is equivalent</del><ins><tt>mapped_type</tt> 
corresponding</ins> to <tt>x</tt><ins> in <tt>*this</tt></ins>.
</p></blockquote>





<hr>
<h3><a name="2008"></a>2008. Conflicting Error Conditions for <tt>packaged_task::operator()</tt></h3>
<p><b>Section:</b> 30.6.9.1 [futures.task.members] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2010-06-21 <b>Last modified:</b> 2011-03-24</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The Throws clause for <tt>packaged_task::operator()</tt> says that it throws "a
<tt>future_error</tt> exception object if there is no associated asynchronous
state or the stored task has already been invoked." However, the Error
Conditions clause does not define an error condition when the stored task has
already been invoked, only when the associated state is already ready (i.e. the
invocation has completed).
</p>

<p><i>[2011-02-17 Anthony provides an alternative resolution]</i></p>


<p><strong>Previous</strong> proposed resolution:</p>

<p>
Change the first bullet item in 30.6.9.1 [futures.task.members] /22:
</p>

<blockquote><pre>
void operator()(ArgTypes... args);
</pre>
<blockquote>
<p>
20 ...
</p>
<p>
21 ...
</p>
<p>
22 <i>Error conditions:</i>
</p>
<ul>
<li>
<tt>promise_already_satisfied</tt> if <del>the associated asynchronous state is
already ready</del> <ins><tt>operator()</tt> has already been called</ins>.
</li>
<li>
<tt>no_state</tt> if <tt>*this</tt> has no associated asynchronous state.
</li>
</ul>
</blockquote>
</blockquote>

<p><i>[Adopted at Madrid, 2011-03]</i></p>




<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Change the first bullet item in 30.6.9.1 [futures.task.members] p. 17:
</p>

<blockquote><pre>
void operator()(ArgTypes... args);
</pre>
<blockquote>
<p>
15 ...
</p>
<p>
16 ...
</p>
<p>
17 <i>Error conditions:</i>
</p>
<ul>
<li>
<tt>promise_already_satisfied</tt> if the <del>associated asynchronous state is already 
ready</del><ins>stored task has already been invoked</ins>.
</li>
<li>
<tt>no_state</tt> if <tt>*this</tt> has no associated asynchronous state.
</li>
</ul>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change the first bullet item in 30.6.9.1 [futures.task.members] p. 21:
</p>

<blockquote><pre>
void make_ready_at_thread_exit(ArgTypes... args);
</pre>
<blockquote>
<p>
19 ...
</p>
<p>
20 ...
</p>
<p>
21 <i>Error conditions:</i>
</p>
<ul>
<li>
<tt>promise_already_satisfied</tt> if the <del>associated asynchronous state already has a stored value or
exception</del><ins>stored task has already been invoked</ins>.
</li>
<li>
<tt>no_state</tt> if <tt>*this</tt> has no associated asynchronous state.
</li>
</ul>
</blockquote>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="2009"></a>2009. Reporting out-of-bound values on numeric string conversions</h3>
<p><b>Section:</b> 21.5 [string.conversions] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2010-07-19 <b>Last modified:</b> 2011-03-24</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#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The functions (<tt>w</tt>)<tt>stoi</tt> and (<tt>w</tt>)<tt>stof</tt>
are specified in terms of calling C library APIs for potentially wider
types.  The integer and floating-point versions have subtly different
behaviour when reading values that are too large to convert.  The
floating point case will throw <tt>out_of_bound</tt> if the read value
is too large to convert to the wider type used in the implementation,
but behaviour is undefined if the converted value cannot narrow to a
float.  The integer case will throw <tt>out_of_bounds</tt> if the
converted value cannot be represented in the narrower type, but throws
<tt>invalid_argument</tt>, rather than <tt>out_of_range</tt>, if the
conversion to the wider type fails due to overflow.
</p>

<p>
Suggest that the Throws clause for both specifications should be
consistent, supporting the same set of fail-modes with the matching set
of exceptions.
</p>



<p><b>Proposed resolution:</b></p>
<p>
21.5p3 [string.conversions]
</p>

<blockquote><pre>
int stoi(const string&amp; str, size_t *idx = 0, int base = 10);
long stol(const string&amp; str, size_t *idx = 0, int base = 10);
unsigned long stoul(const string&amp; str, size_t *idx = 0, int base = 10);
long long stoll(const string&amp; str, size_t *idx = 0, int base = 10);
unsigned long long stoull(const string&amp; str, size_t *idx = 0, int base = 10);
</pre>

<blockquote>
<p>
...
</p>
<p>
3 <i>Throws:</i> <tt>invalid_argument</tt> if <tt>strtol</tt>,
<tt>strtoul</tt>, <tt>strtoll</tt>, or <tt>strtoull</tt> reports that no
conversion could be performed. Throws <tt>out_of_range</tt> if
<ins><tt>strtol</tt>, <tt>strtoul</tt>, <tt>strtoll</tt> or
<tt>strtoull</tt> sets <tt>errno</tt> to <tt>ERANGE</tt>, or if</ins>
the converted value is outside the range of representable values for the
return type.
</p>
</blockquote>
</blockquote>

<p>
21.5p6 [string.conversions]
</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>
...
</p>
<p>
6 <i>Throws:</i> <tt>invalid_argument</tt> if <tt>strtod</tt> or
<tt>strtold</tt> reports that no conversion could be performed. Throws
<tt>out_of_range</tt> if <tt>strtod</tt> or <tt>strtold</tt> sets
<tt>errno</tt> to <tt>ERANGE</tt> <ins> or if the converted value is
outside the range of representable values for the return type</ins>.
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="2010"></a>2010. <tt>is_* traits</tt> for binding operations can't be meaningfully specialized</h3>
<p><b>Section:</b> 20.8.9.1.1 [func.bind.isbind] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Sean Hunt <b>Opened:</b> 2010-07-19 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#func.bind.isbind">issues</a> in [func.bind.isbind].</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.9.1.1 [func.bind.isbind] says for <tt>is_bind_expression</tt>:
</p>

<blockquote><p>
Users may specialize this template to indicate that a type should be
treated as a subexpression in a <tt>bind</tt> call.
</p></blockquote>

<p>
But it also says:
</p>

<blockquote><p>
If <tt>T</tt> is a type returned from <tt>bind</tt>,
<tt>is_bind_expression&lt;T&gt;</tt> shall be publicly derived from
<tt>integral_constant&lt;bool, true&gt;</tt>, otherwise from
<tt>integral_constant&lt;bool, false&gt;</tt>.
</p></blockquote>

<p>
This means that while the user is free to specialize, any specialization
would have to be <tt>false</tt> to avoid violating the second
requirement. A similar problem exists for <tt>is_placeholder</tt>.
</p>


<p><i>[
2010 Batavia (post meeting session)
]</i></p>

<p>
Alisdair recognises this is clearly a bug introduced by some wording he
wrote, the sole purpose of this metafunction is as a customization point
for users to write their own <tt>bind</tt>-expression types that participate
in the standard library <tt>bind</tt> protocol.  The consensus was that this
should be fixed in Madrid, moved to Open.
</p>

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





<hr>
<h3><a name="2011"></a>2011. unexpected output required of strings</h3>
<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> James Kanze <b>Opened:</b> 2010-07-23 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#string.io">issues</a> in [string.io].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
What should the following code output? 
</p>

<blockquote><pre>
#include &lt;string>
#include &lt;iostream>
#include &lt;iomanip>

int 
main() 
{ 
   std::string test("0X1Y2Z"); 
   std::cout.fill('*'); 
   std::cout.setf(std::ios::internal, std::ios::adjustfield); 
   std::cout &lt;&lt; std::setw(8) &lt;&lt; test &lt;&lt; std::endl; 
} 
</pre></blockquote>

<p>
I would expect "<tt>**0X1Y2Z</tt>", and this is what the compilers I have access
to (VC++, g++ and Sun CC) do.  But according to the standard, it should be
"<tt>0X**1Y2Z</tt>":
</p>

<p>
21.4.8.9 [string.io]/5: 
</p>

<blockquote><pre>
template&lt;class charT, class traits, class Allocator&gt;
  basic_ostream&lt;charT, traits&gt;&amp;
    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
</pre><blockquote><p>
<i>Effects:</i> Behaves as a formatted output function (27.7.3.6.1 [ostream.formatted.reqmts]). After constructing 
a <tt>sentry</tt> object, if this object returns <tt>true</tt> when converted to a value of type <tt>bool</tt>, 
determines padding as described in 22.4.2.2.2 [facet.num.put.virtuals], then inserts the resulting sequence of
characters seq as if by calling <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where <tt>n</tt> is the larger of 
<tt>os.width()</tt> and <tt>str.size()</tt>; then calls <tt>os.width(0)</tt>.
</p></blockquote>
</blockquote>

<p>
22.4.2.2.2 [facet.num.put.virtuals]/5: 
</p>

<blockquote>
<p>
[...] 
</p>

<p>
<b>Stage 3:</b> A local variable is initialized as
</p>

<blockquote><pre>
fmtflags adjustfield= (flags &amp; (ios_base::adjustfield));
</pre></blockquote>

<p>
The location of any padding is determined according to Table 88. 
</p>

<p>
If <tt>str.width()</tt> is nonzero and the number of <tt>charT</tt>'s in the
sequence after stage 2 is less than <tt>str.width()</tt>, then enough fill
characters are added to the sequence at the position indicated for padding to
bring the length of the sequence to <tt>str.width()</tt>. <tt>str.width(0)</tt>
is called.
</p>

<table border="1">
<caption>Table 88 &mdash; Fill padding</caption>
<tr>
<th>State</th>
<th>Location</th>
</tr>

<tr>
<td><tt>adjustfield == ios_base::left</tt></td>
<td>pad after</td>
</tr>

<tr>
<td><tt>adjustfield == ios_base::right</tt></td>
<td>pad before</td>
</tr>

<tr>
<td><tt>adjustfield == internal</tt> and a sign occurs in the representation</td>
<td>pad after the sign</td>
</tr>

<tr>
<td><tt>adjustfield == internal</tt> and representation after stage 1 began with 0x or 0X</td>
<td>pad after x or X</td>
</tr>

<tr>
<td><i>otherwise</i></td>
<td>pad before</td>
</tr>
</table>

</blockquote>

<p>
Although it's not 100% clear what "the sequence after stage 2" should mean here,
when there is no stage 2, the only reasonable assumption is that it is the
contents of the string being output.  In the above code, the string being output
is "<tt>0X1Y2Z</tt>", which starts with "<tt>0X</tt>", so the padding should be
inserted "after x or X", and not before the string. I believe that this is a
defect in the standard, and not in the three compilers I tried.
</p>

<p><i>[
2010 Batavia (post meeting session)
]</i></p>

<p>
Consensus that all known implementations are consistent, and disagree with the
standard. Preference is to fix the standard before implementations start trying
to conform to the current spec, as the current implementations have the preferred
form. Howard volunteered to drught for Madrid, move to Open.
</p>

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


<p>
Daniel Kr&uuml;gler volunteered to provide wording, interacting with Dietmar and
Bill. 
</p>



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





<hr>
<h3><a name="2012"></a>2012. Associative maps should insert <tt>pair</tt>, not <tt>tuple</tt></h3>
<p><b>Section:</b> 23.4 [associative] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2010-10-29 <b>Last modified:</b> 2011-03-24</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I'm seeing something strange in the paragraphs 23.4.4.4 [map.modifiers] and 23.4.5.3 [multimap.modifiers]:
they both talk about <tt>tuple&lt;const key_type, mapped_type&gt;</tt> but I think they
should be talking about <tt>pair&lt;const key_type, mapped_type&gt;</tt> because, among
other reasons, a <tt>tuple</tt> is not convertible to a <tt>pair</tt>. If I replace <tt>tuple</tt>
with <tt>pair</tt> everything makes sense to me.
<p/>
The proposed resolution is obvious. 
</p>

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


<p>
This is by far not the only necessary fix within both sub-clauses. For details see the 2010-10-29 comment in 
<a href="lwg-active.html#2005">2005</a>.
</p>

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


<p>
Paolo: Don't think we can do it now.
<p/>
Daniel K: Agrees. 
</p>


<p><b>Proposed resolution:</b></p>
<p>
Apply the resolution proposed by the 2010-10-29 comment in <a href="lwg-active.html#2005">2005</a>.
</p>





<hr>
<h3><a name="2013"></a>2013. Do library implementers have the freedom to add <tt>constexpr</tt>?</h3>
<p><b>Section:</b> 17.6.5.6 [constexpr.functions] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2010-11-12 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>Suppose that a particular function is not tagged as constexpr in the standard,
but that, in some particular implementation, it is possible to write it within
the constexpr constraints. If an implementer tags such a function as constexpr,
is that a violation of the standard or is it a conforming extension?</p>

<p>There are two questions to consider. First, is this allowed under the
as-if rule? Second, if it does not fall under as-if, is there
(and should there be) any special license granted to implementers
to do this anyway, sort of the way we allow elision of copy constructors
even though it is detectable by users?</p>

<p>I believe that this does not fall under "as-if", so implementers
probably don't have that freedom today. I suggest changing the WP
to grant it. Even if we decide otherwise, however, I suggest that
we make it explicit.</p>



<p><b>Proposed resolution:</b></p>
<p><i>In 17.6.4.6 [constexpr.functions], change paragraph 1 to:</i></p>

<blockquote><p>
<ins>This standard explicitly requires that certain standard library functions
are <tt>constexpr</tt> [dcl.constexpr].
Additionally, an implementation may declare any function to be <tt>constexpr</tt>
if that function's definition satisfies the necessary constraints.</ins>
Within any header that provides any non-defining declarations of <tt>constexpr</tt>
functions or constructors an implementation shall provide corresponding definitions. 
</p></blockquote>






<hr>
<h3><a name="2014"></a>2014. More restrictions on macro names</h3>
<p><b>Section:</b> 17.6.4.3.1 [macro.names] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2010-11-16 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#macro.names">issues</a> in [macro.names].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>
A program is currently forbidden to use keywords as macro names. This restriction should be strengthened to include all identifiers 
that could be used by the library as attribute-tokens (for example <tt>noreturn</tt>, which is used by header <tt>&lt;cstdlib&gt;</tt>) 
and the special identifiers introduced recently for override control (these are not currently used in the library public interface,
but could potentially be used by the implementation or in future revisions of the library).
</p>
<p><i>[2011-02-10 Reflector discussion]</i></p>

<p>
Moved to Tentatively Ready after 5 votes.
</p>


<p><b>Proposed resolution:</b></p>
<p>Modify 17.6.4.3.1 [macro.names] paragraph 2 as follows:</p>

<blockquote><p>
A translation unit shall not <tt>#define</tt> or <tt>#undef</tt> names
lexically identical to keywords<ins>, to the identifiers listed in Table
X [Identifiers with special meaning], or to the <i>attribute-tokens</i>
described in clause 7.6 [dcl.attr]</ins>.
</p></blockquote>






<hr>
<h3><a name="2015"></a>2015. Incorrect pre-conditions for some type traits</h3>
<p><b>Section:</b> 20.9.4 [meta.unary] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2010-11-08 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary">issues</a> in [meta.unary].</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 N3126&nbsp;&#x2011;&nbsp;3.9/9,</p>

<p>&quot;Scalar types, trivial class types (Clause 9), arrays of such types
and <i>cv</i>&#x2011;qualified versions of these types (3.9.3) are collectively
called <i>trivial types</i>.&quot;</p>

<p>Thus, an array (possibly of unknown bound) can be trivial type, non&#x2011;trivial type, 
or an array type whose triviality cannot be determined because its element type is incomplete.</p>

<p>According to N3126&nbsp;&#x2011;&nbsp;Table 45, preconditions for <tt>std::is_trivial</tt> are
defined as follows:</p>

<p>&quot;<tt>T</tt> shall be a complete type, (possibly <i>cv</i>-qualified) <tt>void</tt>, 
or an array of unknown bound&quot;</p>

<p>It seems that &quot;an array of unknown bound&quot; should be changed to &quot;an
array of unknown bound of a complete element type&quot;. Preconditions for
some other templates (e.g., <tt>std::is_trivially_copyable</tt>,
<tt>std::is_standard_layout</tt>, <tt>std::is_pod</tt>, and <tt>std::is_literal_type</tt>) should
be changed similarly.</p>

<p>On the other hand, some preconditions look too restrictive. For
example, <tt>std::is_empty</tt> and <tt>std::is_polymorphic</tt> might accept any
incomplete non&#x2011;class type.</p>

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


<p>
While reviewing the individual preconditions I could find three different groups of
either too weakening or too strengthening constraints:
</p>
<ol>
<li><pre>is_empty/is_polymorphic/is_abstract/has_virtual_destructor:</pre>

<p>These traits can only apply for <em>non&#x2011;union class types</em>, otherwise the result must
always be false</p>
</li>

<li><pre>is_base_of:</pre>

<p>Similar to the previous bullet, but the current wording comes already near to that ideal,
it only misses to add the <em>non&#x2011;union</em> aspect.</p>
</li>

<li><pre>is_trivial/is_trivially_copyable/is_standard_layout/is_pod/is_literal_type:</pre>

<p>These traits always require that <tt>std::remove_all_extents&lt;T&gt;::type</tt> to be <tt><i>cv</i> void</tt> or 
a complete type.</p>
</li>
</ol>


<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Modify the pre-conditions of the following type traits in 20.9.4.3 [meta.unary.prop], Table 48 &mdash; Type property predicates:
</p>

<blockquote>
<table border="1">
<caption>Table 48 &mdash; Type property predicates</caption>
<tr>
<th>Template</th>
<th>Condition</th>
<th>Preconditions</th>
</tr>

<tr>
<td colspan="3" style="text-align:center;">...</td>
</tr>

<tr>
<td><tt>template &lt;class T&gt;<br/>
struct is_trivial;</tt></td>
<td><tt>T</tt> is a trivial type (3.9)</td>
<td><tt><ins>remove_all_extents&lt;</ins>T<ins>&gt;::type</ins></tt><br/>
shall be a complete type<del>,</del><ins> or</ins> (possibly<br/>
cv-qualified) <tt>void</tt><del>, or an array of<br/>
unknown bound</del>.</td>
</tr>

<tr>
<td><tt>template &lt;class T&gt;<br/>
struct is_trivially_copyable;</tt></td>
<td><tt>T</tt> is a trivially copyable<br/>
type (3.9)</td>
<td><tt><ins>remove_all_extents&lt;</ins>T<ins>&gt;::type</ins></tt><br/>
shall be a complete type<del>,</del><ins> or</ins> (possibly<br/>
cv-qualified) <tt>void</tt><del>, or an array of<br/>
unknown bound</del>.</td>
</tr>

<tr>
<td><tt>template &lt;class T&gt;<br/>
struct is_standard_layout;</tt></td>
<td><tt>T</tt> is a standard-layout<br/>
type (3.9)</td>
<td><tt><ins>remove_all_extents&lt;</ins>T<ins>&gt;::type</ins></tt><br/>
shall be a complete type<del>,</del><ins> or</ins> (possibly<br/>
cv-qualified) <tt>void</tt><del>, or an array of<br/>
unknown bound</del>.</td>
</tr>

<tr>
<td><tt>template &lt;class T&gt;<br/>
struct is_pod;</tt></td>
<td><tt>T</tt> is a POD type (3.9)</td>
<td><tt><ins>remove_all_extents&lt;</ins>T<ins>&gt;::type</ins></tt><br/>
shall be a complete type<del>,</del><ins> or</ins> (possibly<br/>
cv-qualified) <tt>void</tt><del>, or an array of<br/>
unknown bound</del>.</td>
</tr>

<tr>
<td><tt>template &lt;class T&gt;<br/>
struct is_literal_type;</tt></td>
<td><tt>T</tt> is a literal type (3.9)</td>
<td><tt><ins>remove_all_extents&lt;</ins>T<ins>&gt;::type</ins></tt><br/>
shall be a complete type<del>,</del><ins> or</ins> (possibly<br/>
cv-qualified) <tt>void</tt><del>, or an array of<br/>
unknown bound</del>.</td>
</tr>

<tr>
<td><tt>template &lt;class T&gt;<br/>
struct is_empty;</tt></td>
<td><tt>T</tt> is a class type, but not a<br/>
union type, with no<br/>
non-static data members<br/>
other than bit-fields of<br/>
length 0, no virtual<br/>
member functions, no<br/>
virtual base classes, and<br/>
no base class B for which<br/>
<tt>is_empty&lt;B&gt;::value</tt> is<br/>
false.</td>
<td><del><tt>T</tt> shall be a complete type,<br/>
(possibly cv-qualified) <tt>void</tt>, or<br/>
an array of unknown bound</del><ins>If <tt>T</tt><br/>
is a non&#x2011;union class type, <tt>T</tt><br/>
shall be a complete type</ins>.</td>
</tr>

<tr>
<td><tt>template &lt;class T&gt;<br/>
struct is_polymorphic;</tt></td>
<td><tt>T</tt> is a polymorphic<br/>
class (10.3)</td>
<td><del><tt>T</tt> shall be a complete type,<br/>
type, (possibly cv-qualified) <tt>void</tt>, or<br/>
an array of unknown bound</del><ins>If <tt>T</tt><br/>
is a non&#x2011;union class type, <tt>T</tt><br/>
shall be a complete type</ins>.</td>
</tr>

<tr>
<td><tt>template &lt;class T&gt;<br/>
struct is_abstract;</tt></td>
<td><tt>T</tt> is an abstract<br/>
class (10.4)</td>
<td><del><tt>T</tt> shall be a complete type,<br/>
type, (possibly cv-qualified) <tt>void</tt>, or<br/>
an array of unknown bound</del><ins>If <tt>T</tt><br/>
is a non&#x2011;union class type, <tt>T</tt><br/>
shall be a complete type</ins>.</td>
</tr>

<tr>
<td colspan="3" style="text-align:center;">...</td>
</tr>

<tr>
<td><tt>template &lt;class T&gt;<br/>
struct has_virtual_destructor;</tt></td>
<td><tt>T</tt> has a virtual<br/>
destructor (12.4)</td>
<td><del><tt>T</tt> shall be a complete type,<br/>
(possibly cv-qualified) <tt>void</tt>, or<br/>
an array of unknown bound</del><ins>If <tt>T</tt><br/>
is a non&#x2011;union class type, <tt>T</tt><br/>
shall be a complete type</ins>.</td>
</tr>

</table>
</blockquote>

</li>

<li>
<p>
Modify the pre-conditions of the following type traits in 20.9.6 [meta.rel], Table 50 &mdash; Type relationship predicates:
</p>

<blockquote>
<table border="1">
<caption>Table 50 &mdash; Type relationship predicates</caption>
<tr>
<th>Template</th>
<th>Condition</th>
<th>Comments</th>
</tr>

<tr>
<td colspan="3" style="text-align:center;">...</td>
</tr>

<tr>
<td><tt>template &lt;class Base, class<br/>
Derived&gt;<br/>
struct is_base_of;</tt></td>
<td><tt>Base</tt> is a base class of<br/>
<tt>Derived</tt> (10) without<br/>
regard to cv-qualifiers<br/>
or <tt>Base</tt> and <tt>Derived</tt><br/>
are not unions and<br/>
name the same class<br/>
type without regard to<br/>
cv-qualifiers</td>
<td>If <tt>Base</tt> and <tt>Derived</tt> are<br/>
<ins>non&#x2011;union</ins> class types<br/>
and are different types<br/>
(ignoring possible cv-qualifiers)<br/>
then <tt>Derived</tt> shall be a complete<br/>
type. [ <i>Note</i>: Base classes that<br/>
are private, protected, or<br/>
ambigious are, nonetheless, base<br/>
classes. &mdash; <i>end note</i> ]</td>
</tr>

<tr>
<td colspan="3" style="text-align:center;">...</td>
</tr>

</table>
</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#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2010-11-17 <b>Last modified:</b> 2011-03-24</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>
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><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]). 
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> object<del>s</del> 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 using <ins>a</ins> <del>an unqualified call to non-member</del> 
<tt>swap</tt> <ins>call</ins> <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="2017"></a>2017. <tt>std::reference_wrapper</tt> makes incorrect usage of <tt>std::result_of</tt></h3>
<p><b>Section:</b> 20.8.3 [refwrap] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2010-11-15 <b>Last modified:</b> 2011-03-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#refwrap">active issues</a> in [refwrap].</p>
<p><b>View all other</b> <a href="lwg-index.html#refwrap">issues</a> in [refwrap].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>std::reference_wrapper</tt>'s function call operator uses <em>wrong</em>
type encoding for rvalue-arguments. An rvalue-argument of type <tt>T</tt> must
be encoded as <tt>T&amp;&amp;</tt>, not as just <tt>T</tt>.
</p>
<blockquote><pre>
#include &lt;functional&gt;
#include &lt;iostream&gt;
#include &lt;string&gt;
#include &lt;type_traits&gt;
#include &lt;utility&gt;

template &lt;class F, class... Types&gt;
     typename std::result_of&lt;F (Types...)&gt;::type
         f1(F f, Types&amp;&amp;... params)
{
     return f(std::forward&lt;Types...&gt;(params...));
}

template &lt;class F, class... Types&gt;
     typename std::result_of&lt;F (Types<b>&amp;&amp;</b>...)&gt;::type
         f2(F f, Types&amp;&amp;... params)
{
     return f(std::forward&lt;Types...&gt;(params...));
}

struct Functor
{
     template &lt;class T&gt;
         T&amp;&amp; operator()(T&amp;&amp; t) const
     {
         return static_cast&lt;T&amp;&amp;&gt;(t);
     }
};

int main()
{
     typedef std::string const Str;
     std::cout &lt;&lt; f1(Functor(), Str("1")) &lt;&lt; std::endl; // (1)
     std::cout &lt;&lt; f2(Functor(), Str("2")) &lt;&lt; std::endl; // (2)
}
</pre></blockquote>
<p>
Lets consider the function template <tt>f1</tt> (which is similar to
<tt>std::reference_wrapper</tt>'s function call operator). In the invocation
(1) <tt>F</tt> is deduced as '<tt>Functor</tt>' and <tt>Types</tt> is deduced as type sequence
which consists of one type '<tt>std::string const</tt>'. After the substitution
we have the following equivalent:
</p>
<blockquote><pre>
template &lt;&gt;
    std::result_of&lt;F (std::string const)&gt;::type
        f1&lt;Functor, std::string const&gt;(Functor f, std::string const &amp;&amp; params)
{
    return f(std::forward&lt;const std::string&gt;(params));
}
</pre></blockquote>
<p>
The top-level <i>cv</i>-qualifier in the parameter type of '<tt>F (std::string const)</tt>' is removed, so we have
</p>
<blockquote><pre>
template &lt;&gt;
    std::result_of&lt;F (std::string)&gt;::type
        f1&lt;Functor, std::string const&gt;(Functor f, std::string const &amp;&amp; params)
{
    return f(std::forward&lt;const std::string&gt;(params));
}
</pre></blockquote>
<p>
Let <tt>r</tt> be an rvalue of type '<tt>std::string</tt>' and <tt>cr</tt> be an rvalue of type
'<tt>std::string const</tt>'. The expression <tt>Str("1")</tt> is <tt>cr</tt>. The corresponding
return type for the invocation
</p>
<blockquote><pre>
Functor().operator()(r)
</pre></blockquote>
<p>
is '<tt>std::string &amp;&amp;</tt>'. The corresponding return type for the invocation
</p>
<blockquote><pre>
Functor().operator()(cr)
</pre></blockquote>
<p>
is '<tt>std::string const &amp;&amp;</tt>'.
<p/>
<tt>std::result_of&lt;Functor (std::string)&gt;::type</tt> is the same type as the
corresponding return type for the invocation <tt>Functor().operator()(r)</tt>,
i.e. it is '<tt>std::string &amp;&amp;</tt>'. As a consequence, we have wrong reference
binding in the return statement in <tt>f1</tt>.
<p/>
Now lets consider the invocation (2) of the function template <tt>f2</tt>. When
the template arguments are substituted we have the following equivalent:
</p>
<blockquote><pre>
template &lt;&gt;
    std::result_of&lt;F (std::string const &amp;&amp;)&gt;::type
        f2&lt;Functor, std::string const&gt;(Functor f, std::string const &amp;&amp; params)
{
    return f(std::forward&lt;const std::string&gt;(params));
}
</pre></blockquote>
<p>
<tt>std::result_of&lt;F (std::string const &amp;&amp;)&gt;::type</tt> is the same type as
'<tt>std::string const &amp;&amp;</tt>'. This is correct result.
</p>
<p><i>[
2010-12-07 Jonathan Wakely comments and suggests a proposed resolution
]</i></p>


<p>
I agree with the analysis and I think this is a defect in the
standard, it would be a shame if it can't be fixed.
<p/>
In the following example one would expect <tt>f(Str("1"))</tt> and
<tt>std::ref(f)(Str("2"))</tt> to be equivalent but the current wording makes
the invocation through <tt>reference_wrapper</tt> ill-formed:
</p>
<blockquote><pre>
#include &lt;functional&gt;
#include &lt;string&gt;

struct Functor
{
   template &lt;class T&gt;
       T&amp;&amp; operator()(T&amp;&amp; t) const
       {
           return static_cast&lt;T&amp;&amp;&gt;(t);
       }
};

int main()
{
   typedef std::string const Str;
   Functor f;
   f( Str("1") );
   std::ref(f)( Str("2") );  // error
}
</pre></blockquote>

<p><i>[
2010-12-07 Daniel comments and refines the proposed resolution
]</i></p>


<p>
There is one further defect in the usage of <tt>result_of</tt> within
<tt>reference_wrapper</tt>'s function call operator: According to 20.8.3.4 [refwrap.invoke] p. 1
the invokable entity of type <tt>T</tt> is provided as lvalue, but 
<tt>result_of</tt> is fed as if it were an rvalue. This does not only lead to
potentially incorrect result types, but it will also have the effect that
we could never use the function call operator with a function type,
because the type encoding used in <tt>result_of</tt> would form an invalid
function type return a function type. The following program demonstrates
this problem:
</p>
<blockquote><pre>
#include &lt;functional&gt;

void foo(int) {}

int main()
{
   std::ref(foo)(0);  // error
}
</pre></blockquote><p>
The correct solution is to ensure that <tt>T</tt> becomes <tt>T&amp;</tt>
within <tt>result_of</tt>, which solves both problems at once.
</p>

<p><i>[2011-02-24 Reflector discussion]</i></p>

<p>
Moved to Tentatively Ready after 5 votes.
</p> 


<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Change the synopsis in 20.8.3 [refwrap] paragraph 1:
</p>

<blockquote><pre>
namespace std {
  template &lt;class T&gt; class reference_wrapper
  {
  public :
    [...]
    // invocation
    template &lt;class... ArgTypes&gt;
    typename result_of&lt;T<ins>&amp;</ins>(ArgTypes<ins>&amp;&amp;</ins>...)&gt;::type
    operator() (ArgTypes&amp;&amp;...) const;
  };
}
</pre></blockquote>
</li>

<li>
<p>
Change the signature in 20.8.3.4 [refwrap.invoke] before paragraph 1
</p>

<blockquote><pre>
template &lt;class... ArgTypes&gt;
typename result_of&lt;T<ins>&amp;</ins>(ArgTypes<ins>&amp;&amp;</ins>... )&gt;::type
operator()(ArgTypes&amp;&amp;... args) const;
</pre><blockquote><p>
1 <i>Returns</i>: <tt>INVOKE(get(), std::forward&lt;ArgTypes&gt;(args)...)</tt>. (20.8.2)
</p></blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="2018"></a>2018. <tt>regex_traits::isctype</tt> Returns clause is wrong</h3>
<p><b>Section:</b> 28.7 [re.traits] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2010-11-16 <b>Last modified:</b> 2011-03-24</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>28.7 [re.traits] p. 12 says:</p>

<blockquote><p>
returns true if <tt>f</tt> bitwise or&#39;ed with the result of calling
<tt>lookup_classname</tt> with an iterator pair that designates the character
sequence &quot;w&quot; is not equal to <tt>0</tt> and <tt>c == '_'</tt>
</p></blockquote>

<p>
If the bitmask value corresponding to &quot;w&quot; has a non-zero value (which
it must do) then the bitwise or with any value is also non-zero, and
so <tt>isctype('_', f)</tt> returns true for any <tt>f</tt>. Obviously this is wrong,
since <tt>'_'</tt> is not in every <tt>ctype</tt> category.
</p>

<p>
There&#39;s a similar problem with the following phrases discussing the
&quot;blank&quot; char class.
</p>


<p><b>Proposed resolution:</b></p>
<p>Replace the Returns clause with a description in terms of <tt>ctype</tt>
categories, rather than pseudocode in terms of bitwise operations.
(full replacement wording to follow)
</p>





<hr>
<h3><a name="2019"></a>2019. <tt>isblank</tt> not supported by <tt>std::locale</tt></h3>
<p><b>Section:</b> 22.3.3.1 [classification] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2010-11-16 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>C99 added <tt>isblank</tt> and <tt>iswblank</tt> to <tt>&lt;locale.h&gt;</tt> but <tt>&lt;locale&gt;</tt> does not
provide any equivalent.</p>

<p><i>[2011-02-24 Reflector discussion]</i></p>

<p>
Moved to Tentatively Ready after 6 votes.
</p> 


<p><b>Proposed resolution:</b></p>
<p>Add to 22.3.3.1 [classification] synopsis:</p>
<blockquote><pre>
template &lt;class charT&gt; bool isgraph (charT c, const locale&amp; loc);
<ins>template &lt;class charT&gt; bool isblank (charT c, const locale&amp; loc);</ins>
</pre></blockquote>

<p>Add to 22.4.1 [category.ctype] synopsis:</p>

<blockquote><pre>
static const mask xdigit = 1 &lt;&lt; 8;
<ins>static const mask blank = 1 &lt;&lt; 9;</ins>
static const mask alnum = alpha | digit;
static const mask graph = alnum | punct;
</pre></blockquote>






<hr>
<h3><a name="2020"></a>2020. Time utility arithmetic <tt>constexpr</tt> functions have invalid effects</h3>
<p><b>Section:</b> 20.11.5.5 [time.duration.nonmember] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2010-12-06 <b>Last modified:</b> 2011-03-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#time.duration.nonmember">active issues</a> in [time.duration.nonmember].</p>
<p><b>View all other</b> <a href="lwg-index.html#time.duration.nonmember">issues</a> in [time.duration.nonmember].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As of issue <a href="lwg-defects.html#1171">1171</a> several time-utility functions have been marked <tt>constexpr</tt>.
Alas this was done without adapting the corresponding return elements, which has the effect that 
none of current arithmetic functions of class template <tt>duration</tt> marked as <tt>constexpr</tt> 
can ever be <tt>constexpr</tt> functions (which makes them ill-formed, no diagnostics required as 
of recent core rules), because they invoke a non-constant expression, e.g. 20.11.5.5 [time.duration.nonmember]/2:
</p>
<blockquote><pre>
template &lt;class Rep1, class Period1, class Rep2, class Period2>
constexpr typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;{&gt;}::type
operator+(const duration&lt;Rep1, Period1>&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);

2 Returns: CD(lhs) += rhs.
</pre></blockquote>
<p>
The real problem is, that we cannot defer to as-if rules here: The returns element
specifies an indirect calling contract of a potentially user-defined function. This <em>cannot</em> be
the <tt>+=</tt> assignment operator of such a user-defined type, but must be the corresponding
immutable binary <tt>operator+</tt> (unless we require that <tt>+=</tt> shall be an immutable function
which does not really makes sense).
</p>
<p><i>[2011-02-17 Reflector discussion]</i></p>

<p>
Moved to Tentatively Ready after 5 votes.
</p>



<p><b>Proposed resolution:</b></p>
<p>
The suggested wording changes are against the working draft N3242. Additional to the normative wording
changes some editorial fixes are suggested.
</p>
<ol>
<li>
<p>In 20.11.5.5 [time.duration.nonmember], change the following arithmetic function specifications as follows:</p>
<blockquote><pre>
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
constexpr typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;<del>{</del>&gt;<del>}</del>::type
operator+(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
</pre><blockquote><p>
2 <i>Returns</i>: <del><tt>CD(lhs) += rhs</tt></del><ins><tt>CD(CD(lhs).count() + CD(rhs).count())</tt></ins>.
</p></blockquote></blockquote>

<blockquote><pre>
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
constexpr typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;<del>{</del>&gt;<del>}</del>::type
operator-(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
</pre><blockquote><p>
3 <i>Returns</i>: <del><tt>CD(lhs) -= rhs</tt></del><ins><tt>CD(CD(lhs).count() - CD(rhs).count())</tt></ins>.
</p></blockquote></blockquote>

<blockquote><pre>
template &lt;class Rep1, class Period, class Rep2&gt;
constexpr duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre><blockquote><p>
4 <i>Remarks</i>: This operator shall not participate in overload resolution unless <tt>Rep2</tt> is implicitly convertible
to <tt>CR(Rep1, Rep2)</tt>.
<p/>
5 <i>Returns</i>: <del><tt>duration&lt;CR(Rep1, Rep2), Period&gt;(d) *= s</tt></del><ins><tt>CD(CD(d).count() * s)</tt></ins>.
</p></blockquote></blockquote>

<blockquote><p>
<tt>[...]</tt>
</p></blockquote>

<blockquote><pre>
template &lt;class Rep1, class Period, class Rep2&gt;
constexpr duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre><blockquote><p>
8 <i>Remarks</i>: This operator shall not participate in overload resolution unless <tt>Rep2</tt> is implicitly convertible
to <tt>CR(Rep1, Rep2)</tt> and <tt>Rep2</tt> is not an instantiation of <tt>duration</tt>.
<p/>
9 <i>Returns</i>: <del><tt>duration&lt;CR(Rep1, Rep2), Period&gt;(d) &#47;= s</tt></del><ins><tt>CD(CD(d).count() &#47; s)</tt></ins>.
</p></blockquote></blockquote>

<blockquote><p>
<tt>[...]</tt>
</p></blockquote>

<blockquote><pre>
template &lt;class Rep1, class Period, class Rep2&gt;
constexpr duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre><blockquote><p>
11 <i>Remarks</i>: This operator shall not participate in overload resolution unless <tt>Rep2</tt> is implicitly convertible
to <tt>CR(Rep1, Rep2)</tt> and <tt>Rep2</tt> is not an instantiation of <tt>duration</tt>.
<p/>
12 <i>Returns</i>: <del><tt>duration&lt;CR(Rep1, Rep2), Period&gt;(d) %= s</tt></del><ins><tt>CD(CD(d).count() % s)</tt></ins>
</p></blockquote></blockquote>

<blockquote><pre>
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
constexpr typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
operator%(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
</pre><blockquote><p>
13 Returns: <del><tt>common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt; &gt;::type(lhs) 
 %= rhs</tt></del><ins><tt>CD(CD(lhs).count() % CD(rhs).count())</tt></ins>.
</p></blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="2021"></a>2021. Further incorrect usages of <tt>result_of</tt></h3>
<p><b>Section:</b> 20.8.9.1.2 [func.bind.bind], 30.6.1 [futures.overview], 30.6.8 [futures.async] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2010-12-07 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Issue <a href="lwg-active.html#2017">2017</a> points out some incorrect usages of <tt>result_of</tt> in the
declaration of the function call operator overload of <tt>reference_wrapper</tt>,
but there are more such specification defects:
</p>
<ol>
<li>According to 20.8.9.1.2 [func.bind.bind] p. 3: 
<blockquote><p>
[..] The effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt>INVOKE(fd, v1, v2, ..., vN, result_of&lt;FD cv (V1, V2, ..., VN)&gt;::type)</tt> [..]
</p></blockquote>
<p>
but <tt>fd</tt> is defined as &quot;an lvalue of type <tt>FD</tt> constructed from <tt>std::forward&lt;F&gt;(f)</tt>&quot;. This means that
the above usage must refer to <tt>result_of&lt;FD cv <strong>&amp;</strong> (V1, V2, ..., VN)&gt;</tt> instead.
</p>
</li>
<li><p>
Similar in 20.8.9.1.2 [func.bind.bind] p. 10 bullet 2 we have:
</p>
<blockquote><p>
if the value of <tt>is_bind_expression&lt;TiD&gt;::value</tt> is true, the argument is <tt>tid(std::forward&lt;Uj&gt;(uj)...)</tt>
and its type <tt>Vi</tt> is <tt>result_of&lt;TiD cv (Uj...)&gt;::type</tt>
</p></blockquote>
<p>
Again, <tt>tid</tt> is defined as &quot;lvalue of type <tt>TiD</tt> constructed from <tt>std::forward&lt;Ti&gt;(ti)</tt>&quot;. This means that
the above usage must refer to <tt>result_of&lt;TiD cv <strong>&amp;</strong> (Uj...)&gt;</tt> instead. We also have similar defect as in
<a href="lwg-active.html#2017">2017</a> in regard to the argument types, this leads us to the further corrected form 
<tt>result_of&lt;TiD cv <strong>&amp;</strong> (Uj<strong>&amp;&amp;</strong>...)&gt;</tt>. This is not the end: Since the <tt>Vi</tt>
are similar sensitive to the argument problem, the last part must say: 
<p/>
&quot;[..] its type <tt>Vi</tt> is <tt>result_of&lt;TiD cv <strong>&amp;</strong> (Uj<strong>&amp;&amp;</strong>...)&gt;::type <strong>&amp;&amp;</strong>&quot;</tt>
<p/>
(The bound arguments <tt>Vi</tt> can never be <tt>void</tt> types, therefore we don't need 
to use the more defensive <tt>std::add_rvalue_reference</tt> type trait)
</p>
</li>
<li><p>The function template <tt>async</tt> is declared as follows (the other overload has the same problem):</p>
<blockquote><pre>
template &lt;class F, class... Args&gt;
future&lt;typename result_of&lt;F(Args...)&gt;::type&gt;
async(F&amp;&amp; f, Args&amp;&amp;... args);
</pre></blockquote><p>
This usage has the some same problems as we have found in <tt>reference_wrapper</tt> (<a href="lwg-active.html#2017">2017</a>) and more: According to
the specification in 30.6.8 [futures.async] the effective result type is that of the call of
</p><blockquote><pre>
INVOKE(decay_copy(std::forward&lt;F&gt;(f)), decay_copy(std::forward&lt;Args&gt;(args))...)
</pre></blockquote><p>
First, <tt>decay_copy</tt> potentially modifies the effective types to <tt>decay&lt;F&gt;::type</tt> and <tt>decay&lt;Args&gt;::type...</tt>.
Second, the current specification is not really clear, what the value category of callable type or the arguments shall be: According
to the second bullet of 30.6.8 [futures.async] p. 3:
</p>
<blockquote><p>
Invocation of the deferred function evaluates <tt>INVOKE(g, xyz)</tt> where <tt>g</tt> is the stored value of 
<tt>decay_copy(std::forward&lt;F&gt;(f))</tt> and <tt>xyz</tt> is the stored copy of 
<tt>decay_copy(std::forward&lt;Args&gt;(args))...</tt>.
</p></blockquote><p>
This seems to imply that lvalues are provided in contrast to the direct call expression of 30.6.8 [futures.async] p. 2
which implies rvalues instead. The specification needs to be clarified.
</p>
</li>
</ol>


<p><b>Proposed resolution:</b></p>
<p>
The suggested wording changes are against the working draft N3242.
</p>
<ol>
<li>
<p>Change 20.8.9.1.2 [func.bind.bind] p. 3 as indicated:</p>

<blockquote><p>
<i>Returns</i>: A forwarding call wrapper <tt>g</tt> with a weak result type (20.8.2). The effect of 
<tt>g(u1, u2, ..., uM)</tt> shall be <tt>INVOKE(fd, v1, v2, ..., vN, result_of&lt;FD cv <ins>&amp;</ins> (V1, V2, ..., VN)&gt;::type)</tt>, 
where <i>cv</i> represents the <i>cv</i>-qualifiers of <tt>g</tt> and the values and types of the bound arguments 
<tt>v1, v2, ..., vN</tt> are determined as specified below. [..]
</p></blockquote>

</li>

<li>
<p>Change 20.8.9.1.2 [func.bind.bind] p. 10 bullet 2 as indicated:</p>

<blockquote><p>
if the value of <tt>is_bind_expression&lt;TiD&gt;::value</tt> is <tt>true</tt>, the argument is 
<tt>tid(std::forward&lt;Uj&gt;(uj)...)</tt> and its type <tt>Vi</tt> is 
<tt>result_of&lt;TiD cv <ins>&amp;</ins> (Uj<ins>&amp;&amp;</ins>...)&gt;::type<ins>&amp;&amp;</ins></tt>;
</p></blockquote>

</li>

<li>
<p>
This resolution assumes that the wording of 30.6.8 [futures.async] is incorrectly implying rvalues
as arguments of <tt>INVOKE</tt>, those should be lvalues instead.
</p>

<p>
Change the function signatures in header <tt>&lt;future&gt;</tt> synopsis 30.6.1 [futures.overview] p. 1
and in 30.6.8 [futures.async] p. 1 as indicated:
</p>

<blockquote><pre>
template &lt;class F, class... Args&gt;
future&lt;typename result_of&lt;<ins>typename decay&lt;</ins>F<ins>&gt;::type&amp;</ins>(<ins>typename decay&lt;</ins>Args<ins>&gt;::type&amp;</ins>...)&gt;::type&gt;
async(F&amp;&amp; f, Args&amp;&amp;... args);
template &lt;class F, class... Args>
future&lt;typename result_of&lt;<ins>typename decay&lt;</ins>F<ins>&gt;::type&amp;</ins>(<ins>typename decay&lt;</ins>Args<ins>&gt;::type&amp;</ins>...)&gt;::type&gt;
async(launch policy, F&amp;&amp; f, Args&amp;&amp;... args);
</pre></blockquote>
</li>

<li>
<p>Change 30.6.8 [futures.async] p. 4 as indicated: [Note: There is one tiny editorial correction that completes one
<tt>::</tt> scope specifier]
[Note: This sub-section need more wording: The call expressions used imply a different value category]
</p>

<blockquote><p>
<i>Returns</i>: an object of type 
<tt>future&lt;typename result_of&lt;<ins>typename decay&lt;</ins>F<ins>&gt;::type&amp;</ins>(<ins>typename decay&lt;</ins>Args<ins>&gt;::type&amp;</ins>...)&gt;:<ins>:</ins>type&gt;</tt> 
that refers to the associated asynchronous state created by this call to <tt>async</tt>.
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="2022"></a>2022. <tt>reference_wrapper&lt;T&gt;::result_type</tt> is underspecified</h3>
<p><b>Section:</b> 20.8.3 [refwrap] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2010-12-08 <b>Last modified:</b> 2011-03-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#refwrap">active issues</a> in [refwrap].</p>
<p><b>View all other</b> <a href="lwg-index.html#refwrap">issues</a> in [refwrap].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Issue <a href="lwg-defects.html#1295">1295</a> correctly removed function types and references to function types from the
bullet 1 of 20.8.2 [func.require] p. 3 because neither function types nor function references
satisfy the requirements for a target object which is <em>defined</em> to be an object of a callable 
type. This has the effect that the reference in 20.8.3 [refwrap] p. 2
</p>
<blockquote><p>
<tt>reference_wrapper</tt> has a weak result type (20.8.2).
</p></blockquote>
<p>
is insufficient as a reference to define the member type <tt>result_type</tt> when the template argument 
<tt>T</tt> is a function type.
<p/>
There are basically two approaches to solve the problem:
</p>
<ol>
<li><p>Extend the definition of a <i>weak result type</i> in 20.8.2 [func.require] p. 3 to both
function types and references thereof. This extension must be specified independend from the concept
of a call wrapper, though.</p>
</li>
<li><p>Add one extra sentence to 20.8.3 [refwrap] p. 2 that simply defines the member type
<tt>result_type</tt> for <tt>reference_wrapper&lt;T&gt;</tt>, when <tt>T</tt> is a function type.</p>
</li>
</ol>
<p>
I checked the current usages of <i>weak result type</i> to have a base to argue for one or the other
approach. It turns out, that there is no further reference to this definition in regard to
function types or references thereof. The only other reference can be found in 
20.8.9.1.2 [func.bind.bind] p. 3, where <tt>g</tt> is required to be a class type.
</p>

<p><i>[2011-02-23 Reflector discussion]</i></p>

<p>
Moved to Tentatively Ready after 5 votes.
</p> 


<p><b>Proposed resolution:</b></p>
<p>
The suggested wording changes are against the working draft N3242.
</p>

<ol>
<li>
<p>Change 20.8.3 [refwrap] p. 2 as indicated:</p>

<blockquote><p>
2 <tt>reference_wrapper<ins>&lt;T&gt;</ins></tt> has a weak result type (20.8.2). <ins>If <tt>T</tt> is a function type, 
<tt>result_type</tt> shall be a synonym for the return type of <tt>T</tt>.</ins>
</p></blockquote>

</li>

</ol>





<hr>
<h3><a name="2026"></a>2026. <tt>hash</tt> should be <tt>std</tt> qualified for unordered container</h3>
<p><b>Section:</b> 23.5 [unord] <b>Status:</b> <a href="lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2011-02-07 <b>Last modified:</b> 2011-03-24</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 NAD">Tentatively NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Tom Plum pointed out to me that there's an apparent inconsistency in the <tt>std::</tt> qualification of template names in the unordered containers:
</p>

<blockquote><pre>
 template &lt;class Key,
           class T,
           class Hash = hash&lt;Key&gt;,
           class Pred = std::equal_to&lt;Key&gt;,
           class Alloc = std::allocator&lt;std::pair&lt;const Key, T&gt; &gt; &gt;
   class unordered_map;
</pre></blockquote>

<p>
Is there a reason that hash is not qualified with <tt>std::</tt>? TR1 also
does not use <tt>std::</tt> here.
</p>

<p><i>[
2011-02-07 Chris Jefferson adds:
]</i></p>

<p>
I assumed (I might be wrong) it is because <tt>hash</tt> is designed to be a
customisation point, like <tt>swap</tt>.
</p>

<p><i>[
2011-02-07 Howard Hinnant adds:
]</i></p>

<p>I think this is incorrect.  We mean <tt>std::hash</tt>, though clients
are free to specialize <tt>std::hash</tt> on user-defined types.  With the
possible exception of <tt>begin</tt>/<tt>end</tt> (which I'm not sure if
we've settled that), <tt>swap</tt> is the only intended customization point (look up a function by ADL) in the <tt>std::</tt> lib.
</p>

<p><i>[
2011-02-24 Chris Jefferson adds:
]</i></p>

<p>I recommend NAD, due to 17.6.1.1 [contents] p3:</p>
<blockquote><p>
Whenever a name <tt>x</tt> defined in the standard library is mentioned, the name <tt>x</tt> is assumed to be fully qualified
as <tt>::std::x</tt>, unless explicitly described otherwise. For example, if the Effects section for library function <tt>F</tt>
is described as calling library function <tt>G</tt>, the function <tt>::std::G</tt> is meant.
</p></blockquote>

<p><i>[2011-02-25 Reflector discussion]</i></p>

<p>
Moved to Tentatively NAD after 5 votes.
</p> 


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





<hr>
<h3><a name="2027"></a>2027. Initialization of the stored task of a <tt>packaged_task</tt></h3>
<p><b>Section:</b> 30.6.9.1 [futures.task.members] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2011-02-09 <b>Last modified:</b> 2011-03-24</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#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Related with LWG issue <a href="lwg-active.html#1514">1514</a>.
</p>

<p>
The move constructor of <tt>packaged_task</tt> does not specify how the stored task is constructed. 
The obvious way is to move-construct it using the task stored in the argument. Moreover, the 
constructor should be provided with a throws clause similar to one used for the other constructors, 
as the move constructor of the stored task is not required to be nothrow.</p>

<p>
As for the other constructors, the terms "stores a copy of <tt>f</tt>" do not reflect the intent, which is 
to allow <tt>f</tt> to be moved when possible.
</p>

<p><i>[2011-02-25: Alberto updates wording]</i></p>


<p><i>[2011-02-26 Reflector discussion]</i></p>

<p>
Moved to Tentatively Ready after 5 votes.
</p> 


<p><b>Proposed resolution:</b></p>
<p>(wording written assuming LWG <a href="lwg-active.html#1514">1514</a> is also accepted)</p>

<ol>
<li>
<p>Change 30.6.9.1 [futures.task.members] paragraph 3:</p>

<blockquote><p>
3 <em>Effects</em>: constructs a new <tt>packaged_task</tt> object with an associated asynchronous state and <del>stores a
copy of <tt>f</tt> as the object's stored task</del><ins>initializes the object's stored task with <tt>std::forward&lt;F&gt;(f)</tt></ins>. 
The constructors that take an <tt>Allocator</tt> argument use it to allocate memory needed to store the internal data structures.
</p></blockquote>

</li>

<li>
<p>Change 30.6.9.1 [futures.task.members] paragraph 5:</p>

<blockquote><p>
5 <em>Effects</em>: constructs a new <tt>packaged_task</tt> object and transfers ownership of <tt>other</tt>'s associated asynchronous
state to <tt>*this</tt>, leaving <tt>other</tt> with no associated asynchronous state. <ins>Moves the stored task from <tt>other</tt> 
to <tt>*this</tt>.</ins>
</p></blockquote>

</li>

</ol>






<hr>
<h3><a name="2028"></a>2028. <tt>messages_base::catalog</tt> overspecified</h3>
<p><b>Section:</b> 22.4.7.1 [locale.messages] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2011-02-14 <b>Last modified:</b> 2011-03-24</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 22.4.7.1 [locale.messages], <tt>messages_base::catalog</tt> is specified to be a typedef to <tt>int</tt>.  
This type is subsequently used to open, access and close catalogs.
</p>

<p>
However, an OS may have catalog/messaging services that are indexed and managed by types other than <tt>int</tt>.  
For example <tt>POSIX</tt>, publishes the <a href="http://www.unix.org/single_unix_specification/">following messaging API</a>:
</p>

<blockquote><pre>
typedef <em>unspecified</em> nl_catd;

nl_catd catopen(const char* name , int oflag);
char*   catgets(nl_catd catd, int set_id, int msg_id, const char* s);
int     catclose(nl_catd catd);
</pre></blockquote>

<p>
I.e., the catalog is managed with an unspecified type, not necessarily an <tt>int</tt>.  
Mac OS uses a <tt>void*</tt> for <tt>nl_catd</tt> (which is conforming to the <tt>POSIX</tt> standard).  
The current <tt>messages_base</tt> spec effectively outlaws using the built-in OS messaging service 
supplied for this very purpose!
</p>

<p><i>[2011-02-24: Chris Jefferson updates the proposed wording, changing <i>unspecified</i> to <i>unspecified signed integral type</i>]</i></p>


<p><i>[2011-03-02: Daniel updates the proposed wording, changing <i>unspecified signed integral type</i> to
 <i>unspecified signed integer type</i> (We don't want to allow for <tt>bool</tt> or <tt>char</tt>)]</i></p>

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


<p>
Consensus that this resolution is the direction we would like to see.
</p>



<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>Modify 22.4.7.1 [locale.messages]:</p>

<blockquote><pre>
namespace std {
  class messages_base {
  public:
    typedef <del>int</del><ins><em>unspecified signed integer type</em></ins> catalog;
  };
  ...
}
</pre></blockquote>

</li>

</ol>






<hr>
<h3><a name="2029"></a>2029. Missing '<tt>noexcept</tt>' on <tt>basic_regex</tt> move-assignment operator</h3>
<p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-02-16 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#re.regex">issues</a> in [re.regex].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3149.html">N3149</a> replaced 
the "<tt>Throws: nothing</tt>" clause on <tt>basic_regex::assign(basic_regex&amp;&amp;)</tt> with 
the <tt>noexcept</tt> keyword. The effects of the move-assignment operator are defined in terms of 
the <tt>assign()</tt> function, so the "<tt>Throws: nothing</tt>" applied there too, and a
<tt>noexcept</tt>-specification should be added there too.
</p>

<p><i>[2011-02-24 Reflector discussion]</i></p>

<p>
Moved to Tentatively Ready after 7 votes.
</p> 


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

<ol>
<li>
<p>Modify the <tt>basic_regex</tt> synopsis in 28.8 [re.regex] p. 3:</p>

<blockquote><pre>
namespace std {
  template &lt;class charT,
            class traits = regex_traits&lt;charT&gt; &gt;
  class basic_regex {
  public:
    ...
    basic_regex&amp; operator=(const basic_regex&amp;);
    basic_regex&amp; operator=(basic_regex&amp;&amp;) <ins>noexcept</ins>;
    basic_regex&amp; operator=(const charT* ptr);
    ...
  };
}
</pre></blockquote>

</li>

<li>
<p>Modify 28.8.3 [re.regex.assign] p. 2:</p>

<blockquote><pre>
basic_regex&amp; operator=(basic_regex&amp;&amp; e) <ins>noexcept</ins>;
</pre>
<blockquote><p>
2 <em>Effects</em>: returns <tt>assign(std::move(e))</tt>.
</p></blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2030"></a>2030. <tt>packaged_task::result_type</tt> should be removed</h3>
<p><b>Section:</b> 30.6.9 [futures.task] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2010-11-12 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.task">issues</a> in [futures.task].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>packaged_task::operator()</tt> always returns <tt>void</tt>, regardless of the return
type of the wrapped task. However, <tt>packaged_task::result_type</tt> is a
typedef to the return type of the wrapped task. This is inconsistent
with other uses of <tt>result_type</tt> in the standard, where it matches the
return type of <tt>operator()</tt> (e.g. <tt>function</tt>, <tt>owner_less</tt>). This is confusing.
</p>

<p>
It also violates the TR1 <tt>result_of</tt> protocol, and thus makes
<tt>packaged_task</tt> harder to use with anything that respects that protocol.
</p>

<p>
Finally, it is of little use anyway.
</p>

<p><tt>packaged_task::result_type</tt> should therefore be removed.</p>

<p><i>[2011-02-24 Reflector discussion]</i></p>

<p>
Moved to Tentatively Ready after 5 votes.
</p> 


<p><b>Proposed resolution:</b></p>
<p>Alter the class definition of <tt>packaged_task</tt> in 30.6.9 [futures.task] p. 2 as follows:</p>
<blockquote><pre>
template&lt;class R, class... ArgTypes&gt;
class packaged_task&lt;R(ArgTypes...)&gt; {
public:
  <del>typedef R result_type;</del>
  [...]
};
</pre></blockquote>





<hr>
<h3><a name="2031"></a>2031. <tt>std::future&lt;&gt;::share()</tt> only applies to rvalues</h3>
<p><b>Section:</b> 30.6.6 [futures.unique_future] <b>Status:</b> <a href="lwg-active.html#Voting">Tentatively Voting</a>
 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2011-02-17 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Voting">Tentatively Voting</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As specified, <tt>future&lt;&gt;::share()</tt> has the signature
</p>

<blockquote><pre>
shared_future&lt;R&gt; share() &amp;&amp;;
</pre></blockquote>

<p>
This means that it can only be applied to rvalues. One of the key benefits of <tt>share()</tt> is 
that it can be used with the new <tt>auto</tt> facility:
</p>

<blockquote><pre>
std::promise&lt;<em>some_long_winded_type_name</em>&gt; some_promise;
auto f = some_promise.get_future(); // std::future
auto sf = std::move(f).share();
</pre></blockquote>

<p>
<tt>share()</tt> is sufficiently explicit that the move should not be required. We should be able to write:
</p>

<blockquote><pre>
auto sf = f.share();
</pre></blockquote>

<p><i>[2011-02-22 Reflector discussion]</i></p>

<p>
Moved to Tentatively Ready after 5 votes.
</p> 


<p><b>Proposed resolution:</b></p>
<p>Alter the declaration of <tt>share()</tt> to remove the "&amp;&amp;" rvalue qualifier in 
30.6.6 [futures.unique_future] p. 3, and 30.6.6 [futures.unique_future] p. 11:</p>

<blockquote><pre>
shared_future&lt;R&gt; share() <del>&amp;&amp;</del>;
</pre></blockquote>






<hr>
<h3><a name="2032"></a>2032. Incorrect synchronization clause of <tt>async</tt> function</h3>
<p><b>Section:</b> 30.6.8 [futures.async] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2011-02-17 <b>Last modified:</b> 2011-03-24</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Clause 30.6.8 [futures.async] has undergone significant rewording
in Batavia. Due to co-presence of at least three different sources
of modification there is a part where changes have overlapped
(marked by an Editor's note), which should be reconciled. Moreover,
I believe that a few non-overlapping sentences are now incorrect
and should be fixed, so the problem cannot be handled editorially.
(See c++std-lib-29667.)
</p>

<p><i>[Adopted in Madrid, 2011-03]</i></p>




<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p> 
Edit 30.6.4 [futures.state], paragraph 3 as follows.
</p>

<blockquote>
<p>
An <dfn>asynchronous return object</dfn>
is an object that reads results from an associated asynchronous state.
A <dfn>waiting function</dfn> of an asynchronous return object
is one that potentially blocks
to wait for the associated asynchronous state to be made ready.
<ins>If a waiting function can return
before the state is made ready because of a timeout (30.2.5),
then it is a <dfn>timed waiting function</dfn>,
otherwise it is a <dfn>non-timed waiting function</dfn>.</ins>
</p>
</blockquote>
</li>

<li>
<p>
Edit within 30.6.8 [futures.async] paragraph 3 bullet 2 as follows.
</p>

<blockquote>
<p>
<i>Effects:</i>
[...]
</p>
<ul><li>if <code>policy &amp; launch::deferred</code> is non-zero &mdash; [...]
The associated asynchronous state is not made ready
until the function has completed.
The first call to a <ins>non-timed waiting</ins> function
<ins>(30.6.4 [futures.state])</ins>
<del>requiring a non-timed wait</del>
on an asynchronous return object
referring to <del>the</del> <ins>this</ins>
associated asynchronous state
<del>created by this <code>async</code> call to become ready</del>
shall invoke the deferred function
in the thread that called the waiting function<del>;</del><ins>.</ins>
<del>once</del> <ins>Once</ins> evaluation of
<code><var>INVOKE</var>(g, xyz)</code> begins,
the function is no longer considered deferred.
[...]
</li></ul>
</blockquote>
</li>

<li>
<p>
Edit 30.6.8 [futures.async] paragraph 5 as follows.
</p>

<blockquote>
<p>
<i>Synchronization:</i>
Regardless of the provided <code>policy</code> argument,
</p>
<ul>
<li>
the invocation of <code>async</code> synchronizes with (1.10)
the invocation of <code>f</code>.
[<i>Note:</i>
this statement applies even when the corresponding future object
is moved to another thread.
&mdash;<i>end note</i>];
and
</li>
<li>
the completion of the function <code>f</code>
is sequenced before (1.10) the associated asynchronous state is made ready.
[<i>Note:</i>
<code>f</code> might not be called at all,
so its completion might never happen.
&mdash;<i>end note</i>]
</li>
</ul>

<p>
<del>If <code>policy &amp; launch::async</code> is non-zero,</del>
<ins>If the implementation chooses the <code>launch::async</code> policy,</ins>
</p>
<ul>
<li>
a call to a waiting function on an asynchronous return object
that shares the associated asynchronous state
created by this <code>async</code> call
shall block until the associated thread has completed,
as if joined (30.3.1.5);
</li>
<li>
<del>the <code>join()</code> on the created thread object</del>
<ins>the associated thread completion</ins>
synchronizes with (1.10)
the return from the first function
that successfully detects the ready status of the associated asynchronous state
or with the return from the last function that 
releases the associated asynchronous state <del>returns</del>,
whichever happens first.
<del><b>[Editor's note:
N3196 changes the following sentence as indicated.
N3188 removes the sentence.
Please pick one.]</b>
If the invocation is deferred,
the completion of the invocation of the deferred function
synchronizes with the successful return
from a call to a waiting function on the associated asynchronous state.</del>
</li>
</ul>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="2033"></a>2033. Preconditions of <tt>reserve</tt>, <tt>shrink_to_fit</tt>, and <tt>resize</tt> functions</h3>
<p><b>Section:</b> 23.3.6.3 [vector.capacity], 23.3.3.3 [deque.capacity] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2011-02-20 <b>Last modified:</b> 2011-03-24</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>
I have several questions with regard to the working paper N3225 (C++0x working draft):
</p>
<ol>
<li><p>
Where the working draft specifies preconditions for <tt>shrink_to_fit</tt>
member function of <tt>std::vector</tt> and <tt>std::deque</tt>?
</p></li>
<li><p>
Where the working draft specifies preconditions for '<tt>void reserve(size_type n)</tt>' 
member function of <tt>std::vector</tt>?
</p></li>
<li><p>
Does a call to '<tt>void resize(size_type sz)</tt>' of <tt>std::vector</tt> require
the element type to be <tt>DefaultConstructible</tt>? If yes, why such
requirement is not listed in the <i>Requires</i> paragraph?
</p></li>
<li><p>
Does a call to '<tt>void resize(size_type sz)</tt>' 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 <i>Effects</i> paragraph would require the element type to be <tt>MoveAssignable</tt>?
</p></li>
<li><p>
Why <tt>CopyInsertable</tt> requirement is used for '<tt>void resize(size_type sz)</tt>' of <tt>std::vector</tt> 
instead of <tt>MoveInsertable</tt> requirement?
</p></li>
</ol>



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





<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> 2011-03-24</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-active.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><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] p. 5:</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.6.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&frasl;note<br/>pre-&frasl;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:</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&frasl;note<br/>pre-&frasl;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>pre: <tt>(a, b)</tt> is in the domain<br/>
of <tt>==</tt>.
</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>pre: <tt>a</tt> is dereferenceable.
</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:</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&frasl;note<br/>pre-&frasl;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.<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/>
<i>Remark</i>: After this operation<br/>
<tt>r</tt> is not required to be<br/>
dereferenceable <ins>or incrementable</ins>.<br/>
<del>post: <tt>r</tt> is incrementable.</del>
</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><i>Remark</i>: After this operation<br/>
<tt>r</tt> is not required to be<br/>
dereferenceable <ins>or incrementable</ins>.<br/>
<del>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><i>Remark</i>: After this operation<br/>
<tt>r</tt> is not required to be<br/>
dereferenceable <ins>or incrementable</ins>.<br/>
<del>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&frasl;note<br/>pre-&frasl;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&frasl;note<br/>pre-&frasl;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> 2011-03-24</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.6.3.2 [pointer.traits.functions] refers to a 
"dereferenceable pointer"; in 22.4.5.1.2 [locale.time.get.virtuals]&frasl;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><b>Proposed resolution:</b></p>
<p></p>





<hr>
<h3><a name="2039"></a>2039. Issues with <tt>std::reverse</tt> and <tt>std::copy_if</tt></h3>
<p><b>Section:</b> 25.3.1 [alg.copy], 25.3.10 [alg.reverse] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2011-03-02 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<ol>
<li><p>In the description of <tt>std::reverse</tt></p>
<blockquote><p>
<i>Effects</i>: For each non-negative integer <tt>i &lt;= (last - first)/2</tt>, applies <tt>iter_swap</tt> 
to all pairs of iterators <tt>first + i</tt>, <tt>(last - i) - 1</tt>.
</p></blockquote>
<p>
should be changed to
</p><blockquote><p>
<i>Effects</i>: For each non-negative integer <tt>i <strong>&lt;</strong> (last - first)/2</tt>, applies <tt>iter_swap</tt> 
to all pairs of iterators <tt>first + i</tt>, <tt>(last - i) - 1</tt>.
</p></blockquote><p>
Here <tt>i</tt> shall be strictly less than <tt>(last - first)/2</tt>.
</p>
</li>
<li><p>In the description of <tt>std::copy_if</tt> <i>Returns</i> paragraph is missing.</p></li>
</ol>

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



<p><b>Proposed resolution:</b></p>
<ol>
<li><p>Modify 25.3.10 [alg.reverse] p. 1 as indicated:</p>

<blockquote><p>
1 <i>Effects</i>: For each non-negative integer <tt>i &lt;<del>=</del> (last - first)/2</tt>, applies <tt>iter_swap</tt> 
to all pairs of iterators <tt>first + i</tt>, <tt>(last - i) - 1</tt>.
</p></blockquote>
</li>

<li><p>Add the following <i>Returns</i> element after 25.3.1 [alg.copy] p. 9:</p>

<blockquote><pre>
template&lt;class InputIterator, class OutputIterator, class Predicate&gt;
OutputIterator copy_if(InputIterator first, InputIterator last,
   OutputIterator result, Predicate pred);
</pre><blockquote><p>
8 <i>Requires</i>: The ranges <tt>[first,last)</tt> and <tt>[result,result + (last - first))</tt> shall not overlap.
<p/>
9 <i>Effects</i>: Copies all of the elements referred to by the iterator <tt>i</tt> in the range <tt>[first,last)</tt> 
for which <tt>pred(*i)</tt> is true.
<p/>
<ins>?? <i>Returns</i>: The end of the resulting range.</ins>
<p/>
10 <i>Complexity</i>: Exactly <tt>last - first</tt> applications of the corresponding predicate.
<p/>
11 <i>Remarks</i>: Stable.
</p></blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="2040"></a>2040. Missing type traits related to <tt>is_convertible</tt></h3>
<p><b>Section:</b> 20.9 [meta] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-03-03 <b>Last modified:</b> 2011-03-24</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>When <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a>
was suggested, it concentrated on constructions, assignments, and destructions, but overlooked 
to complement the single remaining compiler-support trait</p>

<blockquote><pre>
template &lt;class From, class To&gt; struct is_convertible;
</pre></blockquote>

<p>with the no-throw and triviality related aspects as it had been done with the other
expression-based traits. Specifically, the current specification misses to add the
following traits:
</p>

<blockquote><pre>
template &lt;class From, class To&gt; struct is_nothrow_convertible;
template &lt;class From, class To&gt; struct is_trivially_convertible;
</pre></blockquote>

<p>In particular the lack of <tt>is_nothrow_convertible</tt> is severly restricting. This
was recently recognized when the proposal for <tt>decay_copy</tt> was prepared by 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3255.html">n3255</a>.
There does not exist a portable means to define the correct conditional <tt>noexcept</tt>
specification for the <tt>decay_copy</tt> function template, which is declared as:</p>

<blockquote><pre>
template &lt;class T&gt; 
typename decay&lt;T&gt;::type decay_copy(T&amp;&amp; v) noexcept(<i>???</i>);
</pre></blockquote>

<p>The semantics of <tt>decay_copy</tt> bases on an implicit conversion which again
influences the overload set of functions that are viable here. In most circumstances
this will have the same effect as comparing against the trait 
<tt>std::is_nothrow_move_constructible</tt>, but there is no guarantee for that being
the right answer. It is possible to construct examples, where this would lead
to the false result, e.g.</p>

<blockquote><pre>
struct S {
  S(const S&amp;) noexcept(false);
 
  template&lt;class T&gt;
  explicit S(T&amp;&amp;) noexcept(true);
};
</pre></blockquote>

<p><tt>std::is_nothrow_move_constructible</tt> will properly honor the explicit template
constructor because of the direct-initialization context which is part of the
<tt>std::is_constructible</tt> definition and will in this case select it, such that
<tt>std::is_nothrow_move_constructible&lt;S&gt;::value == true</tt>, but if we had
the traits <tt>is_nothrow_convertible</tt>, <tt>is_nothrow_convertible&lt;S, S&gt;::value</tt>
would evaluate to <tt>false</tt>, because it would use the copy-initialization context
that is part of the <tt>is_convertible</tt> definition, excluding any explicit
constructors and giving the opposite result.</p>

<p>The <tt>decay_copy</tt> example is surely not one of the most convincing examples, but
<tt>is_nothrow_convertible</tt> has several use-cases, and can e.g. be used to express
whether calling the following implicit conversion function could throw an exception or not:</p>

<blockquote><pre>
template&lt;class T, class U&gt;
T implicit_cast(U&amp;&amp; u) noexcept(is_nothrow_convertible&lt;U, T&gt;::value) 
{
  return std::forward&lt;U&gt;(u);
}
</pre></blockquote>

<p>Therefore I suggest to add the missing trait <tt>is_nothrow_convertible</tt> and for
completeness also the missing trait <tt>is_trivially_convertible</tt> to 20.9 [meta].</p>

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


<p>
Daniel K: This is a new feature so out of scope.
<p/>
Pablo: Any objections to moving 2040 to Open?
<p/>
No objections. 
</p>


<p><b>Proposed resolution:</b></p>
<ol>
<li><p>Ammend the following declarations to the header <tt>&lt;type_traits&gt;</tt> synopsis
in 20.9.2 [meta.type.synop]:</p>

<blockquote><pre>
namespace std {
  &hellip;
  // 20.9.6, type relations:
  template &lt;class T, class U&gt; struct is_same;
  template &lt;class Base, class Derived&gt; struct is_base_of;
  template &lt;class From, class To&gt; struct is_convertible;
  <ins>template &lt;class From, class To&gt; struct is_trivially_convertible;</ins>
  <ins>template &lt;class From, class To&gt; struct is_nothrow_convertible;</ins>

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

<li><p>Modify Table 51 &mdash; &quot;Type relationship predicates&quot; as indicated. The removal of the
remaining traces of the trait <tt>is_explicitly_convertible</tt> is an editorial
step, it was removed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3047.html">n3047</a>:
</p>

<blockquote>
<table border="1">
<caption>Table 51 &mdash; Type relationship predicates</caption>

<tr>
<th>Template</th>
<th>Condition</th>
<th>Comments</th>
</tr>

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

<tr>
<td><tt>template &lt;class From, class To&gt;<br/>
struct is_convertible;</tt></td>
<td><i>see below</i></td>
<td><tt>From</tt> and <tt>To</tt> shall be complete<br/>
types, arrays of unknown bound, or<br/>
(possibly cv-qualified) <tt>void</tt><br/>
types.</td>
</tr>

<tr>
<td><del><tt>template &lt;class From, class To&gt;<br/>
struct is_explicitly_convertible;</tt></del></td>
<td><del><tt>is_constructible&lt;To, From&gt;::value</tt></del></td>
<td><del>a synonym for a two-argument<br/>
version of <tt>is_constructible</tt>.<br/>
An implementation may define it<br/>
as an alias template.</del></td>
</tr>

<tr>
<td><ins><tt>template &lt;class From, class To&gt;<br/>
struct is_trivially_convertible;</tt></ins></td>
<td><ins><tt>is_convertible&lt;From,<br/>
 To&gt;::value</tt> is <tt>true</tt> and the<br/>
conversion, as defined by<br/>
<tt>is_convertible</tt>, is known<br/>
to call no operation that is<br/>
not trivial ([basic.types], [special]).</ins></td>
<td><ins><tt>From</tt> and <tt>To</tt> shall be complete<br/>
types, arrays of unknown bound,<br/>
or (possibly cv-qualified) <tt>void</tt><br/>
types.</ins></td>
</tr>

<tr>
<td><ins><tt>template &lt;class From, class To&gt;<br/>
struct is_nothrow_convertible;</tt></ins></td>
<td><ins><tt>is_convertible&lt;From,<br/>
 To&gt;::value</tt> is <tt>true</tt> and the<br/>
conversion, as defined by<br/>
<tt>is_convertible</tt>, is known<br/>
not to throw any<br/>
exceptions ([expr.unary.noexcept]).</ins></td>
<td><ins><tt>From</tt> and <tt>To</tt> shall be complete<br/>
types, arrays of unknown bound,<br/>
or (possibly cv-qualified) <tt>void</tt><br/>
types.</ins></td>
</tr>

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

</table>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2041"></a>2041. Stage 2 accumulate incompatibilty</h3>
<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2011-03-09 <b>Last modified:</b> 2011-03-24</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><tt>num_get</tt> Stage 2 accumulation changed between C++03 and the current C++0x working draft. The sentences:</p>

<blockquote><p>
If it is not discarded, then a check is made to determine if <tt>c</tt> is allowed as the
next character of an input field of the conversion specifier returned by stage 1.
If so it is accumulated.
</p></blockquote>

<p>have been dropped from 22.4.2.1.2 [facet.num.get.virtuals], Stage 2, paragraph 3 that begins:</p>

<blockquote><p>
If <tt>discard</tt> is true, [&hellip;]
</p></blockquote>

<p>Consider this code:</p>

<blockquote><pre>
#include &lt;sstream&gt;
#include &lt;iostream&gt;

int main(void)
{
   std::istringstream s("8cz");
   long i = 0;
   char c;
   s &gt;&gt; i;
   if (!s.fail())
       std::cout &lt;&lt; "i = " &lt;&lt; i &lt;&lt; '\n';
   else
   {
       std::cout &lt;&lt; "s &gt;&gt; i failed\n";
       s.clear();
   }
   s &gt;&gt; c;
   if (!s.fail())
       std::cout &lt;&lt; "c = " &lt;&lt; c &lt;&lt; '\n';
   else
       std::cout &lt;&lt; "s &gt;&gt; c failed\n";
}
</pre></blockquote>

<p>C++0x currently prints out:</p>

<blockquote><pre>
s &gt;&gt; i failed
c = z
</pre></blockquote>

<p>However C++03 conforming implementations will output:</p>

<blockquote><pre>
i = 8
c = c
</pre></blockquote>

<p>I believe we need to restore C++03 compatibility.</p>



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

<p>Add to 22.4.2.1.2 [facet.num.get.virtuals], Stage 2:</p>

<blockquote><p>
If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been accumulated, then the position of the character
is remembered, but the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has already been
accumulated, the character is discarded and Stage 2 terminates. <ins>If it is not discarded, then a 
check is made to determine if <tt>c</tt> is allowed as the next character of an input field of the 
conversion specifier returned by stage 1. If so it is accumulated.</ins>
<p/>
If the character is either discarded or accumulated then in is advanced by <tt>++in</tt> and processing
returns to the beginning of stage 2.
</p></blockquote>





<hr>
<h3><a name="2042"></a>2042. Comparing <tt>forward_list::before_begin()</tt> to <tt>forward_list::end()</tt></h3>
<p><b>Section:</b> 23.3.4.3 [forwardlist.iter] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2011-03-13 <b>Last modified:</b> 2011-03-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>For an object <tt>c</tt> of type <tt>forward_list&lt;X, Alloc&gt;</tt>, the iterators
<tt>c.before_begin()</tt> and <tt>c.end()</tt> are part of the same underlying sequence,
so the expression <tt>c.before_begin() == c.end()</tt>  must be well-defined.
But the standard says nothing about what the result of this expression
should be.  The forward iterator requirements says no dereferenceable
iterator is equal to a non-dereferenceable iterator and that two
dereferenceable iterators are equal if and only if they point to the
same element.  But since <tt>before_begin()</tt> and <tt>end()</tt> are both
non-dereferenceable, neither of these rules applies.
</p>

<p>
Many <tt>forward_list</tt> methods, such as <tt>insert_after()</tt>, have a
precondition that the iterator passed to them must not be equal to
<tt>end()</tt>. Thus, user code might look like the following:
</p>
<blockquote><pre>
void foo(forward_list&lt;int&gt;&amp; c, forward_list&lt;int&gt;::iterator it)
{
  assert(it != c.end());
  c.insert_after(it, 42);
}
</pre></blockquote>

<p>
Conversely, <tt>before_begin()</tt> was specifically designed to be used with
methods like <tt>insert_after()</tt>, so if <tt>c.before_begin()</tt> is passed to 
this function the assertion must not fail.
</p>

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


<p>The suggested wording changes are necessary but not sufficient. Since there
does not exist an equivalent semantic definition of <tt>cbefore_begin()</tt> as
we have for <tt>cbegin()</tt>, this still leaves the question open whether
the normative remark applies to <tt>cbefore_begin()</tt> as well. A simple fix
is to define the operational semantics of <tt>cbefore_begin()</tt> in terms of
<tt>before_begin()</tt>.</p>

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


<p>
General agreement that this is a serious bug.
<p/>
Pablo: Any objections to moving 2042 to Immediate?
<p/>
No objections. 
</p>



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

<p>Add to the definition of <tt>forward_list::before_begin()</tt> 23.3.4.3 [forwardlist.iter] 
the following:</p>

<blockquote><pre>
iterator before_begin();
const_iterator before_begin() const;
const_iterator cbefore_begin() const;
</pre><blockquote><p>
-1- <i>Returns</i>: A non-dereferenceable iterator that, when incremented, is equal to the iterator returned by <tt>begin()</tt>.
<p/>
<ins>-?- <i>Effects</i>: <tt>cbefore_begin()</tt> is equivalent to <tt>const_cast&lt;forward_list const&amp;>(*this).before_begin()</tt>.</ins>
<p/>
<ins>-?- <i>Remarks</i>: <tt>before_begin() == end()</tt> shall equal false.</ins>
</p></blockquote></blockquote>





</body>
</html>
