<!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">N3312=11-0082</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2011-09-06</td>
</tr>
<tr>
  <td align="left">Project:</td>
  <td align="left">Programming Language C++</td>
</tr>
<tr>
  <td align="left">Reply to:</td>
  <td align="left">Alisdair Meredith &lt;<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>&gt;</td>
</tr>
</table>
<h1>C++ Standard Library Active Issues List (Revision R76)</h1>
<p>Revised 2011-09-06 at 13:09:55 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>R76: 2011-09-06 post-Bloomington mailing<ul>
<li><b>Summary:</b><ul>
<li>44 open issues, up by 19.</li>
<li>1549 closed issues, up by 9.</li>
<li>1593 issues total, up by 28.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 2 NAD issues: <a href="lwg-closed.html#2043">2043</a>, <a href="lwg-closed.html#2068">2068</a>.</li>
<li>Added the following 2 NAD Future issues: <a href="lwg-closed.html#2051">2051</a>, <a href="lwg-closed.html#2055">2055</a>.</li>
<li>Added the following 6 Open issues: <a href="lwg-active.html#2052">2052</a>, <a href="lwg-active.html#2054">2054</a>, <a href="lwg-active.html#2057">2057</a>, <a href="lwg-active.html#2062">2062</a>, <a href="lwg-active.html#2063">2063</a>, <a href="lwg-active.html#2070">2070</a>.</li>
<li>Added the following Pending NAD issue: <a href="lwg-closed.html#2046">2046</a>.</li>
<li>Added the following Pending NAD Editorial issue: <a href="lwg-closed.html#2060">2060</a>.</li>
<li>Added the following 10 Ready issues: <a href="lwg-active.html#2044">2044</a>, <a href="lwg-active.html#2045">2045</a>, <a href="lwg-active.html#2047">2047</a>, <a href="lwg-active.html#2050">2050</a>, <a href="lwg-active.html#2053">2053</a>, <a href="lwg-active.html#2061">2061</a>, <a href="lwg-active.html#2064">2064</a>, <a href="lwg-active.html#2065">2065</a>, <a href="lwg-active.html#2067">2067</a>, <a href="lwg-active.html#2069">2069</a>.</li>
<li>Added the following 5 Review issues: <a href="lwg-active.html#2048">2048</a>, <a href="lwg-active.html#2049">2049</a>, <a href="lwg-active.html#2056">2056</a>, <a href="lwg-active.html#2058">2058</a>, <a href="lwg-active.html#2059">2059</a>.</li>
<li>Added the following Tentatively Resolved issue: <a href="lwg-active.html#2066">2066</a>.</li>
<li>Changed the following 322 issues from WP to C++11: <a href="lwg-defects.html#149">149</a>, <a href="lwg-defects.html#296">296</a>, <a href="lwg-defects.html#419">419</a>, <a href="lwg-defects.html#427">427</a>, <a href="lwg-defects.html#430">430</a>, <a href="lwg-defects.html#471">471</a>, <a href="lwg-defects.html#473">473</a>, <a href="lwg-defects.html#498">498</a>, <a href="lwg-defects.html#539">539</a>, <a href="lwg-defects.html#556">556</a>, <a href="lwg-defects.html#564">564</a>, <a href="lwg-defects.html#565">565</a>, <a href="lwg-defects.html#630">630</a>, <a href="lwg-defects.html#659">659</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#688">688</a>, <a href="lwg-defects.html#696">696</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#711">711</a>, <a href="lwg-defects.html#716">716</a>, <a href="lwg-defects.html#723">723</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#752">752</a>, <a href="lwg-defects.html#753">753</a>, <a href="lwg-defects.html#758">758</a>, <a href="lwg-defects.html#765">765</a>, <a href="lwg-defects.html#774">774</a>, <a href="lwg-defects.html#780">780</a>, <a href="lwg-defects.html#788">788</a>, <a href="lwg-defects.html#810">810</a>, <a href="lwg-defects.html#811">811</a>, <a href="lwg-defects.html#814">814</a>, <a href="lwg-defects.html#817">817</a>, <a href="lwg-defects.html#819">819</a>, <a href="lwg-defects.html#821">821</a>, <a href="lwg-defects.html#835">835</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-defects.html#838">838</a>, <a href="lwg-defects.html#847">847</a>, <a href="lwg-defects.html#853">853</a>, <a href="lwg-defects.html#854">854</a>, <a href="lwg-defects.html#857">857</a>, <a href="lwg-defects.html#859">859</a>, <a href="lwg-defects.html#860">860</a>, <a href="lwg-defects.html#861">861</a>, <a href="lwg-defects.html#865">865</a>, <a href="lwg-defects.html#866">866</a>, <a href="lwg-defects.html#868">868</a>, <a href="lwg-defects.html#869">869</a>, <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#871">871</a>, <a href="lwg-defects.html#872">872</a>, <a href="lwg-defects.html#876">876</a>, <a href="lwg-defects.html#878">878</a>, <a href="lwg-defects.html#881">881</a>, <a href="lwg-defects.html#883">883</a>, <a href="lwg-defects.html#885">885</a>, <a href="lwg-defects.html#886">886</a>, <a href="lwg-defects.html#888">888</a>, <a href="lwg-defects.html#890">890</a>, <a href="lwg-defects.html#891">891</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-defects.html#894">894</a>, <a href="lwg-defects.html#896">896</a>, <a href="lwg-defects.html#898">898</a>, <a href="lwg-defects.html#899">899</a>, <a href="lwg-defects.html#900">900</a>, <a href="lwg-defects.html#904">904</a>, <a href="lwg-defects.html#907">907</a>, <a href="lwg-defects.html#909">909</a>, <a href="lwg-defects.html#911">911</a>, <a href="lwg-defects.html#920">920</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#922">922</a>, <a href="lwg-defects.html#925">925</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-defects.html#931">931</a>, <a href="lwg-defects.html#934">934</a>, <a href="lwg-defects.html#938">938</a>, <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-defects.html#948">948</a>, <a href="lwg-defects.html#949">949</a>, <a href="lwg-defects.html#951">951</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-defects.html#956">956</a>, <a href="lwg-defects.html#957">957</a>, <a href="lwg-defects.html#960">960</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#963">963</a>, <a href="lwg-defects.html#965">965</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>, <a href="lwg-defects.html#970">970</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#975">975</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-defects.html#981">981</a>, <a href="lwg-defects.html#982">982</a>, <a href="lwg-defects.html#984">984</a>, <a href="lwg-defects.html#986">986</a>, <a href="lwg-defects.html#987">987</a>, <a href="lwg-defects.html#990">990</a>, <a href="lwg-defects.html#991">991</a>, <a href="lwg-defects.html#993">993</a>, <a href="lwg-defects.html#994">994</a>, <a href="lwg-defects.html#997">997</a>, <a href="lwg-defects.html#998">998</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-defects.html#1004">1004</a>, <a href="lwg-defects.html#1006">1006</a>, <a href="lwg-defects.html#1011">1011</a>, <a href="lwg-defects.html#1012">1012</a>, <a href="lwg-defects.html#1014">1014</a>, <a href="lwg-defects.html#1019">1019</a>, <a href="lwg-defects.html#1021">1021</a>, <a href="lwg-defects.html#1030">1030</a>, <a href="lwg-defects.html#1033">1033</a>, <a href="lwg-defects.html#1034">1034</a>, <a href="lwg-defects.html#1037">1037</a>, <a href="lwg-defects.html#1038">1038</a>, <a href="lwg-defects.html#1039">1039</a>, <a href="lwg-defects.html#1040">1040</a>, <a href="lwg-defects.html#1044">1044</a>, <a href="lwg-defects.html#1045">1045</a>, <a href="lwg-defects.html#1065">1065</a>, <a href="lwg-defects.html#1066">1066</a>, <a href="lwg-defects.html#1070">1070</a>, <a href="lwg-defects.html#1071">1071</a>, <a href="lwg-defects.html#1073">1073</a>, <a href="lwg-defects.html#1079">1079</a>, <a href="lwg-defects.html#1089">1089</a>, <a href="lwg-defects.html#1094">1094</a>, <a href="lwg-defects.html#1095">1095</a>, <a href="lwg-defects.html#1097">1097</a>, <a href="lwg-defects.html#1098">1098</a>, <a href="lwg-defects.html#1103">1103</a>, <a href="lwg-defects.html#1104">1104</a>, <a href="lwg-defects.html#1108">1108</a>, <a href="lwg-defects.html#1110">1110</a>, <a href="lwg-defects.html#1113">1113</a>, <a href="lwg-defects.html#1114">1114</a>, <a href="lwg-defects.html#1118">1118</a>, <a href="lwg-defects.html#1123">1123</a>, <a href="lwg-defects.html#1126">1126</a>, <a href="lwg-defects.html#1130">1130</a>, <a href="lwg-defects.html#1131">1131</a>, <a href="lwg-defects.html#1133">1133</a>, <a href="lwg-defects.html#1134">1134</a>, <a href="lwg-defects.html#1136">1136</a>, <a href="lwg-defects.html#1137">1137</a>, <a href="lwg-defects.html#1138">1138</a>, <a href="lwg-defects.html#1144">1144</a>, <a href="lwg-defects.html#1152">1152</a>, <a href="lwg-defects.html#1157">1157</a>, <a href="lwg-defects.html#1158">1158</a>, <a href="lwg-defects.html#1159">1159</a>, <a href="lwg-defects.html#1170">1170</a>, <a href="lwg-defects.html#1171">1171</a>, <a href="lwg-defects.html#1177">1177</a>, <a href="lwg-defects.html#1178">1178</a>, <a href="lwg-defects.html#1180">1180</a>, <a href="lwg-defects.html#1181">1181</a>, <a href="lwg-defects.html#1182">1182</a>, <a href="lwg-defects.html#1183">1183</a>, <a href="lwg-defects.html#1187">1187</a>, <a href="lwg-defects.html#1189">1189</a>, <a href="lwg-defects.html#1191">1191</a>, <a href="lwg-defects.html#1192">1192</a>, <a href="lwg-defects.html#1193">1193</a>, <a href="lwg-defects.html#1194">1194</a>, <a href="lwg-defects.html#1195">1195</a>, <a href="lwg-defects.html#1197">1197</a>, <a href="lwg-defects.html#1198">1198</a>, <a href="lwg-defects.html#1199">1199</a>, <a href="lwg-defects.html#1204">1204</a>, <a href="lwg-defects.html#1205">1205</a>, <a href="lwg-defects.html#1206">1206</a>, <a href="lwg-defects.html#1207">1207</a>, <a href="lwg-defects.html#1208">1208</a>, <a href="lwg-defects.html#1209">1209</a>, <a href="lwg-defects.html#1215">1215</a>, <a href="lwg-defects.html#1216">1216</a>, <a href="lwg-defects.html#1218">1218</a>, <a href="lwg-defects.html#1220">1220</a>, <a href="lwg-defects.html#1221">1221</a>, <a href="lwg-defects.html#1222">1222</a>, <a href="lwg-defects.html#1227">1227</a>, <a href="lwg-defects.html#1231">1231</a>, <a href="lwg-defects.html#1234">1234</a>, <a href="lwg-defects.html#1237">1237</a>, <a href="lwg-defects.html#1240">1240</a>, <a href="lwg-defects.html#1241">1241</a>, <a href="lwg-defects.html#1245">1245</a>, <a href="lwg-defects.html#1247">1247</a>, <a href="lwg-defects.html#1249">1249</a>, <a href="lwg-defects.html#1250">1250</a>, <a href="lwg-defects.html#1252">1252</a>, <a href="lwg-defects.html#1253">1253</a>, <a href="lwg-defects.html#1254">1254</a>, <a href="lwg-defects.html#1255">1255</a>, <a href="lwg-defects.html#1256">1256</a>, <a href="lwg-defects.html#1257">1257</a>, <a href="lwg-defects.html#1261">1261</a>, <a href="lwg-defects.html#1262">1262</a>, <a href="lwg-defects.html#1264">1264</a>, <a href="lwg-defects.html#1267">1267</a>, <a href="lwg-defects.html#1270">1270</a>, <a href="lwg-defects.html#1271">1271</a>, <a href="lwg-defects.html#1276">1276</a>, <a href="lwg-defects.html#1277">1277</a>, <a href="lwg-defects.html#1278">1278</a>, <a href="lwg-defects.html#1279">1279</a>, <a href="lwg-defects.html#1280">1280</a>, <a href="lwg-defects.html#1284">1284</a>, <a href="lwg-defects.html#1285">1285</a>, <a href="lwg-defects.html#1286">1286</a>, <a href="lwg-defects.html#1287">1287</a>, <a href="lwg-defects.html#1288">1288</a>, <a href="lwg-defects.html#1292">1292</a>, <a href="lwg-defects.html#1294">1294</a>, <a href="lwg-defects.html#1295">1295</a>, <a href="lwg-defects.html#1298">1298</a>, <a href="lwg-defects.html#1299">1299</a>, <a href="lwg-defects.html#1303">1303</a>, <a href="lwg-defects.html#1306">1306</a>, <a href="lwg-defects.html#1309">1309</a>, <a href="lwg-defects.html#1310">1310</a>, <a href="lwg-defects.html#1312">1312</a>, <a href="lwg-defects.html#1316">1316</a>, <a href="lwg-defects.html#1319">1319</a>, <a href="lwg-defects.html#1323">1323</a>, <a href="lwg-defects.html#1325">1325</a>, <a href="lwg-defects.html#1332">1332</a>, <a href="lwg-defects.html#1333">1333</a>, <a href="lwg-defects.html#1334">1334</a>, <a href="lwg-defects.html#1335">1335</a>, <a href="lwg-defects.html#1337">1337</a>, <a href="lwg-defects.html#1338">1338</a>, <a href="lwg-defects.html#1339">1339</a>, <a href="lwg-defects.html#1340">1340</a>, <a href="lwg-defects.html#1349">1349</a>, <a href="lwg-defects.html#1354">1354</a>, <a href="lwg-defects.html#1360">1360</a>, <a href="lwg-defects.html#1362">1362</a>, <a href="lwg-defects.html#1363">1363</a>, <a href="lwg-defects.html#1367">1367</a>, <a href="lwg-defects.html#1368">1368</a>, <a href="lwg-defects.html#1370">1370</a>, <a href="lwg-defects.html#1372">1372</a>, <a href="lwg-defects.html#1381">1381</a>, <a href="lwg-defects.html#1384">1384</a>, <a href="lwg-defects.html#1385">1385</a>, <a href="lwg-defects.html#1386">1386</a>, <a href="lwg-defects.html#1387">1387</a>, <a href="lwg-defects.html#1388">1388</a>, <a href="lwg-defects.html#1399">1399</a>, <a href="lwg-defects.html#1400">1400</a>, <a href="lwg-defects.html#1401">1401</a>, <a href="lwg-defects.html#1402">1402</a>, <a href="lwg-defects.html#1403">1403</a>, <a href="lwg-defects.html#1404">1404</a>, <a href="lwg-defects.html#1408">1408</a>, <a href="lwg-defects.html#1414">1414</a>, <a href="lwg-defects.html#1416">1416</a>, <a href="lwg-defects.html#1417">1417</a>, <a href="lwg-defects.html#1418">1418</a>, <a href="lwg-defects.html#1420">1420</a>, <a href="lwg-defects.html#1423">1423</a>, <a href="lwg-defects.html#1424">1424</a>, <a href="lwg-defects.html#1425">1425</a>, <a href="lwg-defects.html#1426">1426</a>, <a href="lwg-defects.html#1427">1427</a>, <a href="lwg-defects.html#1428">1428</a>, <a href="lwg-defects.html#1429">1429</a>, <a href="lwg-defects.html#1430">1430</a>, <a href="lwg-defects.html#1431">1431</a>, <a href="lwg-defects.html#1432">1432</a>, <a href="lwg-defects.html#1435">1435</a>, <a href="lwg-defects.html#1436">1436</a>, <a href="lwg-defects.html#1437">1437</a>, <a href="lwg-defects.html#1438">1438</a>, <a href="lwg-defects.html#1439">1439</a>, <a href="lwg-defects.html#1440">1440</a>, <a href="lwg-defects.html#1441">1441</a>, <a href="lwg-defects.html#1448">1448</a>, <a href="lwg-defects.html#1449">1449</a>, <a href="lwg-defects.html#1474">1474</a>, <a href="lwg-defects.html#1478">1478</a>, <a href="lwg-defects.html#1479">1479</a>, <a href="lwg-defects.html#1480">1480</a>, <a href="lwg-defects.html#1487">1487</a>, <a href="lwg-defects.html#1494">1494</a>, <a href="lwg-defects.html#1497">1497</a>, <a href="lwg-defects.html#1514">1514</a>, <a href="lwg-defects.html#1516">1516</a>, <a href="lwg-defects.html#1517">1517</a>, <a href="lwg-defects.html#1518">1518</a>, <a href="lwg-defects.html#1519">1519</a>, <a href="lwg-defects.html#1520">1520</a>, <a href="lwg-defects.html#1522">1522</a>, <a href="lwg-defects.html#1524">1524</a>, <a href="lwg-defects.html#1525">1525</a>, <a href="lwg-defects.html#2000">2000</a>, <a href="lwg-defects.html#2001">2001</a>, <a href="lwg-defects.html#2004">2004</a>, <a href="lwg-defects.html#2007">2007</a>, <a href="lwg-defects.html#2008">2008</a>, <a href="lwg-defects.html#2014">2014</a>, <a href="lwg-defects.html#2017">2017</a>, <a href="lwg-defects.html#2019">2019</a>, <a href="lwg-defects.html#2020">2020</a>, <a href="lwg-defects.html#2022">2022</a>, <a href="lwg-defects.html#2027">2027</a>, <a href="lwg-defects.html#2029">2029</a>, <a href="lwg-defects.html#2030">2030</a>, <a href="lwg-defects.html#2031">2031</a>, <a href="lwg-defects.html#2032">2032</a>, <a href="lwg-defects.html#2041">2041</a>, <a href="lwg-defects.html#2042">2042</a>.</li>
<li>Changed the following issue from Deferred to NAD: <a href="lwg-closed.html#1330">1330</a>.</li>
<li>Changed the following issue from Deferred to NAD Future: <a href="lwg-closed.html#1521">1521</a>.</li>
<li>Changed the following issue from Open to NAD Future: <a href="lwg-closed.html#2040">2040</a>.</li>
<li>Changed the following issue from Deferred to Open: <a href="lwg-active.html#1450">1450</a>.</li>
<li>Changed the following issue from Deferred to Ready: <a href="lwg-active.html#1214">1214</a>.</li>
<li>Changed the following 2 issues from New to Ready: <a href="lwg-active.html#2013">2013</a>, <a href="lwg-active.html#2015">2015</a>.</li>
<li>Changed the following 2 issues from Open to Ready: <a href="lwg-active.html#2010">2010</a>, <a href="lwg-active.html#2033">2033</a>.</li>
<li>Changed the following issue from Review to Ready: <a href="lwg-active.html#2021">2021</a>.</li>
<li>Changed the following 2 issues from Deferred to Review: <a href="lwg-active.html#1169">1169</a>, <a href="lwg-active.html#1175">1175</a>.</li>
<li>Changed the following issue from Open to Review: <a href="lwg-active.html#2011">2011</a>.</li>
</ul></li>
</ul>
</li>
<li>R75: 
2011-03-28 post-Madrid mailing
<ul>
<li><b>Summary:</b><ul>
<li>25 open issues, down by 71.</li>
<li>1540 closed issues, up by 80.</li>
<li>1565 issues total, up by 9.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issue: <a href="lwg-closed.html#2036">2036</a>.</li>
<li>Added the following 2 Open issues: <a href="lwg-active.html#2038">2038</a>, <a href="lwg-active.html#2040">2040</a>.</li>
<li>Added the following Ready issue: <a href="lwg-active.html#2039">2039</a>.</li>
<li>Added the following Resolved issue: <a href="lwg-defects.html#2037">2037</a>.</li>
<li>Added the following 2 WP issues: <a href="lwg-defects.html#2041">2041</a>, <a href="lwg-defects.html#2042">2042</a>.</li>
<li>Changed the following issue from New to Deferred: <a href="lwg-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 7 issues from Open to NAD: <a href="lwg-closed.html#1318">1318</a>, <a href="lwg-closed.html#1348">1348</a>, <a href="lwg-closed.html#1358">1358</a>, <a href="lwg-closed.html#1369">1369</a>, <a href="lwg-closed.html#1374">1374</a>, <a href="lwg-closed.html#1452">1452</a>, <a href="lwg-closed.html#1461">1461</a>.</li>
<li>Changed the following 6 issues from Tentatively NAD to NAD: <a href="lwg-closed.html#1371">1371</a>, <a href="lwg-closed.html#1413">1413</a>, <a href="lwg-closed.html#1485">1485</a>, <a href="lwg-closed.html#1486">1486</a>, <a href="lwg-closed.html#2006">2006</a>, <a href="lwg-closed.html#2026">2026</a>.</li>
<li>Changed the following issue from Tentatively Ready to NAD: <a href="lwg-closed.html#1456">1456</a>.</li>
<li>Changed the following 2 issues from Open to NAD Future: <a href="lwg-closed.html#1396">1396</a>, <a href="lwg-closed.html#1459">1459</a>.</li>
<li>Changed the following issue from Tentatively NAD Future to NAD Future: <a href="lwg-closed.html#1320">1320</a>.</li>
<li>Changed the following 4 issues from New to Open: <a href="lwg-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 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 3 issues from New to Resolved: <a href="lwg-defects.html#1523">1523</a>, <a href="lwg-defects.html#2025">2025</a>, <a href="lwg-defects.html#2034">2034</a>.</li>
<li>Changed the following 13 issues from Open to Resolved: <a href="lwg-defects.html#964">964</a>, <a href="lwg-defects.html#966">966</a>, <a href="lwg-defects.html#985">985</a>, <a href="lwg-defects.html#1297">1297</a>, <a href="lwg-defects.html#1345">1345</a>, <a href="lwg-defects.html#1353">1353</a>, <a href="lwg-defects.html#1364">1364</a>, <a href="lwg-defects.html#1421">1421</a>, <a href="lwg-defects.html#1460">1460</a>, <a href="lwg-defects.html#1502">1502</a>, <a href="lwg-defects.html#1504">1504</a>, <a href="lwg-defects.html#1505">1505</a>, <a href="lwg-defects.html#1507">1507</a>.</li>
<li>Changed the following 4 issues from Tentatively Ready to Resolved: <a href="lwg-defects.html#1457">1457</a>, <a href="lwg-defects.html#1515">1515</a>, <a href="lwg-defects.html#2023">2023</a>, <a href="lwg-defects.html#2024">2024</a>.</li>
<li>Changed the following issue from New to Review: <a href="lwg-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 3 issues from New to WP: <a href="lwg-defects.html#1524">1524</a>, <a href="lwg-defects.html#2008">2008</a>, <a href="lwg-defects.html#2032">2032</a>.</li>
<li>Changed the following 5 issues from Open to WP: <a href="lwg-defects.html#1252">1252</a>, <a href="lwg-defects.html#1349">1349</a>, <a href="lwg-defects.html#1448">1448</a>, <a href="lwg-defects.html#1478">1478</a>, <a href="lwg-defects.html#1487">1487</a>.</li>
<li>Changed the following 8 issues from Ready to WP: <a href="lwg-defects.html#1279">1279</a>, <a href="lwg-defects.html#1332">1332</a>, <a href="lwg-defects.html#1385">1385</a>, <a href="lwg-defects.html#1401">1401</a>, <a href="lwg-defects.html#1408">1408</a>, <a href="lwg-defects.html#1418">1418</a>, <a href="lwg-defects.html#1420">1420</a>, <a href="lwg-defects.html#1438">1438</a>.</li>
<li>Changed the following 22 issues from Tentatively Ready to WP: <a href="lwg-defects.html#1215">1215</a>, <a href="lwg-defects.html#1253">1253</a>, <a href="lwg-defects.html#1310">1310</a>, <a href="lwg-defects.html#1474">1474</a>, <a href="lwg-defects.html#1479">1479</a>, <a href="lwg-defects.html#1480">1480</a>, <a href="lwg-defects.html#1494">1494</a>, <a href="lwg-defects.html#1497">1497</a>, <a href="lwg-defects.html#1514">1514</a>, <a href="lwg-defects.html#2000">2000</a>, <a href="lwg-defects.html#2001">2001</a>, <a href="lwg-defects.html#2004">2004</a>, <a href="lwg-defects.html#2007">2007</a>, <a href="lwg-defects.html#2014">2014</a>, <a href="lwg-defects.html#2017">2017</a>, <a href="lwg-defects.html#2019">2019</a>, <a href="lwg-defects.html#2020">2020</a>, <a href="lwg-defects.html#2022">2022</a>, <a href="lwg-defects.html#2027">2027</a>, <a href="lwg-defects.html#2029">2029</a>, <a href="lwg-defects.html#2030">2030</a>, <a href="lwg-defects.html#2031">2031</a>.</li>
</ul></li>
</ul>
</li>
<li>R74: 
2011-02-28 pre-Madrid mailing
<ul>
<li><b>Summary:</b><ul>
<li>96 open issues, up by 16.</li>
<li>1460 closed issues, up by 1.</li>
<li>1556 issues total, up by 17.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 7 New issues: <a href="lwg-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-closed.html#1521">1521</a>, <a href="lwg-defects.html#1523">1523</a>, <a href="lwg-defects.html#2008">2008</a>, <a href="lwg-active.html#2012">2012</a>, <a href="lwg-active.html#2013">2013</a>, <a href="lwg-defects.html#2014">2014</a>, <a href="lwg-active.html#2015">2015</a>, <a href="lwg-active.html#2016">2016</a>, <a href="lwg-defects.html#2017">2017</a>, <a href="lwg-active.html#2018">2018</a>, <a href="lwg-defects.html#2019">2019</a>.</li>
<li>Added the following 5 Open issues: <a href="lwg-defects.html#2001">2001</a>, <a href="lwg-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-closed.html#2006">2006</a>.</li>
<li>Added the following 3 Tentatively Ready issues: <a href="lwg-defects.html#2000">2000</a>, <a href="lwg-defects.html#2004">2004</a>, <a href="lwg-defects.html#2007">2007</a>.</li>
<li>Added the following WP issue: <a href="lwg-defects.html#1522">1522</a>.</li>
<li>Changed the following 3 issues from New to Deferred: <a href="lwg-active.html#1213">1213</a>, <a href="lwg-active.html#1214">1214</a>, <a href="lwg-closed.html#1330">1330</a>.</li>
<li>Changed the following issue from Open to Deferred: <a href="lwg-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-defects.html#1252">1252</a>, <a href="lwg-defects.html#1297">1297</a>.</li>
<li>Changed the following 3 issues from New to Ready: <a href="lwg-defects.html#1279">1279</a>, <a href="lwg-closed.html#1318">1318</a>, <a href="lwg-defects.html#1332">1332</a>.</li>
<li>Changed the following 6 issues from Open to Ready: <a href="lwg-defects.html#1385">1385</a>, <a href="lwg-defects.html#1401">1401</a>, <a href="lwg-defects.html#1408">1408</a>, <a href="lwg-defects.html#1418">1418</a>, <a href="lwg-defects.html#1420">1420</a>, <a href="lwg-defects.html#1438">1438</a>.</li>
<li>Changed the following 42 issues from NAD Editorial to Resolved: <a href="lwg-defects.html#353">353</a>, <a href="lwg-defects.html#431">431</a>, <a href="lwg-defects.html#482">482</a>, <a href="lwg-defects.html#525">525</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-defects.html#625">625</a>, <a href="lwg-defects.html#635">635</a>, <a href="lwg-defects.html#658">658</a>, <a href="lwg-defects.html#697">697</a>, <a href="lwg-defects.html#719">719</a>, <a href="lwg-defects.html#742">742</a>, <a href="lwg-defects.html#786">786</a>, <a href="lwg-defects.html#815">815</a>, <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#823">823</a>, <a href="lwg-defects.html#827">827</a>, <a href="lwg-defects.html#834">834</a>, <a href="lwg-defects.html#884">884</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-defects.html#947">947</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#953">953</a>, <a href="lwg-defects.html#983">983</a>, <a href="lwg-defects.html#1054">1054</a>, <a href="lwg-defects.html#1055">1055</a>, <a href="lwg-defects.html#1075">1075</a>, <a href="lwg-defects.html#1100">1100</a>, <a href="lwg-defects.html#1116">1116</a>, <a href="lwg-defects.html#1117">1117</a>, <a href="lwg-defects.html#1122">1122</a>, <a href="lwg-defects.html#1135">1135</a>, <a href="lwg-defects.html#1151">1151</a>, <a href="lwg-defects.html#1174">1174</a>, <a href="lwg-defects.html#1258">1258</a>, <a href="lwg-defects.html#1260">1260</a>, <a href="lwg-defects.html#1283">1283</a>, <a href="lwg-defects.html#1293">1293</a>, <a href="lwg-defects.html#1307">1307</a>, <a href="lwg-defects.html#1321">1321</a>, <a href="lwg-defects.html#1394">1394</a>, <a href="lwg-defects.html#1405">1405</a>, <a href="lwg-defects.html#1407">1407</a>.</li>
<li>Changed the following 5 issues from New to Resolved: <a href="lwg-defects.html#1290">1290</a>, <a href="lwg-defects.html#1322">1322</a>, <a href="lwg-defects.html#1324">1324</a>, <a href="lwg-defects.html#1326">1326</a>, <a href="lwg-defects.html#1328">1328</a>.</li>
<li>Changed the following 46 issues from Open to Resolved: <a href="lwg-defects.html#801">801</a>, <a href="lwg-defects.html#1268">1268</a>, <a href="lwg-defects.html#1327">1327</a>, <a href="lwg-defects.html#1344">1344</a>, <a href="lwg-defects.html#1346">1346</a>, <a href="lwg-defects.html#1347">1347</a>, <a href="lwg-defects.html#1355">1355</a>, <a href="lwg-defects.html#1356">1356</a>, <a href="lwg-defects.html#1357">1357</a>, <a href="lwg-defects.html#1365">1365</a>, <a href="lwg-defects.html#1366">1366</a>, <a href="lwg-defects.html#1377">1377</a>, <a href="lwg-defects.html#1378">1378</a>, <a href="lwg-defects.html#1379">1379</a>, <a href="lwg-defects.html#1380">1380</a>, <a href="lwg-defects.html#1382">1382</a>, <a href="lwg-defects.html#1383">1383</a>, <a href="lwg-defects.html#1389">1389</a>, <a href="lwg-defects.html#1390">1390</a>, <a href="lwg-defects.html#1391">1391</a>, <a href="lwg-defects.html#1392">1392</a>, <a href="lwg-defects.html#1393">1393</a>, <a href="lwg-defects.html#1397">1397</a>, <a href="lwg-defects.html#1409">1409</a>, <a href="lwg-defects.html#1410">1410</a>, <a href="lwg-defects.html#1412">1412</a>, <a href="lwg-defects.html#1445">1445</a>, <a href="lwg-defects.html#1447">1447</a>, <a href="lwg-defects.html#1453">1453</a>, <a href="lwg-defects.html#1455">1455</a>, <a href="lwg-defects.html#1462">1462</a>, <a href="lwg-defects.html#1464">1464</a>, <a href="lwg-defects.html#1465">1465</a>, <a href="lwg-defects.html#1466">1466</a>, <a href="lwg-defects.html#1467">1467</a>, <a href="lwg-defects.html#1468">1468</a>, <a href="lwg-defects.html#1469">1469</a>, <a href="lwg-defects.html#1481">1481</a>, <a href="lwg-defects.html#1482">1482</a>, <a href="lwg-defects.html#1490">1490</a>, <a href="lwg-defects.html#1491">1491</a>, <a href="lwg-defects.html#1492">1492</a>, <a href="lwg-defects.html#1498">1498</a>, <a href="lwg-defects.html#1501">1501</a>, <a href="lwg-defects.html#1508">1508</a>, <a href="lwg-defects.html#1513">1513</a>.</li>
<li>Changed the following issue from Open to Review: <a href="lwg-defects.html#1480">1480</a>.</li>
<li>Changed the following 2 issues from Open to Tentatively NAD: <a href="lwg-closed.html#1371">1371</a>, <a href="lwg-closed.html#1413">1413</a>.</li>
<li>Changed the following issue from New to Tentatively NAD Future: <a href="lwg-closed.html#1320">1320</a>.</li>
<li>Changed the following 3 issues from New to Tentatively Ready: <a href="lwg-defects.html#1215">1215</a>, <a href="lwg-defects.html#1253">1253</a>, <a href="lwg-defects.html#1310">1310</a>.</li>
<li>Changed the following issue from Open to Tentatively Ready: <a href="lwg-defects.html#1497">1497</a>.</li>
<li>Changed the following 24 issues from NAD Editorial to WP: <a href="lwg-defects.html#1360">1360</a>, <a href="lwg-defects.html#1363">1363</a>, <a href="lwg-defects.html#1367">1367</a>, <a href="lwg-defects.html#1372">1372</a>, <a href="lwg-defects.html#1381">1381</a>, <a href="lwg-defects.html#1384">1384</a>, <a href="lwg-defects.html#1386">1386</a>, <a href="lwg-defects.html#1387">1387</a>, <a href="lwg-defects.html#1388">1388</a>, <a href="lwg-defects.html#1399">1399</a>, <a href="lwg-defects.html#1400">1400</a>, <a href="lwg-defects.html#1402">1402</a>, <a href="lwg-defects.html#1403">1403</a>, <a href="lwg-defects.html#1416">1416</a>, <a href="lwg-defects.html#1417">1417</a>, <a href="lwg-defects.html#1423">1423</a>, <a href="lwg-defects.html#1424">1424</a>, <a href="lwg-defects.html#1425">1425</a>, <a href="lwg-defects.html#1426">1426</a>, <a href="lwg-defects.html#1427">1427</a>, <a href="lwg-defects.html#1429">1429</a>, <a href="lwg-defects.html#1430">1430</a>, <a href="lwg-defects.html#1431">1431</a>, <a href="lwg-defects.html#1441">1441</a>.</li>
<li>Changed the following issue from New to WP: <a href="lwg-defects.html#1294">1294</a>.</li>
<li>Changed the following 10 issues from Open to WP: <a href="lwg-defects.html#1354">1354</a>, <a href="lwg-defects.html#1362">1362</a>, <a href="lwg-defects.html#1368">1368</a>, <a href="lwg-defects.html#1370">1370</a>, <a href="lwg-defects.html#1428">1428</a>, <a href="lwg-defects.html#1435">1435</a>, <a href="lwg-defects.html#1436">1436</a>, <a href="lwg-defects.html#1437">1437</a>, <a href="lwg-defects.html#1439">1439</a>, <a href="lwg-defects.html#1440">1440</a>.</li>
<li>Changed the following 2 issues from Ready to WP: <a href="lwg-defects.html#868">868</a>, <a href="lwg-defects.html#951">951</a>.</li>
<li>Changed the following 33 issues from Tentatively Ready to WP: <a href="lwg-defects.html#956">956</a>, <a href="lwg-defects.html#1118">1118</a>, <a href="lwg-defects.html#1171">1171</a>, <a href="lwg-defects.html#1181">1181</a>, <a href="lwg-defects.html#1183">1183</a>, <a href="lwg-defects.html#1191">1191</a>, <a href="lwg-defects.html#1198">1198</a>, <a href="lwg-defects.html#1207">1207</a>, <a href="lwg-defects.html#1234">1234</a>, <a href="lwg-defects.html#1240">1240</a>, <a href="lwg-defects.html#1249">1249</a>, <a href="lwg-defects.html#1292">1292</a>, <a href="lwg-defects.html#1295">1295</a>, <a href="lwg-defects.html#1316">1316</a>, <a href="lwg-defects.html#1319">1319</a>, <a href="lwg-defects.html#1323">1323</a>, <a href="lwg-defects.html#1325">1325</a>, <a href="lwg-defects.html#1333">1333</a>, <a href="lwg-defects.html#1334">1334</a>, <a href="lwg-defects.html#1335">1335</a>, <a href="lwg-defects.html#1337">1337</a>, <a href="lwg-defects.html#1338">1338</a>, <a href="lwg-defects.html#1339">1339</a>, <a href="lwg-defects.html#1340">1340</a>, <a href="lwg-defects.html#1404">1404</a>, <a href="lwg-defects.html#1414">1414</a>, <a href="lwg-defects.html#1432">1432</a>, <a href="lwg-defects.html#1449">1449</a>, <a href="lwg-defects.html#1516">1516</a>, <a href="lwg-defects.html#1517">1517</a>, <a href="lwg-defects.html#1518">1518</a>, <a href="lwg-defects.html#1519">1519</a>, <a href="lwg-defects.html#1520">1520</a>.</li>
</ul></li>
</ul>
</li>
<li>R72: 
2010-10-18 pre-Batavia mailing.
<ul>
<li><b>Summary:</b><ul>
<li>206 open issues, up by 141.</li>
<li>1314 closed issues, up by 36.</li>
<li>1520 issues total, up by 177.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following Dup issues: <a href="lwg-closed.html#1433">1433</a>, <a href="lwg-closed.html#1444">1444</a>.</li>
<li>Added the following NAD Editorial issues: <a href="lwg-defects.html#1360">1360</a>, <a href="lwg-defects.html#1363">1363</a>, <a href="lwg-defects.html#1367">1367</a>, <a href="lwg-defects.html#1372">1372</a>, <a href="lwg-defects.html#1381">1381</a>, <a href="lwg-defects.html#1384">1384</a>, <a href="lwg-defects.html#1386">1386</a>, <a href="lwg-defects.html#1387">1387</a>, <a href="lwg-defects.html#1388">1388</a>, <a href="lwg-defects.html#1394">1394</a>, <a href="lwg-defects.html#1399">1399</a>, <a href="lwg-defects.html#1400">1400</a>, <a href="lwg-defects.html#1402">1402</a>, <a href="lwg-defects.html#1403">1403</a>, <a href="lwg-defects.html#1405">1405</a>, <a href="lwg-defects.html#1407">1407</a>, <a href="lwg-closed.html#1415">1415</a>, <a href="lwg-defects.html#1416">1416</a>, <a href="lwg-defects.html#1417">1417</a>, <a href="lwg-closed.html#1419">1419</a>, <a href="lwg-defects.html#1423">1423</a>, <a href="lwg-defects.html#1424">1424</a>, <a href="lwg-defects.html#1425">1425</a>, <a href="lwg-defects.html#1426">1426</a>, <a href="lwg-defects.html#1427">1427</a>, <a href="lwg-defects.html#1429">1429</a>, <a href="lwg-defects.html#1430">1430</a>, <a href="lwg-defects.html#1431">1431</a>, <a href="lwg-closed.html#1434">1434</a>, <a href="lwg-defects.html#1441">1441</a>, <a href="lwg-closed.html#1483">1483</a>, <a href="lwg-closed.html#1500">1500</a>, <a href="lwg-closed.html#1506">1506</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#1344">1344</a>, <a href="lwg-defects.html#1345">1345</a>, <a href="lwg-defects.html#1346">1346</a>, <a href="lwg-defects.html#1347">1347</a>, <a href="lwg-closed.html#1348">1348</a>, <a href="lwg-defects.html#1349">1349</a>, <a href="lwg-closed.html#1350">1350</a>, <a href="lwg-closed.html#1351">1351</a>, <a href="lwg-closed.html#1352">1352</a>, <a href="lwg-defects.html#1353">1353</a>, <a href="lwg-defects.html#1354">1354</a>, <a href="lwg-defects.html#1355">1355</a>, <a href="lwg-defects.html#1356">1356</a>, <a href="lwg-defects.html#1357">1357</a>, <a href="lwg-closed.html#1358">1358</a>, <a href="lwg-closed.html#1359">1359</a>, <a href="lwg-closed.html#1361">1361</a>, <a href="lwg-defects.html#1362">1362</a>, <a href="lwg-defects.html#1364">1364</a>, <a href="lwg-defects.html#1365">1365</a>, <a href="lwg-defects.html#1366">1366</a>, <a href="lwg-defects.html#1368">1368</a>, <a href="lwg-closed.html#1369">1369</a>, <a href="lwg-defects.html#1370">1370</a>, <a href="lwg-closed.html#1371">1371</a>, <a href="lwg-closed.html#1373">1373</a>, <a href="lwg-closed.html#1374">1374</a>, <a href="lwg-closed.html#1375">1375</a>, <a href="lwg-closed.html#1376">1376</a>, <a href="lwg-defects.html#1377">1377</a>, <a href="lwg-defects.html#1378">1378</a>, <a href="lwg-defects.html#1379">1379</a>, <a href="lwg-defects.html#1380">1380</a>, <a href="lwg-defects.html#1382">1382</a>, <a href="lwg-defects.html#1383">1383</a>, <a href="lwg-defects.html#1385">1385</a>, <a href="lwg-defects.html#1389">1389</a>, <a href="lwg-defects.html#1390">1390</a>, <a href="lwg-defects.html#1391">1391</a>, <a href="lwg-defects.html#1392">1392</a>, <a href="lwg-defects.html#1393">1393</a>, <a href="lwg-closed.html#1395">1395</a>, <a href="lwg-closed.html#1396">1396</a>, <a href="lwg-defects.html#1397">1397</a>, <a href="lwg-closed.html#1398">1398</a>, <a href="lwg-defects.html#1401">1401</a>, <a href="lwg-closed.html#1406">1406</a>, <a href="lwg-defects.html#1408">1408</a>, <a href="lwg-defects.html#1409">1409</a>, <a href="lwg-defects.html#1410">1410</a>, <a href="lwg-closed.html#1411">1411</a>, <a href="lwg-defects.html#1412">1412</a>, <a href="lwg-closed.html#1413">1413</a>, <a href="lwg-defects.html#1418">1418</a>, <a href="lwg-defects.html#1420">1420</a>, <a href="lwg-defects.html#1421">1421</a>, <a href="lwg-closed.html#1422">1422</a>, <a href="lwg-defects.html#1428">1428</a>, <a href="lwg-defects.html#1435">1435</a>, <a href="lwg-defects.html#1436">1436</a>, <a href="lwg-defects.html#1437">1437</a>, <a href="lwg-defects.html#1438">1438</a>, <a href="lwg-defects.html#1439">1439</a>, <a href="lwg-defects.html#1440">1440</a>, <a href="lwg-closed.html#1442">1442</a>, <a href="lwg-closed.html#1443">1443</a>, <a href="lwg-defects.html#1445">1445</a>, <a href="lwg-closed.html#1446">1446</a>, <a href="lwg-defects.html#1447">1447</a>, <a href="lwg-defects.html#1448">1448</a>, <a href="lwg-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-defects.html#1474">1474</a>, <a href="lwg-closed.html#1475">1475</a>, <a href="lwg-closed.html#1476">1476</a>, <a href="lwg-closed.html#1477">1477</a>, <a href="lwg-defects.html#1478">1478</a>, <a href="lwg-defects.html#1479">1479</a>, <a href="lwg-defects.html#1480">1480</a>, <a href="lwg-defects.html#1481">1481</a>, <a href="lwg-defects.html#1482">1482</a>, <a href="lwg-closed.html#1484">1484</a>, <a href="lwg-closed.html#1485">1485</a>, <a href="lwg-closed.html#1486">1486</a>, <a href="lwg-defects.html#1487">1487</a>, <a href="lwg-closed.html#1488">1488</a>, <a href="lwg-closed.html#1489">1489</a>, <a href="lwg-defects.html#1490">1490</a>, <a href="lwg-defects.html#1491">1491</a>, <a href="lwg-defects.html#1492">1492</a>, <a href="lwg-closed.html#1493">1493</a>, <a href="lwg-defects.html#1494">1494</a>, <a href="lwg-closed.html#1495">1495</a>, <a href="lwg-closed.html#1496">1496</a>, <a href="lwg-defects.html#1497">1497</a>, <a href="lwg-defects.html#1498">1498</a>, <a href="lwg-closed.html#1499">1499</a>, <a href="lwg-defects.html#1501">1501</a>, <a href="lwg-defects.html#1502">1502</a>, <a href="lwg-closed.html#1503">1503</a>, <a href="lwg-defects.html#1504">1504</a>, <a href="lwg-defects.html#1505">1505</a>, <a href="lwg-defects.html#1507">1507</a>, <a href="lwg-defects.html#1508">1508</a>, <a href="lwg-closed.html#1509">1509</a>, <a href="lwg-closed.html#1510">1510</a>, <a href="lwg-closed.html#1511">1511</a>, <a href="lwg-closed.html#1512">1512</a>, <a href="lwg-defects.html#1513">1513</a>, <a href="lwg-defects.html#1514">1514</a>, <a href="lwg-defects.html#1515">1515</a>.</li>
<li>Added the following Tentatively Ready issues: <a href="lwg-defects.html#1404">1404</a>, <a href="lwg-defects.html#1414">1414</a>, <a href="lwg-defects.html#1432">1432</a>, <a href="lwg-defects.html#1449">1449</a>, <a href="lwg-defects.html#1516">1516</a>, <a href="lwg-defects.html#1517">1517</a>, <a href="lwg-defects.html#1518">1518</a>, <a href="lwg-defects.html#1519">1519</a>, <a href="lwg-defects.html#1520">1520</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#1260">1260</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#1181">1181</a>, <a href="lwg-defects.html#1240">1240</a>, <a href="lwg-defects.html#1249">1249</a>, <a href="lwg-defects.html#1292">1292</a>, <a href="lwg-defects.html#1295">1295</a>, <a href="lwg-defects.html#1316">1316</a>, <a href="lwg-defects.html#1319">1319</a>, <a href="lwg-defects.html#1323">1323</a>, <a href="lwg-defects.html#1325">1325</a>, <a href="lwg-defects.html#1333">1333</a>, <a href="lwg-defects.html#1334">1334</a>, <a href="lwg-defects.html#1335">1335</a>, <a href="lwg-defects.html#1337">1337</a>, <a href="lwg-defects.html#1338">1338</a>, <a href="lwg-defects.html#1339">1339</a>, <a href="lwg-defects.html#1340">1340</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#956">956</a>, <a href="lwg-defects.html#1118">1118</a>, <a href="lwg-defects.html#1183">1183</a>, <a href="lwg-defects.html#1234">1234</a>.</li>
</ul></li>
</ul>
</li>
<li>R71: 
2010-08-25 post-Rapperswil mailing.
<ul>
<li><b>Summary:</b><ul>
<li>65 open issues, up by 2.</li>
<li>1278 closed issues, up by 7.</li>
<li>1343 issues total, up by 9.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#1335">1335</a>, <a href="lwg-defects.html#2008">2008</a>, <a href="lwg-defects.html#1337">1337</a>, <a href="lwg-defects.html#1338">1338</a>, <a href="lwg-defects.html#1339">1339</a>, <a href="lwg-defects.html#1340">1340</a>, <a href="lwg-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-closed.html#1320">1320</a>, <a href="lwg-defects.html#1322">1322</a>, <a href="lwg-defects.html#1323">1323</a>, <a href="lwg-defects.html#1324">1324</a>, <a href="lwg-defects.html#1325">1325</a>, <a href="lwg-defects.html#1326">1326</a>, <a href="lwg-defects.html#1328">1328</a>, <a href="lwg-closed.html#1330">1330</a>, <a href="lwg-closed.html#1331">1331</a>, <a href="lwg-defects.html#1332">1332</a>, <a href="lwg-defects.html#1333">1333</a>, <a href="lwg-defects.html#1334">1334</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#1327">1327</a>.</li>
<li>Changed the following issues from Tentatively Dup to Dup: <a href="lwg-closed.html#1219">1219</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#1302">1302</a>, <a href="lwg-closed.html#1308">1308</a>, <a href="lwg-closed.html#1313">1313</a>, <a href="lwg-closed.html#1314">1314</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#887">887</a>, <a href="lwg-closed.html#1008">1008</a>, <a href="lwg-closed.html#1068">1068</a>, <a href="lwg-closed.html#1069">1069</a>, <a href="lwg-closed.html#1153">1153</a>, <a href="lwg-closed.html#1156">1156</a>, <a href="lwg-closed.html#1228">1228</a>.</li>
<li>Changed the following issues from Tentatively NAD to NAD: <a href="lwg-closed.html#631">631</a>, <a href="lwg-closed.html#726">726</a>, <a href="lwg-closed.html#959">959</a>, <a href="lwg-closed.html#1056">1056</a>, <a href="lwg-closed.html#1099">1099</a>, <a href="lwg-closed.html#1125">1125</a>, <a href="lwg-closed.html#1176">1176</a>, <a href="lwg-closed.html#1202">1202</a>, <a href="lwg-closed.html#1223">1223</a>, <a href="lwg-closed.html#1224">1224</a>, <a href="lwg-closed.html#1246">1246</a>, <a href="lwg-closed.html#1251">1251</a>, <a href="lwg-closed.html#1259">1259</a>, <a href="lwg-closed.html#1263">1263</a>, <a href="lwg-closed.html#1265">1265</a>, <a href="lwg-closed.html#1296">1296</a>.</li>
<li>Changed the following issues from Tentatively NAD Concepts to NAD Concepts: <a href="lwg-closed.html#910">910</a>, <a href="lwg-closed.html#1186">1186</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#1185">1185</a>, <a href="lwg-defects.html#1210">1210</a>, <a href="lwg-defects.html#1212">1212</a>, <a href="lwg-defects.html#1225">1225</a>, <a href="lwg-defects.html#1244">1244</a>, <a href="lwg-defects.html#1266">1266</a>, <a href="lwg-defects.html#1269">1269</a>, <a href="lwg-defects.html#1272">1272</a>, <a href="lwg-defects.html#1275">1275</a>, <a href="lwg-defects.html#1291">1291</a>, <a href="lwg-defects.html#1305">1305</a>, <a href="lwg-defects.html#1307">1307</a>, <a href="lwg-defects.html#1311">1311</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#299">299</a>, <a href="lwg-closed.html#397">397</a>, <a href="lwg-closed.html#408">408</a>, <a href="lwg-closed.html#446">446</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-defects.html#625">625</a>, <a href="lwg-defects.html#742">742</a>, <a href="lwg-defects.html#834">834</a>, <a href="lwg-closed.html#915">915</a>, <a href="lwg-defects.html#1093">1093</a>, <a href="lwg-defects.html#1151">1151</a>, <a href="lwg-defects.html#1211">1211</a>, <a href="lwg-defects.html#1248">1248</a>.</li>
<li>Changed the following issues from Ready to NAD Editorial: <a href="lwg-defects.html#485">485</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#983">983</a>, <a href="lwg-defects.html#1100">1100</a>, <a href="lwg-defects.html#1135">1135</a>.</li>
<li>Changed the following issues from Tentatively NAD Editorial to NAD Editorial: <a href="lwg-defects.html#815">815</a>, <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#889">889</a>, <a href="lwg-defects.html#1106">1106</a>, <a href="lwg-closed.html#1115">1115</a>, <a href="lwg-closed.html#1233">1233</a>, <a href="lwg-closed.html#1239">1239</a>, <a href="lwg-defects.html#1258">1258</a>, <a href="lwg-defects.html#1283">1283</a>, <a href="lwg-closed.html#1301">1301</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="lwg-defects.html#1090">1090</a>, <a href="lwg-defects.html#1226">1226</a>, <a href="lwg-defects.html#1273">1273</a>, <a href="lwg-defects.html#1274">1274</a>, <a href="lwg-defects.html#1293">1293</a>, <a href="lwg-defects.html#1300">1300</a>, <a href="lwg-defects.html#1304">1304</a>, <a href="lwg-closed.html#1315">1315</a>.</li>
<li>Changed the following issues from New to NAD Future: <a href="lwg-closed.html#1154">1154</a>, <a href="lwg-closed.html#1317">1317</a>.</li>
<li>Changed the following issues from Ready to NAD Future: <a href="lwg-closed.html#1052">1052</a>.</li>
<li>Changed the following issues from Tentatively NAD Future to NAD Future: <a href="lwg-closed.html#1112">1112</a>, <a href="lwg-closed.html#1121">1121</a>, <a href="lwg-closed.html#1201">1201</a>, <a href="lwg-closed.html#1238">1238</a>, <a href="lwg-closed.html#1282">1282</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#1234">1234</a>, <a href="lwg-defects.html#1268">1268</a>.</li>
<li>Changed the following issues from Tentatively Ready to Open: <a href="lwg-closed.html#579">579</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#1187">1187</a>, <a href="lwg-defects.html#1206">1206</a>, <a href="lwg-defects.html#1278">1278</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#1281">1281</a>.</li>
<li>Changed the following issues from Ready to Review: <a href="lwg-defects.html#868">868</a>.</li>
<li>Changed the following issues from New to WP: <a href="lwg-defects.html#1159">1159</a>.</li>
<li>Changed the following issues from Open to WP: <a href="lwg-defects.html#427">427</a>, <a href="lwg-defects.html#430">430</a>, <a href="lwg-defects.html#774">774</a>, <a href="lwg-defects.html#819">819</a>, <a href="lwg-defects.html#835">835</a>, <a href="lwg-defects.html#861">861</a>, <a href="lwg-defects.html#885">885</a>, <a href="lwg-defects.html#896">896</a>, <a href="lwg-defects.html#900">900</a>, <a href="lwg-defects.html#911">911</a>, <a href="lwg-defects.html#1079">1079</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#296">296</a>, <a href="lwg-defects.html#471">471</a>, <a href="lwg-defects.html#473">473</a>, <a href="lwg-defects.html#539">539</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-defects.html#854">854</a>, <a href="lwg-defects.html#860">860</a>, <a href="lwg-defects.html#865">865</a>, <a href="lwg-defects.html#871">871</a>, <a href="lwg-defects.html#872">872</a>, <a href="lwg-defects.html#920">920</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-defects.html#957">957</a>, <a href="lwg-defects.html#960">960</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#963">963</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#1011">1011</a>, <a href="lwg-defects.html#1030">1030</a>, <a href="lwg-defects.html#1094">1094</a>, <a href="lwg-defects.html#1095">1095</a>, <a href="lwg-defects.html#1097">1097</a>, <a href="lwg-defects.html#1098">1098</a>, <a href="lwg-defects.html#1104">1104</a>, <a href="lwg-defects.html#1123">1123</a>, <a href="lwg-defects.html#1134">1134</a>, <a href="lwg-defects.html#1136">1136</a>, <a href="lwg-defects.html#1144">1144</a>, <a href="lwg-defects.html#1157">1157</a>, <a href="lwg-defects.html#1194">1194</a>, <a href="lwg-defects.html#1204">1204</a>, <a href="lwg-defects.html#1216">1216</a>, <a href="lwg-defects.html#1227">1227</a>, <a href="lwg-defects.html#1237">1237</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="lwg-defects.html#556">556</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#780">780</a>, <a href="lwg-defects.html#811">811</a>, <a href="lwg-defects.html#817">817</a>, <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#891">891</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-defects.html#987">987</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-defects.html#1033">1033</a>, <a href="lwg-defects.html#1034">1034</a>, <a href="lwg-defects.html#1071">1071</a>, <a href="lwg-defects.html#1089">1089</a>, <a href="lwg-defects.html#1108">1108</a>, <a href="lwg-defects.html#1110">1110</a>, <a href="lwg-defects.html#1113">1113</a>, <a href="lwg-defects.html#1114">1114</a>, <a href="lwg-defects.html#1126">1126</a>, <a href="lwg-defects.html#1130">1130</a>, <a href="lwg-defects.html#1131">1131</a>, <a href="lwg-defects.html#1133">1133</a>, <a href="lwg-defects.html#1137">1137</a>, <a href="lwg-defects.html#1138">1138</a>, <a href="lwg-defects.html#1152">1152</a>, <a href="lwg-defects.html#1158">1158</a>, <a href="lwg-defects.html#1170">1170</a>, <a href="lwg-defects.html#1177">1177</a>, <a href="lwg-defects.html#1180">1180</a>, <a href="lwg-defects.html#1182">1182</a>, <a href="lwg-defects.html#1189">1189</a>, <a href="lwg-defects.html#1192">1192</a>, <a href="lwg-defects.html#1193">1193</a>, <a href="lwg-defects.html#1195">1195</a>, <a href="lwg-defects.html#1197">1197</a>, <a href="lwg-defects.html#1199">1199</a>, <a href="lwg-defects.html#1205">1205</a>, <a href="lwg-defects.html#1208">1208</a>, <a href="lwg-defects.html#1209">1209</a>, <a href="lwg-defects.html#1218">1218</a>, <a href="lwg-defects.html#1220">1220</a>, <a href="lwg-defects.html#1221">1221</a>, <a href="lwg-defects.html#1222">1222</a>, <a href="lwg-defects.html#1231">1231</a>, <a href="lwg-defects.html#1241">1241</a>, <a href="lwg-defects.html#1245">1245</a>, <a href="lwg-defects.html#1247">1247</a>, <a href="lwg-defects.html#1250">1250</a>, <a href="lwg-defects.html#1254">1254</a>, <a href="lwg-defects.html#1255">1255</a>, <a href="lwg-defects.html#1256">1256</a>, <a href="lwg-defects.html#1257">1257</a>, <a href="lwg-defects.html#1261">1261</a>, <a href="lwg-defects.html#1262">1262</a>, <a href="lwg-defects.html#1264">1264</a>, <a href="lwg-defects.html#1267">1267</a>, <a href="lwg-defects.html#1270">1270</a>, <a href="lwg-defects.html#1271">1271</a>, <a href="lwg-defects.html#1276">1276</a>, <a href="lwg-defects.html#1277">1277</a>, <a href="lwg-defects.html#1280">1280</a>, <a href="lwg-defects.html#1284">1284</a>, <a href="lwg-defects.html#1285">1285</a>, <a href="lwg-defects.html#1286">1286</a>, <a href="lwg-defects.html#1287">1287</a>, <a href="lwg-defects.html#1288">1288</a>, <a href="lwg-defects.html#1298">1298</a>, <a href="lwg-defects.html#1299">1299</a>, <a href="lwg-defects.html#1303">1303</a>, <a href="lwg-defects.html#1306">1306</a>, <a href="lwg-defects.html#1309">1309</a>, <a href="lwg-defects.html#1312">1312</a>.</li>
</ul></li>
</ul>
</li>
<li>R69: 
2010-02-12 pre-Pittsburgh mailing.
<ul>
<li><b>Summary:</b><ul>
<li>266 open issues, up by 61.</li>
<li>1052 closed issues, down by 3.</li>
<li>1318 issues total, up by 58.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#1266">1266</a>, <a href="lwg-defects.html#1268">1268</a>, <a href="lwg-defects.html#1269">1269</a>, <a href="lwg-defects.html#1272">1272</a>, <a href="lwg-defects.html#1275">1275</a>, <a href="lwg-defects.html#1278">1278</a>, <a href="lwg-defects.html#1279">1279</a>, <a href="lwg-defects.html#1281">1281</a>, <a href="lwg-closed.html#1289">1289</a>, <a href="lwg-defects.html#1290">1290</a>, <a href="lwg-defects.html#1291">1291</a>, <a href="lwg-defects.html#1292">1292</a>, <a href="lwg-defects.html#1294">1294</a>, <a href="lwg-defects.html#1295">1295</a>, <a href="lwg-defects.html#1297">1297</a>, <a href="lwg-closed.html#1302">1302</a>, <a href="lwg-defects.html#1305">1305</a>, <a href="lwg-defects.html#1307">1307</a>, <a href="lwg-closed.html#1308">1308</a>, <a href="lwg-defects.html#1310">1310</a>, <a href="lwg-defects.html#1311">1311</a>, <a href="lwg-closed.html#1313">1313</a>, <a href="lwg-closed.html#1314">1314</a>, <a href="lwg-defects.html#1316">1316</a>, <a href="lwg-closed.html#1317">1317</a>, <a href="lwg-closed.html#1318">1318</a>.</li>
<li>Added the following Tentatively NAD issues: <a href="lwg-closed.html#1263">1263</a>, <a href="lwg-closed.html#1265">1265</a>, <a href="lwg-closed.html#1296">1296</a>.</li>
<li>Added the following Tentatively NAD Editorial issues: <a href="lwg-defects.html#1283">1283</a>, <a href="lwg-closed.html#1301">1301</a>.</li>
<li>Added the following Tentatively NAD Future issues: <a href="lwg-closed.html#1282">1282</a>.</li>
<li>Added the following Tentatively Ready issues: <a href="lwg-defects.html#1261">1261</a>, <a href="lwg-defects.html#1262">1262</a>, <a href="lwg-defects.html#1264">1264</a>, <a href="lwg-defects.html#1267">1267</a>, <a href="lwg-defects.html#1270">1270</a>, <a href="lwg-defects.html#1271">1271</a>, <a href="lwg-defects.html#1273">1273</a>, <a href="lwg-defects.html#1274">1274</a>, <a href="lwg-defects.html#1276">1276</a>, <a href="lwg-defects.html#1277">1277</a>, <a href="lwg-defects.html#1280">1280</a>, <a href="lwg-defects.html#1284">1284</a>, <a href="lwg-defects.html#1285">1285</a>, <a href="lwg-defects.html#1286">1286</a>, <a href="lwg-defects.html#1287">1287</a>, <a href="lwg-defects.html#1288">1288</a>, <a href="lwg-defects.html#1293">1293</a>, <a href="lwg-defects.html#1298">1298</a>, <a href="lwg-defects.html#1299">1299</a>, <a href="lwg-defects.html#1300">1300</a>, <a href="lwg-defects.html#1303">1303</a>, <a href="lwg-defects.html#1304">1304</a>, <a href="lwg-defects.html#1306">1306</a>, <a href="lwg-defects.html#1309">1309</a>, <a href="lwg-defects.html#1312">1312</a>, <a href="lwg-closed.html#1315">1315</a>.</li>
<li>Changed the following issues from NAD to NAD Editorial: <a href="lwg-closed.html#101">101</a>.</li>
<li>Changed the following issues from NAD Future to Open: <a href="lwg-defects.html#1248">1248</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#1207">1207</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="lwg-defects.html#1079">1079</a>.</li>
<li>Changed the following issues from New to Tentatively Dup: <a href="lwg-closed.html#1219">1219</a>.</li>
<li>Changed the following issues from New to Tentatively NAD: <a href="lwg-closed.html#1125">1125</a>, <a href="lwg-closed.html#1176">1176</a>, <a href="lwg-closed.html#1202">1202</a>, <a href="lwg-closed.html#1223">1223</a>, <a href="lwg-closed.html#1224">1224</a>, <a href="lwg-closed.html#1246">1246</a>, <a href="lwg-closed.html#1251">1251</a>, <a href="lwg-closed.html#1259">1259</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD: <a href="lwg-closed.html#726">726</a>, <a href="lwg-closed.html#959">959</a>.</li>
<li>Changed the following issues from Review to Tentatively NAD: <a href="lwg-closed.html#631">631</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Concepts: <a href="lwg-closed.html#910">910</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="lwg-defects.html#1258">1258</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="lwg-defects.html#815">815</a>, <a href="lwg-defects.html#1106">1106</a>.</li>
<li>Changed the following issues from Ready to Tentatively NAD Editorial: <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#889">889</a>.</li>
<li>Changed the following issues from NAD to Tentatively Ready: <a href="lwg-closed.html#579">579</a>.</li>
<li>Changed the following issues from NAD Editorial to Tentatively Ready: <a href="lwg-defects.html#1195">1195</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#1131">1131</a>, <a href="lwg-defects.html#1133">1133</a>, <a href="lwg-defects.html#1137">1137</a>, <a href="lwg-defects.html#1170">1170</a>, <a href="lwg-defects.html#1180">1180</a>, <a href="lwg-defects.html#1182">1182</a>, <a href="lwg-defects.html#1193">1193</a>, <a href="lwg-defects.html#1197">1197</a>, <a href="lwg-defects.html#1199">1199</a>, <a href="lwg-defects.html#1205">1205</a>, <a href="lwg-defects.html#1209">1209</a>, <a href="lwg-defects.html#1218">1218</a>, <a href="lwg-defects.html#1221">1221</a>, <a href="lwg-defects.html#1222">1222</a>, <a href="lwg-defects.html#1245">1245</a>, <a href="lwg-defects.html#1250">1250</a>, <a href="lwg-defects.html#1254">1254</a>, <a href="lwg-defects.html#1255">1255</a>, <a href="lwg-defects.html#1256">1256</a>, <a href="lwg-defects.html#1257">1257</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#811">811</a>, <a href="lwg-defects.html#817">817</a>, <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#891">891</a>, <a href="lwg-defects.html#1033">1033</a>, <a href="lwg-defects.html#1034">1034</a>, <a href="lwg-defects.html#1089">1089</a>, <a href="lwg-defects.html#1110">1110</a>.</li>
<li>Changed the following issues from Ready to Tentatively Ready: <a href="lwg-defects.html#893">893</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-defects.html#1177">1177</a>.</li>
<li>Changed the following issues from Review to Tentatively Ready: <a href="lwg-defects.html#556">556</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#780">780</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-defects.html#1130">1130</a>, <a href="lwg-defects.html#1247">1247</a>.</li>
<li>Changed the following issues from Pending WP to WP: <a href="lwg-defects.html#970">970</a>.</li>
</ul></li>
</ul>
</li>
<li>R68: 
2009-11-06 post-Santa Cruz mailing.
<ul>
<li><b>Summary:</b><ul>
<li>205 open issues, down by 77.</li>
<li>1055 closed issues, up by 120.</li>
<li>1260 issues total, up by 43.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following Dup issues: <a href="lwg-closed.html#1230">1230</a>.</li>
<li>Added the following NAD issues: <a href="lwg-defects.html#1229">1229</a>, <a href="lwg-closed.html#1236">1236</a>, <a href="lwg-closed.html#1243">1243</a>.</li>
<li>Added the following NAD Editorial issues: <a href="lwg-closed.html#1232">1232</a>.</li>
<li>Added the following NAD Future issues: <a href="lwg-closed.html#1235">1235</a>, <a href="lwg-closed.html#1242">1242</a>, <a href="lwg-defects.html#1248">1248</a>.</li>
<li>Added the following New issues: <a href="lwg-defects.html#1218">1218</a>, <a href="lwg-closed.html#1219">1219</a>, <a href="lwg-defects.html#1221">1221</a>, <a href="lwg-defects.html#1222">1222</a>, <a href="lwg-closed.html#1223">1223</a>, <a href="lwg-closed.html#1224">1224</a>, <a href="lwg-defects.html#1225">1225</a>, <a href="lwg-defects.html#1234">1234</a>, <a href="lwg-defects.html#1240">1240</a>, <a href="lwg-defects.html#1244">1244</a>, <a href="lwg-defects.html#1245">1245</a>, <a href="lwg-closed.html#1246">1246</a>, <a href="lwg-defects.html#1249">1249</a>, <a href="lwg-defects.html#1250">1250</a>, <a href="lwg-closed.html#1251">1251</a>, <a href="lwg-defects.html#1252">1252</a>, <a href="lwg-defects.html#1253">1253</a>, <a href="lwg-defects.html#1254">1254</a>, <a href="lwg-defects.html#1255">1255</a>, <a href="lwg-defects.html#1256">1256</a>, <a href="lwg-defects.html#1257">1257</a>, <a href="lwg-defects.html#1258">1258</a>, <a href="lwg-closed.html#1259">1259</a>, <a href="lwg-defects.html#1260">1260</a>.</li>
<li>Added the following Open issues: <a href="lwg-closed.html#1228">1228</a>.</li>
<li>Added the following Ready issues: <a href="lwg-defects.html#1227">1227</a>, <a href="lwg-defects.html#1237">1237</a>.</li>
<li>Added the following Review issues: <a href="lwg-defects.html#1247">1247</a>.</li>
<li>Added the following Tentatively NAD Editorial issues: <a href="lwg-closed.html#1233">1233</a>, <a href="lwg-closed.html#1239">1239</a>.</li>
<li>Added the following Tentatively NAD Future issues: <a href="lwg-closed.html#1238">1238</a>.</li>
<li>Added the following Tentatively Ready issues: <a href="lwg-defects.html#1220">1220</a>, <a href="lwg-defects.html#1226">1226</a>, <a href="lwg-defects.html#1231">1231</a>, <a href="lwg-defects.html#1241">1241</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#1132">1132</a>, <a href="lwg-closed.html#1148">1148</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#96">96</a>, <a href="lwg-closed.html#458">458</a>, <a href="lwg-closed.html#463">463</a>, <a href="lwg-closed.html#916">916</a>, <a href="lwg-closed.html#917">917</a>, <a href="lwg-closed.html#919">919</a>, <a href="lwg-closed.html#955">955</a>, <a href="lwg-closed.html#977">977</a>, <a href="lwg-closed.html#1009">1009</a>, <a href="lwg-closed.html#1020">1020</a>, <a href="lwg-closed.html#1035">1035</a>, <a href="lwg-closed.html#1042">1042</a>, <a href="lwg-closed.html#1051">1051</a>, <a href="lwg-closed.html#1064">1064</a>.</li>
<li>Changed the following issues from Review to NAD: <a href="lwg-closed.html#668">668</a>, <a href="lwg-closed.html#930">930</a>, <a href="lwg-closed.html#1091">1091</a>, <a href="lwg-closed.html#1102">1102</a>.</li>
<li>Changed the following issues from Tentatively NAD to NAD: <a href="lwg-closed.html#588">588</a>, <a href="lwg-closed.html#617">617</a>, <a href="lwg-closed.html#971">971</a>.</li>
<li>Changed the following issues from Tentatively NAD Future to NAD: <a href="lwg-closed.html#1062">1062</a>.</li>
<li>Changed the following issues from NAD Concepts to NAD Editorial: <a href="lwg-defects.html#1143">1143</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#1116">1116</a>, <a href="lwg-defects.html#1117">1117</a>, <a href="lwg-defects.html#1122">1122</a>, <a href="lwg-defects.html#1129">1129</a>, <a href="lwg-defects.html#1145">1145</a>, <a href="lwg-defects.html#1146">1146</a>, <a href="lwg-defects.html#1147">1147</a>, <a href="lwg-closed.html#1155">1155</a>, <a href="lwg-defects.html#1166">1166</a>, <a href="lwg-defects.html#1172">1172</a>, <a href="lwg-defects.html#1174">1174</a>, <a href="lwg-closed.html#1179">1179</a>, <a href="lwg-defects.html#1195">1195</a>, <a href="lwg-defects.html#1196">1196</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-defects.html#431">431</a>, <a href="lwg-closed.html#580">580</a>, <a href="lwg-defects.html#635">635</a>, <a href="lwg-defects.html#719">719</a>, <a href="lwg-defects.html#823">823</a>, <a href="lwg-defects.html#827">827</a>, <a href="lwg-closed.html#879">879</a>, <a href="lwg-defects.html#880">880</a>, <a href="lwg-defects.html#908">908</a>, <a href="lwg-defects.html#923">923</a>, <a href="lwg-defects.html#924">924</a>, <a href="lwg-closed.html#926">926</a>, <a href="lwg-defects.html#944">944</a>, <a href="lwg-defects.html#947">947</a>, <a href="lwg-defects.html#958">958</a>, <a href="lwg-defects.html#1046">1046</a>, <a href="lwg-defects.html#1048">1048</a>, <a href="lwg-defects.html#1054">1054</a>, <a href="lwg-defects.html#1055">1055</a>, <a href="lwg-defects.html#1075">1075</a>, <a href="lwg-defects.html#1088">1088</a>, <a href="lwg-defects.html#1160">1160</a>, <a href="lwg-defects.html#1161">1161</a>, <a href="lwg-defects.html#1162">1162</a>, <a href="lwg-defects.html#1163">1163</a>, <a href="lwg-defects.html#1165">1165</a>.</li>
<li>Changed the following issues from Review to NAD Editorial: <a href="lwg-defects.html#828">828</a>, <a href="lwg-defects.html#897">897</a>, <a href="lwg-defects.html#976">976</a>, <a href="lwg-defects.html#1043">1043</a>, <a href="lwg-defects.html#1047">1047</a>, <a href="lwg-defects.html#1049">1049</a>, <a href="lwg-defects.html#1050">1050</a>.</li>
<li>Changed the following issues from New to NAD Future: <a href="lwg-closed.html#1120">1120</a>, <a href="lwg-closed.html#1150">1150</a>, <a href="lwg-closed.html#1184">1184</a>, <a href="lwg-closed.html#1203">1203</a>, <a href="lwg-closed.html#1217">1217</a>.</li>
<li>Changed the following issues from Open to NAD Future: <a href="lwg-closed.html#484">484</a>, <a href="lwg-closed.html#532">532</a>, <a href="lwg-closed.html#851">851</a>, <a href="lwg-closed.html#933">933</a>, <a href="lwg-closed.html#935">935</a>, <a href="lwg-closed.html#936">936</a>, <a href="lwg-closed.html#961">961</a>, <a href="lwg-closed.html#1041">1041</a>, <a href="lwg-closed.html#1053">1053</a>.</li>
<li>Changed the following issues from Tentatively NAD Future to NAD Future: <a href="lwg-closed.html#1031">1031</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#1118">1118</a>, <a href="lwg-closed.html#1119">1119</a>, <a href="lwg-defects.html#1151">1151</a>, <a href="lwg-closed.html#1153">1153</a>, <a href="lwg-closed.html#1156">1156</a>, <a href="lwg-defects.html#1171">1171</a>, <a href="lwg-closed.html#1173">1173</a>, <a href="lwg-defects.html#1183">1183</a>, <a href="lwg-defects.html#1191">1191</a>, <a href="lwg-defects.html#1211">1211</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="lwg-defects.html#430">430</a>, <a href="lwg-defects.html#834">834</a>.</li>
<li>Changed the following issues from Review to Open: <a href="lwg-closed.html#397">397</a>, <a href="lwg-closed.html#408">408</a>, <a href="lwg-defects.html#835">835</a>.</li>
<li>Changed the following issues from Tentatively NAD to Open: <a href="lwg-defects.html#625">625</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#1123">1123</a>, <a href="lwg-defects.html#1134">1134</a>, <a href="lwg-defects.html#1135">1135</a>, <a href="lwg-defects.html#1136">1136</a>, <a href="lwg-defects.html#1144">1144</a>, <a href="lwg-defects.html#1177">1177</a>, <a href="lwg-defects.html#1194">1194</a>, <a href="lwg-defects.html#1204">1204</a>, <a href="lwg-defects.html#1216">1216</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#296">296</a>, <a href="lwg-defects.html#471">471</a>, <a href="lwg-defects.html#485">485</a>, <a href="lwg-defects.html#539">539</a>, <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#860">860</a>, <a href="lwg-defects.html#865">865</a>, <a href="lwg-defects.html#872">872</a>, <a href="lwg-defects.html#920">920</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#960">960</a>, <a href="lwg-defects.html#963">963</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-defects.html#1011">1011</a>, <a href="lwg-defects.html#1030">1030</a>, <a href="lwg-defects.html#1079">1079</a>, <a href="lwg-defects.html#1098">1098</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#473">473</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-defects.html#854">854</a>, <a href="lwg-defects.html#868">868</a>, <a href="lwg-defects.html#871">871</a>, <a href="lwg-defects.html#889">889</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-defects.html#957">957</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>, <a href="lwg-defects.html#983">983</a>, <a href="lwg-closed.html#1052">1052</a>, <a href="lwg-defects.html#1094">1094</a>, <a href="lwg-defects.html#1095">1095</a>, <a href="lwg-defects.html#1097">1097</a>, <a href="lwg-defects.html#1100">1100</a>, <a href="lwg-defects.html#1104">1104</a>, <a href="lwg-defects.html#1157">1157</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#1130">1130</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#556">556</a>, <a href="lwg-closed.html#631">631</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#929">929</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD: <a href="lwg-closed.html#1056">1056</a>, <a href="lwg-closed.html#1099">1099</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Concepts: <a href="lwg-closed.html#1186">1186</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="lwg-closed.html#1115">1115</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Future: <a href="lwg-closed.html#1121">1121</a>, <a href="lwg-closed.html#1201">1201</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Future: <a href="lwg-closed.html#1112">1112</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#1126">1126</a>, <a href="lwg-defects.html#1138">1138</a>, <a href="lwg-defects.html#1152">1152</a>, <a href="lwg-defects.html#1158">1158</a>, <a href="lwg-defects.html#1189">1189</a>, <a href="lwg-defects.html#1192">1192</a>, <a href="lwg-defects.html#1208">1208</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#987">987</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-defects.html#1071">1071</a>, <a href="lwg-defects.html#1090">1090</a>, <a href="lwg-defects.html#1108">1108</a>, <a href="lwg-defects.html#1113">1113</a>, <a href="lwg-defects.html#1114">1114</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#149">149</a>, <a href="lwg-defects.html#419">419</a>, <a href="lwg-defects.html#498">498</a>, <a href="lwg-defects.html#564">564</a>, <a href="lwg-defects.html#565">565</a>, <a href="lwg-defects.html#630">630</a>, <a href="lwg-defects.html#659">659</a>, <a href="lwg-defects.html#696">696</a>, <a href="lwg-defects.html#711">711</a>, <a href="lwg-defects.html#716">716</a>, <a href="lwg-defects.html#723">723</a>, <a href="lwg-defects.html#788">788</a>, <a href="lwg-closed.html#822">822</a>, <a href="lwg-defects.html#838">838</a>, <a href="lwg-defects.html#847">847</a>, <a href="lwg-defects.html#857">857</a>, <a href="lwg-defects.html#859">859</a>, <a href="lwg-defects.html#876">876</a>, <a href="lwg-defects.html#881">881</a>, <a href="lwg-defects.html#883">883</a>, <a href="lwg-defects.html#886">886</a>, <a href="lwg-defects.html#934">934</a>, <a href="lwg-defects.html#1004">1004</a>, <a href="lwg-defects.html#1178">1178</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="lwg-defects.html#1012">1012</a>, <a href="lwg-defects.html#1019">1019</a>.</li>
</ul></li>
</ul>
</li>
<li>R67: 
2009-09-25 pre-Santa Cruz mailing.
<ul>
<li><b>Summary:</b><ul>
<li>282 open issues, up by 32.</li>
<li>935 closed issues, down by 1.</li>
<li>1217 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#1187">1187</a>, <a href="lwg-closed.html#1188">1188</a>, <a href="lwg-defects.html#1189">1189</a>, <a href="lwg-closed.html#1190">1190</a>, <a href="lwg-defects.html#1191">1191</a>, <a href="lwg-defects.html#1192">1192</a>, <a href="lwg-defects.html#1193">1193</a>, <a href="lwg-defects.html#1194">1194</a>, <a href="lwg-defects.html#1195">1195</a>, <a href="lwg-defects.html#1196">1196</a>, <a href="lwg-defects.html#1197">1197</a>, <a href="lwg-defects.html#1198">1198</a>, <a href="lwg-defects.html#1199">1199</a>, <a href="lwg-closed.html#1200">1200</a>, <a href="lwg-closed.html#1201">1201</a>, <a href="lwg-closed.html#1202">1202</a>, <a href="lwg-closed.html#1203">1203</a>, <a href="lwg-defects.html#1204">1204</a>, <a href="lwg-defects.html#1205">1205</a>, <a href="lwg-defects.html#1206">1206</a>, <a href="lwg-defects.html#1207">1207</a>, <a href="lwg-defects.html#1208">1208</a>, <a href="lwg-defects.html#1209">1209</a>, <a href="lwg-defects.html#1210">1210</a>, <a href="lwg-defects.html#1211">1211</a>, <a href="lwg-defects.html#1212">1212</a>, <a href="lwg-active.html#1213">1213</a>, <a href="lwg-active.html#1214">1214</a>, <a href="lwg-defects.html#1215">1215</a>, <a href="lwg-defects.html#1216">1216</a>, <a href="lwg-closed.html#1217">1217</a>.</li>
<li>Changed the following issues from NAD to Open: <a href="lwg-defects.html#296">296</a>.</li>
<li>Changed the following issues from WP to Pending WP: <a href="lwg-defects.html#970">970</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#976">976</a>, <a href="lwg-closed.html#1052">1052</a>.</li>
<li>Changed the following issues from Ready to Review: <a href="lwg-defects.html#780">780</a>.</li>
</ul></li>
</ul>
</li>
<li>R66: 
2009-07-31 post-Frankfurt mailing.
<ul>
<li><b>Summary:</b><ul>
<li>250 open issues, down by 128.</li>
<li>936 closed issues, up by 171.</li>
<li>1186 issues total, up by 43.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issues: <a href="lwg-closed.html#1164">1164</a>.</li>
<li>Added the following NAD Concepts issues: <a href="lwg-closed.html#1149">1149</a>, <a href="lwg-closed.html#1167">1167</a>.</li>
<li>Added the following NAD Editorial issues: <a href="lwg-closed.html#1168">1168</a>.</li>
<li>Added the following New issues: <a href="lwg-defects.html#1144">1144</a>, <a href="lwg-defects.html#1145">1145</a>, <a href="lwg-defects.html#1146">1146</a>, <a href="lwg-defects.html#1147">1147</a>, <a href="lwg-closed.html#1148">1148</a>, <a href="lwg-closed.html#1150">1150</a>, <a href="lwg-defects.html#1151">1151</a>, <a href="lwg-defects.html#1152">1152</a>, <a href="lwg-closed.html#1153">1153</a>, <a href="lwg-closed.html#1154">1154</a>, <a href="lwg-closed.html#1155">1155</a>, <a href="lwg-closed.html#1156">1156</a>, <a href="lwg-defects.html#1158">1158</a>, <a href="lwg-defects.html#1159">1159</a>, <a href="lwg-defects.html#1166">1166</a>, <a href="lwg-active.html#1169">1169</a>, <a href="lwg-defects.html#1170">1170</a>, <a href="lwg-defects.html#1171">1171</a>, <a href="lwg-defects.html#1172">1172</a>, <a href="lwg-closed.html#1173">1173</a>, <a href="lwg-defects.html#1174">1174</a>, <a href="lwg-active.html#1175">1175</a>, <a href="lwg-closed.html#1176">1176</a>, <a href="lwg-defects.html#1177">1177</a>, <a href="lwg-closed.html#1179">1179</a>, <a href="lwg-defects.html#1180">1180</a>, <a href="lwg-defects.html#1181">1181</a>, <a href="lwg-defects.html#1182">1182</a>, <a href="lwg-defects.html#1183">1183</a>, <a href="lwg-closed.html#1184">1184</a>, <a href="lwg-defects.html#1185">1185</a>, <a href="lwg-closed.html#1186">1186</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#1160">1160</a>, <a href="lwg-defects.html#1161">1161</a>, <a href="lwg-defects.html#1162">1162</a>, <a href="lwg-defects.html#1163">1163</a>, <a href="lwg-defects.html#1165">1165</a>.</li>
<li>Added the following Ready issues: <a href="lwg-defects.html#1178">1178</a>.</li>
<li>Added the following Review issues: <a href="lwg-defects.html#1157">1157</a>.</li>
<li>Changed the following issues from Open to Dup: <a href="lwg-closed.html#750">750</a>, <a href="lwg-closed.html#895">895</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#111">111</a>, <a href="lwg-closed.html#128">128</a>, <a href="lwg-closed.html#138">138</a>, <a href="lwg-closed.html#190">190</a>, <a href="lwg-closed.html#219">219</a>, <a href="lwg-closed.html#290">290</a>, <a href="lwg-closed.html#309">309</a>, <a href="lwg-closed.html#342">342</a>, <a href="lwg-defects.html#343">343</a>, <a href="lwg-closed.html#382">382</a>, <a href="lwg-closed.html#394">394</a>, <a href="lwg-closed.html#398">398</a>, <a href="lwg-closed.html#417">417</a>, <a href="lwg-closed.html#418">418</a>, <a href="lwg-closed.html#421">421</a>, <a href="lwg-closed.html#459">459</a>, <a href="lwg-closed.html#466">466</a>, <a href="lwg-closed.html#492">492</a>, <a href="lwg-closed.html#502">502</a>, <a href="lwg-closed.html#503">503</a>, <a href="lwg-closed.html#546">546</a>, <a href="lwg-closed.html#573">573</a>, <a href="lwg-closed.html#582">582</a>, <a href="lwg-closed.html#585">585</a>, <a href="lwg-closed.html#597">597</a>, <a href="lwg-closed.html#606">606</a>, <a href="lwg-closed.html#614">614</a>, <a href="lwg-closed.html#632">632</a>, <a href="lwg-closed.html#721">721</a>, <a href="lwg-closed.html#747">747</a>, <a href="lwg-closed.html#751">751</a>, <a href="lwg-closed.html#833">833</a>, <a href="lwg-closed.html#941">941</a>, <a href="lwg-closed.html#992">992</a>.</li>
<li>Changed the following issues from Review to NAD: <a href="lwg-closed.html#1003">1003</a>.</li>
<li>Changed the following issues from Tentatively NAD to NAD: <a href="lwg-closed.html#568">568</a>, <a href="lwg-closed.html#644">644</a>, <a href="lwg-closed.html#667">667</a>, <a href="lwg-closed.html#669">669</a>, <a href="lwg-closed.html#701">701</a>, <a href="lwg-closed.html#702">702</a>, <a href="lwg-closed.html#785">785</a>, <a href="lwg-closed.html#863">863</a>, <a href="lwg-closed.html#901">901</a>, <a href="lwg-closed.html#903">903</a>, <a href="lwg-closed.html#946">946</a>, <a href="lwg-closed.html#988">988</a>, <a href="lwg-closed.html#995">995</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD: <a href="lwg-closed.html#1002">1002</a>.</li>
<li>Changed the following issues from New to NAD Concepts: <a href="lwg-closed.html#1124">1124</a>, <a href="lwg-closed.html#1127">1127</a>, <a href="lwg-closed.html#1128">1128</a>, <a href="lwg-closed.html#1139">1139</a>, <a href="lwg-closed.html#1140">1140</a>, <a href="lwg-closed.html#1141">1141</a>, <a href="lwg-closed.html#1142">1142</a>, <a href="lwg-defects.html#1143">1143</a>.</li>
<li>Changed the following issues from Open to NAD Concepts: <a href="lwg-closed.html#902">902</a>, <a href="lwg-closed.html#989">989</a>, <a href="lwg-closed.html#1000">1000</a>, <a href="lwg-closed.html#1007">1007</a>, <a href="lwg-closed.html#1010">1010</a>, <a href="lwg-closed.html#1015">1015</a>, <a href="lwg-closed.html#1016">1016</a>, <a href="lwg-closed.html#1017">1017</a>, <a href="lwg-closed.html#1018">1018</a>, <a href="lwg-closed.html#1026">1026</a>, <a href="lwg-closed.html#1027">1027</a>, <a href="lwg-closed.html#1028">1028</a>, <a href="lwg-closed.html#1029">1029</a>, <a href="lwg-closed.html#1032">1032</a>, <a href="lwg-closed.html#1036">1036</a>, <a href="lwg-closed.html#1057">1057</a>, <a href="lwg-closed.html#1059">1059</a>, <a href="lwg-closed.html#1072">1072</a>, <a href="lwg-closed.html#1078">1078</a>, <a href="lwg-closed.html#1081">1081</a>, <a href="lwg-closed.html#1082">1082</a>, <a href="lwg-closed.html#1083">1083</a>, <a href="lwg-closed.html#1084">1084</a>, <a href="lwg-closed.html#1085">1085</a>, <a href="lwg-closed.html#1086">1086</a>, <a href="lwg-closed.html#1092">1092</a>, <a href="lwg-closed.html#1096">1096</a>, <a href="lwg-closed.html#1105">1105</a>.</li>
<li>Changed the following issues from Review to NAD Concepts: <a href="lwg-closed.html#1001">1001</a>, <a href="lwg-closed.html#1005">1005</a>, <a href="lwg-closed.html#1080">1080</a>, <a href="lwg-closed.html#1087">1087</a>, <a href="lwg-closed.html#1111">1111</a>.</li>
<li>Changed the following issues from Tentatively NAD to NAD Concepts: <a href="lwg-closed.html#912">912</a>, <a href="lwg-closed.html#918">918</a>, <a href="lwg-closed.html#1074">1074</a>.</li>
<li>Changed the following issues from Tentatively NAD Editorial to NAD Concepts: <a href="lwg-closed.html#927">927</a>, <a href="lwg-closed.html#1109">1109</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD Concepts: <a href="lwg-closed.html#906">906</a>, <a href="lwg-closed.html#913">913</a>, <a href="lwg-closed.html#914">914</a>, <a href="lwg-closed.html#928">928</a>, <a href="lwg-closed.html#1024">1024</a>, <a href="lwg-closed.html#1063">1063</a>, <a href="lwg-closed.html#1067">1067</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#718">718</a>, <a href="lwg-closed.html#873">873</a>.</li>
<li>Changed the following issues from Tentatively NAD Editorial to NAD Editorial: <a href="lwg-closed.html#424">424</a>, <a href="lwg-defects.html#825">825</a>, <a href="lwg-closed.html#830">830</a>, <a href="lwg-closed.html#837">837</a>, <a href="lwg-closed.html#862">862</a>, <a href="lwg-closed.html#867">867</a>, <a href="lwg-defects.html#884">884</a>, <a href="lwg-closed.html#945">945</a>, <a href="lwg-closed.html#952">952</a>, <a href="lwg-closed.html#969">969</a>, <a href="lwg-closed.html#972">972</a>, <a href="lwg-closed.html#973">973</a>, <a href="lwg-closed.html#979">979</a>, <a href="lwg-closed.html#1023">1023</a>, <a href="lwg-closed.html#1058">1058</a>, <a href="lwg-closed.html#1060">1060</a>, <a href="lwg-closed.html#1061">1061</a>, <a href="lwg-closed.html#1077">1077</a>, <a href="lwg-closed.html#1101">1101</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="lwg-closed.html#1013">1013</a>, <a href="lwg-closed.html#1107">1107</a>.</li>
<li>Changed the following issues from Open to NAD Future: <a href="lwg-closed.html#255">255</a>, <a href="lwg-closed.html#423">423</a>, <a href="lwg-closed.html#523">523</a>, <a href="lwg-closed.html#708">708</a>, <a href="lwg-closed.html#760">760</a>, <a href="lwg-closed.html#839">839</a>, <a href="lwg-closed.html#877">877</a>.</li>
<li>Changed the following issues from CD1 to Open: <a href="lwg-defects.html#823">823</a>.</li>
<li>Changed the following issues from NAD Editorial to Open: <a href="lwg-closed.html#299">299</a>, <a href="lwg-closed.html#484">484</a>, <a href="lwg-closed.html#532">532</a>, <a href="lwg-defects.html#556">556</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-closed.html#631">631</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#742">742</a>, <a href="lwg-defects.html#811">811</a>, <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#872">872</a>.</li>
<li>Changed the following issues from Review to Open: <a href="lwg-closed.html#879">879</a>, <a href="lwg-closed.html#919">919</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#987">987</a>, <a href="lwg-closed.html#1009">1009</a>, <a href="lwg-defects.html#1093">1093</a>.</li>
<li>Changed the following issues from Tentatively NAD to Open: <a href="lwg-closed.html#458">458</a>.</li>
<li>Changed the following issues from Tentatively NAD Future to Open: <a href="lwg-closed.html#96">96</a>.</li>
<li>Changed the following issues from Tentatively Ready to Open: <a href="lwg-closed.html#910">910</a>, <a href="lwg-closed.html#915">915</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#976">976</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-defects.html#1011">1011</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#149">149</a>, <a href="lwg-defects.html#419">419</a>, <a href="lwg-defects.html#430">430</a>, <a href="lwg-defects.html#498">498</a>, <a href="lwg-defects.html#564">564</a>, <a href="lwg-defects.html#565">565</a>, <a href="lwg-defects.html#630">630</a>, <a href="lwg-defects.html#659">659</a>, <a href="lwg-defects.html#696">696</a>, <a href="lwg-defects.html#711">711</a>, <a href="lwg-defects.html#716">716</a>, <a href="lwg-defects.html#723">723</a>, <a href="lwg-defects.html#788">788</a>, <a href="lwg-defects.html#834">834</a>, <a href="lwg-defects.html#838">838</a>, <a href="lwg-defects.html#847">847</a>, <a href="lwg-defects.html#857">857</a>, <a href="lwg-defects.html#859">859</a>, <a href="lwg-defects.html#876">876</a>, <a href="lwg-defects.html#881">881</a>, <a href="lwg-defects.html#883">883</a>, <a href="lwg-defects.html#886">886</a>, <a href="lwg-defects.html#1004">1004</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#780">780</a>.</li>
<li>Changed the following issues from Tentatively NAD to Ready: <a href="lwg-closed.html#822">822</a>.</li>
<li>Changed the following issues from Tentatively Ready to Ready: <a href="lwg-defects.html#934">934</a>.</li>
<li>Changed the following issues from NAD to Review: <a href="lwg-defects.html#871">871</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-closed.html#397">397</a>, <a href="lwg-closed.html#408">408</a>, <a href="lwg-defects.html#473">473</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-defects.html#868">868</a>, <a href="lwg-defects.html#889">889</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-closed.html#930">930</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>.</li>
<li>Changed the following issues from Tentatively NAD to Review: <a href="lwg-closed.html#668">668</a>.</li>
<li>Changed the following issues from Tentatively Ready to Review: <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#1100">1100</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD: <a href="lwg-closed.html#588">588</a>, <a href="lwg-closed.html#617">617</a>, <a href="lwg-defects.html#625">625</a>, <a href="lwg-closed.html#971">971</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Future: <a href="lwg-closed.html#1031">1031</a>, <a href="lwg-closed.html#1062">1062</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#1012">1012</a>, <a href="lwg-defects.html#1019">1019</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="lwg-defects.html#688">688</a>, <a href="lwg-defects.html#765">765</a>, <a href="lwg-defects.html#810">810</a>, <a href="lwg-defects.html#814">814</a>, <a href="lwg-defects.html#853">853</a>, <a href="lwg-defects.html#869">869</a>, <a href="lwg-defects.html#878">878</a>, <a href="lwg-defects.html#888">888</a>, <a href="lwg-defects.html#890">890</a>, <a href="lwg-defects.html#898">898</a>, <a href="lwg-defects.html#899">899</a>, <a href="lwg-defects.html#904">904</a>, <a href="lwg-defects.html#907">907</a>, <a href="lwg-defects.html#909">909</a>, <a href="lwg-defects.html#922">922</a>, <a href="lwg-defects.html#925">925</a>, <a href="lwg-defects.html#931">931</a>, <a href="lwg-defects.html#938">938</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-defects.html#948">948</a>, <a href="lwg-defects.html#949">949</a>, <a href="lwg-defects.html#965">965</a>, <a href="lwg-defects.html#970">970</a>, <a href="lwg-defects.html#975">975</a>, <a href="lwg-defects.html#981">981</a>, <a href="lwg-defects.html#982">982</a>, <a href="lwg-defects.html#984">984</a>, <a href="lwg-defects.html#986">986</a>, <a href="lwg-defects.html#990">990</a>, <a href="lwg-defects.html#991">991</a>, <a href="lwg-defects.html#993">993</a>, <a href="lwg-defects.html#994">994</a>, <a href="lwg-defects.html#997">997</a>, <a href="lwg-defects.html#998">998</a>, <a href="lwg-defects.html#1006">1006</a>, <a href="lwg-defects.html#1014">1014</a>, <a href="lwg-defects.html#1021">1021</a>, <a href="lwg-defects.html#1037">1037</a>, <a href="lwg-defects.html#1038">1038</a>, <a href="lwg-defects.html#1039">1039</a>, <a href="lwg-defects.html#1040">1040</a>, <a href="lwg-defects.html#1044">1044</a>, <a href="lwg-defects.html#1045">1045</a>, <a href="lwg-defects.html#1065">1065</a>, <a href="lwg-defects.html#1066">1066</a>, <a href="lwg-defects.html#1070">1070</a>, <a href="lwg-defects.html#1073">1073</a>, <a href="lwg-defects.html#1103">1103</a>.</li>
</ul></li>
</ul>
</li>
<li>R65: 
2009-06-19 pre-Frankfurt mailing.
<ul>
<li><b>Summary:</b><ul>
<li>378 open issues, up by 32.</li>
<li>765 closed issues, up by 0.</li>
<li>1143 issues total, up by 32.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-closed.html#1115">1115</a>, <a href="lwg-defects.html#1116">1116</a>, <a href="lwg-defects.html#1117">1117</a>, <a href="lwg-defects.html#1118">1118</a>, <a href="lwg-closed.html#1119">1119</a>, <a href="lwg-closed.html#1120">1120</a>, <a href="lwg-closed.html#1121">1121</a>, <a href="lwg-defects.html#1122">1122</a>, <a href="lwg-defects.html#1123">1123</a>, <a href="lwg-closed.html#1124">1124</a>, <a href="lwg-closed.html#1125">1125</a>, <a href="lwg-defects.html#1126">1126</a>, <a href="lwg-closed.html#1127">1127</a>, <a href="lwg-closed.html#1128">1128</a>, <a href="lwg-defects.html#1129">1129</a>, <a href="lwg-defects.html#1130">1130</a>, <a href="lwg-defects.html#1131">1131</a>, <a href="lwg-closed.html#1132">1132</a>, <a href="lwg-defects.html#1133">1133</a>, <a href="lwg-defects.html#1134">1134</a>, <a href="lwg-defects.html#1135">1135</a>, <a href="lwg-defects.html#1136">1136</a>, <a href="lwg-defects.html#1137">1137</a>, <a href="lwg-defects.html#1138">1138</a>, <a href="lwg-closed.html#1139">1139</a>, <a href="lwg-closed.html#1140">1140</a>, <a href="lwg-closed.html#1141">1141</a>, <a href="lwg-closed.html#1142">1142</a>, <a href="lwg-defects.html#1143">1143</a>.</li>
<li>Added the following Open issues: <a href="lwg-closed.html#1112">1112</a>, <a href="lwg-defects.html#1113">1113</a>, <a href="lwg-defects.html#1114">1114</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#937">937</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#696">696</a>, <a href="lwg-defects.html#716">716</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#865">865</a>, <a href="lwg-defects.html#900">900</a>, <a href="lwg-defects.html#911">911</a>, <a href="lwg-closed.html#916">916</a>, <a href="lwg-closed.html#917">917</a>, <a href="lwg-defects.html#920">920</a>, <a href="lwg-closed.html#933">933</a>, <a href="lwg-closed.html#935">935</a>, <a href="lwg-closed.html#941">941</a>, <a href="lwg-defects.html#947">947</a>, <a href="lwg-defects.html#951">951</a>, <a href="lwg-defects.html#953">953</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-closed.html#955">955</a>, <a href="lwg-defects.html#956">956</a>, <a href="lwg-closed.html#977">977</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-defects.html#985">985</a>, <a href="lwg-closed.html#989">989</a>, <a href="lwg-closed.html#996">996</a>, <a href="lwg-defects.html#1033">1033</a>, <a href="lwg-defects.html#1054">1054</a>, <a href="lwg-closed.html#1056">1056</a>, <a href="lwg-closed.html#1057">1057</a>, <a href="lwg-closed.html#1059">1059</a>, <a href="lwg-closed.html#1062">1062</a>, <a href="lwg-closed.html#1068">1068</a>, <a href="lwg-closed.html#1069">1069</a>, <a href="lwg-defects.html#1071">1071</a>, <a href="lwg-closed.html#1072">1072</a>, <a href="lwg-closed.html#1076">1076</a>, <a href="lwg-defects.html#1090">1090</a>, <a href="lwg-closed.html#1092">1092</a>, <a href="lwg-closed.html#1096">1096</a>, <a href="lwg-defects.html#1098">1098</a>, <a href="lwg-closed.html#1099">1099</a>, <a href="lwg-closed.html#1105">1105</a>, <a href="lwg-defects.html#1106">1106</a>, <a href="lwg-defects.html#1108">1108</a>, <a href="lwg-defects.html#1110">1110</a>.</li>
<li>Changed the following issues from Review to Open: <a href="lwg-defects.html#817">817</a>, <a href="lwg-closed.html#971">971</a>, <a href="lwg-closed.html#992">992</a>, <a href="lwg-defects.html#1004">1004</a>, <a href="lwg-closed.html#1010">1010</a>, <a href="lwg-defects.html#1012">1012</a>, <a href="lwg-closed.html#1015">1015</a>, <a href="lwg-defects.html#1019">1019</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#780">780</a>, <a href="lwg-defects.html#835">835</a>, <a href="lwg-defects.html#897">897</a>, <a href="lwg-closed.html#919">919</a>, <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#957">957</a>, <a href="lwg-defects.html#983">983</a>, <a href="lwg-closed.html#1001">1001</a>, <a href="lwg-closed.html#1080">1080</a>, <a href="lwg-closed.html#1091">1091</a>, <a href="lwg-defects.html#1093">1093</a>, <a href="lwg-defects.html#1094">1094</a>, <a href="lwg-defects.html#1095">1095</a>, <a href="lwg-defects.html#1097">1097</a>, <a href="lwg-closed.html#1102">1102</a>, <a href="lwg-defects.html#1104">1104</a>, <a href="lwg-closed.html#1111">1111</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#987">987</a>, <a href="lwg-closed.html#1087">1087</a>.</li>
<li>Changed the following issues from New to Tentatively NAD: <a href="lwg-closed.html#568">568</a>, <a href="lwg-closed.html#701">701</a>, <a href="lwg-closed.html#702">702</a>, <a href="lwg-closed.html#785">785</a>, <a href="lwg-closed.html#863">863</a>, <a href="lwg-closed.html#903">903</a>, <a href="lwg-closed.html#912">912</a>, <a href="lwg-closed.html#918">918</a>, <a href="lwg-closed.html#946">946</a>, <a href="lwg-closed.html#995">995</a>, <a href="lwg-closed.html#1074">1074</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD: <a href="lwg-closed.html#458">458</a>, <a href="lwg-closed.html#644">644</a>, <a href="lwg-closed.html#667">667</a>, <a href="lwg-closed.html#668">668</a>, <a href="lwg-closed.html#669">669</a>.</li>
<li>Changed the following issues from Review to Tentatively NAD: <a href="lwg-closed.html#901">901</a>.</li>
<li>Changed the following issues from Tentatively Ready to Tentatively NAD: <a href="lwg-closed.html#822">822</a>, <a href="lwg-closed.html#988">988</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="lwg-closed.html#837">837</a>, <a href="lwg-closed.html#862">862</a>, <a href="lwg-closed.html#867">867</a>, <a href="lwg-closed.html#927">927</a>, <a href="lwg-closed.html#945">945</a>, <a href="lwg-closed.html#952">952</a>, <a href="lwg-closed.html#969">969</a>, <a href="lwg-closed.html#972">972</a>, <a href="lwg-closed.html#973">973</a>, <a href="lwg-closed.html#979">979</a>, <a href="lwg-closed.html#1058">1058</a>, <a href="lwg-closed.html#1060">1060</a>, <a href="lwg-closed.html#1061">1061</a>, <a href="lwg-closed.html#1077">1077</a>, <a href="lwg-closed.html#1101">1101</a>, <a href="lwg-closed.html#1109">1109</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="lwg-closed.html#424">424</a>, <a href="lwg-defects.html#825">825</a>, <a href="lwg-closed.html#830">830</a>, <a href="lwg-defects.html#884">884</a>.</li>
<li>Changed the following issues from Review to Tentatively NAD Editorial: <a href="lwg-closed.html#1023">1023</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Future: <a href="lwg-closed.html#96">96</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#810">810</a>, <a href="lwg-defects.html#898">898</a>, <a href="lwg-closed.html#906">906</a>, <a href="lwg-closed.html#910">910</a>, <a href="lwg-closed.html#913">913</a>, <a href="lwg-closed.html#914">914</a>, <a href="lwg-closed.html#915">915</a>, <a href="lwg-defects.html#925">925</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#976">976</a>, <a href="lwg-defects.html#981">981</a>, <a href="lwg-defects.html#982">982</a>, <a href="lwg-defects.html#984">984</a>, <a href="lwg-defects.html#990">990</a>, <a href="lwg-defects.html#998">998</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-closed.html#1063">1063</a>, <a href="lwg-closed.html#1067">1067</a>, <a href="lwg-defects.html#1070">1070</a>, <a href="lwg-defects.html#1073">1073</a>, <a href="lwg-defects.html#1100">1100</a>, <a href="lwg-defects.html#1103">1103</a>, <a href="lwg-closed.html#1107">1107</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#688">688</a>, <a href="lwg-defects.html#814">814</a>.</li>
<li>Changed the following issues from Review to Tentatively Ready: <a href="lwg-defects.html#899">899</a>, <a href="lwg-defects.html#907">907</a>, <a href="lwg-defects.html#909">909</a>, <a href="lwg-defects.html#934">934</a>, <a href="lwg-defects.html#938">938</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#965">965</a>, <a href="lwg-defects.html#970">970</a>, <a href="lwg-defects.html#975">975</a>, <a href="lwg-defects.html#986">986</a>, <a href="lwg-defects.html#991">991</a>, <a href="lwg-defects.html#993">993</a>, <a href="lwg-defects.html#994">994</a>, <a href="lwg-defects.html#997">997</a>, <a href="lwg-closed.html#1002">1002</a>, <a href="lwg-defects.html#1006">1006</a>, <a href="lwg-defects.html#1011">1011</a>, <a href="lwg-closed.html#1013">1013</a>, <a href="lwg-defects.html#1014">1014</a>, <a href="lwg-defects.html#1021">1021</a>, <a href="lwg-closed.html#1024">1024</a>, <a href="lwg-defects.html#1037">1037</a>, <a href="lwg-defects.html#1038">1038</a>, <a href="lwg-defects.html#1039">1039</a>, <a href="lwg-defects.html#1040">1040</a>, <a href="lwg-defects.html#1044">1044</a>, <a href="lwg-defects.html#1045">1045</a>, <a href="lwg-defects.html#1065">1065</a>, <a href="lwg-defects.html#1066">1066</a>.</li>
</ul></li>
</ul>
</li>
<li>R64: 
2009-05-01 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>346 open issues, up by 19.</li>
<li>765 closed issues, up by 0.</li>
<li>1111 issues total, up by 19.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#1093">1093</a>, <a href="lwg-defects.html#1094">1094</a>, <a href="lwg-defects.html#1095">1095</a>, <a href="lwg-closed.html#1096">1096</a>, <a href="lwg-defects.html#1097">1097</a>, <a href="lwg-defects.html#1098">1098</a>, <a href="lwg-closed.html#1099">1099</a>, <a href="lwg-defects.html#1100">1100</a>, <a href="lwg-closed.html#1101">1101</a>, <a href="lwg-closed.html#1102">1102</a>, <a href="lwg-defects.html#1103">1103</a>, <a href="lwg-defects.html#1104">1104</a>, <a href="lwg-closed.html#1105">1105</a>, <a href="lwg-defects.html#1106">1106</a>, <a href="lwg-closed.html#1107">1107</a>, <a href="lwg-defects.html#1108">1108</a>, <a href="lwg-closed.html#1109">1109</a>, <a href="lwg-defects.html#1110">1110</a>, <a href="lwg-closed.html#1111">1111</a>.</li>
<li>Changed the following issues from DR to CD1: <a href="lwg-defects.html#130">130</a>, <a href="lwg-defects.html#386">386</a>, <a href="lwg-defects.html#406">406</a>, <a href="lwg-defects.html#409">409</a>, <a href="lwg-defects.html#413">413</a>, <a href="lwg-defects.html#434">434</a>, <a href="lwg-defects.html#438">438</a>, <a href="lwg-defects.html#444">444</a>, <a href="lwg-defects.html#445">445</a>, <a href="lwg-defects.html#455">455</a>, <a href="lwg-defects.html#457">457</a>, <a href="lwg-defects.html#460">460</a>, <a href="lwg-defects.html#469">469</a>, <a href="lwg-defects.html#533">533</a>.</li>
<li>Changed the following issues from Review to New: <a href="lwg-defects.html#1070">1070</a>.</li>
</ul></li>
</ul>
</li>
<li>R63: 
2009-03-20 post-Summit mailing.
<ul>
<li><b>Summary:</b><ul>
<li>327 open issues, up by 96.</li>
<li>765 closed issues, up by 14.</li>
<li>1092 issues total, up by 110.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD Editorial issues: <a href="lwg-closed.html#1022">1022</a>.</li>
<li>Added the following NAD Future issues: <a href="lwg-closed.html#1025">1025</a>.</li>
<li>Added the following New issues: <a href="lwg-defects.html#983">983</a>, <a href="lwg-defects.html#984">984</a>, <a href="lwg-defects.html#985">985</a>, <a href="lwg-closed.html#989">989</a>, <a href="lwg-defects.html#990">990</a>, <a href="lwg-closed.html#995">995</a>, <a href="lwg-closed.html#996">996</a>, <a href="lwg-defects.html#998">998</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-closed.html#1001">1001</a>, <a href="lwg-defects.html#1033">1033</a>, <a href="lwg-defects.html#1054">1054</a>, <a href="lwg-closed.html#1056">1056</a>, <a href="lwg-closed.html#1057">1057</a>, <a href="lwg-closed.html#1058">1058</a>, <a href="lwg-closed.html#1059">1059</a>, <a href="lwg-closed.html#1060">1060</a>, <a href="lwg-closed.html#1061">1061</a>, <a href="lwg-closed.html#1062">1062</a>, <a href="lwg-closed.html#1063">1063</a>, <a href="lwg-closed.html#1067">1067</a>, <a href="lwg-closed.html#1068">1068</a>, <a href="lwg-closed.html#1069">1069</a>, <a href="lwg-defects.html#1071">1071</a>, <a href="lwg-closed.html#1072">1072</a>, <a href="lwg-defects.html#1073">1073</a>, <a href="lwg-closed.html#1074">1074</a>, <a href="lwg-closed.html#1076">1076</a>, <a href="lwg-closed.html#1077">1077</a>, <a href="lwg-closed.html#1080">1080</a>, <a href="lwg-defects.html#1090">1090</a>, <a href="lwg-closed.html#1091">1091</a>, <a href="lwg-closed.html#1092">1092</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#987">987</a>, <a href="lwg-closed.html#1000">1000</a>, <a href="lwg-closed.html#1007">1007</a>, <a href="lwg-closed.html#1008">1008</a>, <a href="lwg-closed.html#1016">1016</a>, <a href="lwg-closed.html#1017">1017</a>, <a href="lwg-closed.html#1018">1018</a>, <a href="lwg-closed.html#1020">1020</a>, <a href="lwg-closed.html#1026">1026</a>, <a href="lwg-closed.html#1027">1027</a>, <a href="lwg-closed.html#1028">1028</a>, <a href="lwg-closed.html#1029">1029</a>, <a href="lwg-defects.html#1030">1030</a>, <a href="lwg-closed.html#1031">1031</a>, <a href="lwg-closed.html#1032">1032</a>, <a href="lwg-defects.html#1034">1034</a>, <a href="lwg-closed.html#1035">1035</a>, <a href="lwg-closed.html#1036">1036</a>, <a href="lwg-closed.html#1041">1041</a>, <a href="lwg-closed.html#1042">1042</a>, <a href="lwg-defects.html#1046">1046</a>, <a href="lwg-defects.html#1048">1048</a>, <a href="lwg-closed.html#1051">1051</a>, <a href="lwg-closed.html#1052">1052</a>, <a href="lwg-closed.html#1053">1053</a>, <a href="lwg-defects.html#1055">1055</a>, <a href="lwg-closed.html#1064">1064</a>, <a href="lwg-defects.html#1075">1075</a>, <a href="lwg-closed.html#1078">1078</a>, <a href="lwg-defects.html#1079">1079</a>, <a href="lwg-closed.html#1081">1081</a>, <a href="lwg-closed.html#1082">1082</a>, <a href="lwg-closed.html#1083">1083</a>, <a href="lwg-closed.html#1084">1084</a>, <a href="lwg-closed.html#1085">1085</a>, <a href="lwg-closed.html#1086">1086</a>, <a href="lwg-closed.html#1087">1087</a>, <a href="lwg-defects.html#1088">1088</a>, <a href="lwg-defects.html#1089">1089</a>.</li>
<li>Added the following Review issues: <a href="lwg-defects.html#986">986</a>, <a href="lwg-defects.html#991">991</a>, <a href="lwg-closed.html#992">992</a>, <a href="lwg-defects.html#993">993</a>, <a href="lwg-defects.html#994">994</a>, <a href="lwg-defects.html#997">997</a>, <a href="lwg-closed.html#1002">1002</a>, <a href="lwg-closed.html#1003">1003</a>, <a href="lwg-defects.html#1004">1004</a>, <a href="lwg-closed.html#1005">1005</a>, <a href="lwg-defects.html#1006">1006</a>, <a href="lwg-closed.html#1009">1009</a>, <a href="lwg-closed.html#1010">1010</a>, <a href="lwg-defects.html#1011">1011</a>, <a href="lwg-defects.html#1012">1012</a>, <a href="lwg-closed.html#1013">1013</a>, <a href="lwg-defects.html#1014">1014</a>, <a href="lwg-closed.html#1015">1015</a>, <a href="lwg-defects.html#1019">1019</a>, <a href="lwg-defects.html#1021">1021</a>, <a href="lwg-closed.html#1023">1023</a>, <a href="lwg-closed.html#1024">1024</a>, <a href="lwg-defects.html#1037">1037</a>, <a href="lwg-defects.html#1038">1038</a>, <a href="lwg-defects.html#1039">1039</a>, <a href="lwg-defects.html#1040">1040</a>, <a href="lwg-defects.html#1043">1043</a>, <a href="lwg-defects.html#1044">1044</a>, <a href="lwg-defects.html#1045">1045</a>, <a href="lwg-defects.html#1047">1047</a>, <a href="lwg-defects.html#1049">1049</a>, <a href="lwg-defects.html#1050">1050</a>, <a href="lwg-defects.html#1065">1065</a>, <a href="lwg-defects.html#1066">1066</a>, <a href="lwg-defects.html#1070">1070</a>.</li>
<li>Added the following Tentatively Ready issues: <a href="lwg-closed.html#988">988</a>.</li>
<li>Changed the following issues from New to Dup: <a href="lwg-closed.html#905">905</a>, <a href="lwg-closed.html#942">942</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#980">980</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#874">874</a>, <a href="lwg-defects.html#875">875</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-defects.html#732">732</a>, <a href="lwg-defects.html#793">793</a>, <a href="lwg-defects.html#794">794</a>, <a href="lwg-defects.html#800">800</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#683">683</a>, <a href="lwg-closed.html#892">892</a>.</li>
<li>Changed the following issues from Ready to NAD Editorial: <a href="lwg-defects.html#803">803</a>.</li>
<li>Changed the following issues from NAD to Open: <a href="lwg-closed.html#466">466</a>.</li>
<li>Changed the following issues from NAD Future to Open: <a href="lwg-closed.html#111">111</a>, <a href="lwg-closed.html#138">138</a>, <a href="lwg-defects.html#149">149</a>, <a href="lwg-closed.html#219">219</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#880">880</a>, <a href="lwg-defects.html#891">891</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-closed.html#902">902</a>, <a href="lwg-defects.html#908">908</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#923">923</a>, <a href="lwg-defects.html#924">924</a>, <a href="lwg-closed.html#926">926</a>, <a href="lwg-closed.html#930">930</a>, <a href="lwg-closed.html#936">936</a>, <a href="lwg-defects.html#944">944</a>, <a href="lwg-defects.html#958">958</a>, <a href="lwg-closed.html#959">959</a>, <a href="lwg-defects.html#960">960</a>, <a href="lwg-closed.html#961">961</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#963">963</a>, <a href="lwg-defects.html#964">964</a>, <a href="lwg-defects.html#966">966</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="lwg-defects.html#788">788</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="lwg-closed.html#937">937</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-closed.html#879">879</a>, <a href="lwg-defects.html#899">899</a>, <a href="lwg-closed.html#901">901</a>, <a href="lwg-defects.html#907">907</a>, <a href="lwg-defects.html#909">909</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-defects.html#934">934</a>, <a href="lwg-defects.html#938">938</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#965">965</a>, <a href="lwg-defects.html#970">970</a>, <a href="lwg-closed.html#971">971</a>, <a href="lwg-defects.html#975">975</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#817">817</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#904">904</a>, <a href="lwg-defects.html#922">922</a>, <a href="lwg-closed.html#928">928</a>, <a href="lwg-defects.html#931">931</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-defects.html#948">948</a>, <a href="lwg-defects.html#949">949</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#890">890</a>.</li>
<li>Changed the following issues from Review to Tentatively Ready: <a href="lwg-defects.html#765">765</a>, <a href="lwg-closed.html#822">822</a>, <a href="lwg-defects.html#853">853</a>, <a href="lwg-defects.html#869">869</a>, <a href="lwg-defects.html#878">878</a>, <a href="lwg-defects.html#888">888</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#752">752</a>, <a href="lwg-defects.html#753">753</a>, <a href="lwg-defects.html#758">758</a>, <a href="lwg-defects.html#821">821</a>, <a href="lwg-defects.html#866">866</a>, <a href="lwg-defects.html#894">894</a>.</li>
</ul></li>
</ul>
</li>
<li>R62: 
2009-02-06 pre-Summit mailing.
<ul>
<li><b>Summary:</b><ul>
<li>231 open issues, up by 44.</li>
<li>751 closed issues, up by 0.</li>
<li>982 issues total, up by 44.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-closed.html#941">941</a>, <a href="lwg-closed.html#942">942</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-defects.html#944">944</a>, <a href="lwg-closed.html#945">945</a>, <a href="lwg-closed.html#946">946</a>, <a href="lwg-defects.html#947">947</a>, <a href="lwg-defects.html#948">948</a>, <a href="lwg-defects.html#949">949</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#951">951</a>, <a href="lwg-closed.html#952">952</a>, <a href="lwg-defects.html#953">953</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-closed.html#955">955</a>, <a href="lwg-defects.html#956">956</a>, <a href="lwg-defects.html#957">957</a>, <a href="lwg-defects.html#958">958</a>, <a href="lwg-closed.html#959">959</a>, <a href="lwg-defects.html#960">960</a>, <a href="lwg-closed.html#961">961</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#963">963</a>, <a href="lwg-defects.html#964">964</a>, <a href="lwg-defects.html#965">965</a>, <a href="lwg-defects.html#966">966</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>, <a href="lwg-closed.html#969">969</a>, <a href="lwg-defects.html#970">970</a>, <a href="lwg-closed.html#971">971</a>, <a href="lwg-closed.html#972">972</a>, <a href="lwg-closed.html#973">973</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#975">975</a>, <a href="lwg-defects.html#976">976</a>, <a href="lwg-closed.html#977">977</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-closed.html#979">979</a>, <a href="lwg-closed.html#980">980</a>, <a href="lwg-defects.html#981">981</a>, <a href="lwg-defects.html#982">982</a>.</li>
</ul></li>
</ul>
</li>
<li>R61: 
2008-12-05 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>187 open issues, up by 20.</li>
<li>751 closed issues, up by 0.</li>
<li>938 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-closed.html#919">919</a>, <a href="lwg-defects.html#920">920</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#922">922</a>, <a href="lwg-defects.html#923">923</a>, <a href="lwg-defects.html#924">924</a>, <a href="lwg-defects.html#925">925</a>, <a href="lwg-closed.html#926">926</a>, <a href="lwg-closed.html#927">927</a>, <a href="lwg-closed.html#928">928</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-closed.html#930">930</a>, <a href="lwg-defects.html#931">931</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-closed.html#933">933</a>, <a href="lwg-defects.html#934">934</a>, <a href="lwg-closed.html#935">935</a>, <a href="lwg-closed.html#936">936</a>, <a href="lwg-closed.html#937">937</a>, <a href="lwg-defects.html#938">938</a>.</li>
</ul></li>
</ul>
</li>
<li>R60: 
2008-10-03 post-San Francisco mailing.
<ul>
<li><b>Summary:</b><ul>
<li>167 open issues, down by 25.</li>
<li>751 closed issues, up by 65.</li>
<li>918 issues total, up by 40.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following CD1 issues: <a href="lwg-defects.html#882">882</a>.</li>
<li>Added the following New issues: <a href="lwg-closed.html#879">879</a>, <a href="lwg-defects.html#880">880</a>, <a href="lwg-defects.html#891">891</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-defects.html#897">897</a>, <a href="lwg-defects.html#898">898</a>, <a href="lwg-defects.html#899">899</a>, <a href="lwg-defects.html#900">900</a>, <a href="lwg-closed.html#901">901</a>, <a href="lwg-closed.html#902">902</a>, <a href="lwg-closed.html#903">903</a>, <a href="lwg-defects.html#904">904</a>, <a href="lwg-closed.html#905">905</a>, <a href="lwg-closed.html#906">906</a>, <a href="lwg-defects.html#907">907</a>, <a href="lwg-defects.html#908">908</a>, <a href="lwg-defects.html#909">909</a>, <a href="lwg-closed.html#910">910</a>, <a href="lwg-defects.html#911">911</a>, <a href="lwg-closed.html#912">912</a>, <a href="lwg-closed.html#913">913</a>, <a href="lwg-closed.html#914">914</a>, <a href="lwg-closed.html#915">915</a>, <a href="lwg-closed.html#916">916</a>, <a href="lwg-closed.html#917">917</a>, <a href="lwg-closed.html#918">918</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#881">881</a>, <a href="lwg-defects.html#883">883</a>, <a href="lwg-defects.html#884">884</a>, <a href="lwg-defects.html#885">885</a>, <a href="lwg-defects.html#886">886</a>, <a href="lwg-closed.html#887">887</a>, <a href="lwg-defects.html#889">889</a>, <a href="lwg-defects.html#890">890</a>, <a href="lwg-closed.html#895">895</a>, <a href="lwg-defects.html#896">896</a>.</li>
<li>Added the following Pending NAD Editorial issues: <a href="lwg-closed.html#892">892</a>.</li>
<li>Added the following Ready issues: <a href="lwg-defects.html#894">894</a>.</li>
<li>Added the following Review issues: <a href="lwg-defects.html#888">888</a>.</li>
<li>Changed the following issues from New to CD1: <a href="lwg-defects.html#818">818</a>, <a href="lwg-defects.html#820">820</a>, <a href="lwg-defects.html#843">843</a>, <a href="lwg-defects.html#845">845</a>, <a href="lwg-defects.html#846">846</a>, <a href="lwg-defects.html#856">856</a>, <a href="lwg-defects.html#858">858</a>.</li>
<li>Changed the following issues from Ready to CD1: <a href="lwg-defects.html#180">180</a>, <a href="lwg-defects.html#387">387</a>, <a href="lwg-defects.html#396">396</a>, <a href="lwg-defects.html#522">522</a>, <a href="lwg-defects.html#629">629</a>, <a href="lwg-defects.html#691">691</a>, <a href="lwg-defects.html#713">713</a>, <a href="lwg-defects.html#714">714</a>, <a href="lwg-defects.html#720">720</a>, <a href="lwg-defects.html#728">728</a>, <a href="lwg-defects.html#762">762</a>, <a href="lwg-defects.html#769">769</a>, <a href="lwg-defects.html#771">771</a>, <a href="lwg-defects.html#772">772</a>, <a href="lwg-defects.html#776">776</a>, <a href="lwg-defects.html#779">779</a>, <a href="lwg-defects.html#787">787</a>, <a href="lwg-defects.html#805">805</a>, <a href="lwg-defects.html#806">806</a>, <a href="lwg-defects.html#807">807</a>, <a href="lwg-defects.html#808">808</a>, <a href="lwg-defects.html#809">809</a>, <a href="lwg-defects.html#813">813</a>, <a href="lwg-defects.html#824">824</a>, <a href="lwg-defects.html#829">829</a>, <a href="lwg-defects.html#842">842</a>, <a href="lwg-defects.html#844">844</a>, <a href="lwg-defects.html#848">848</a>, <a href="lwg-defects.html#850">850</a>, <a href="lwg-defects.html#852">852</a>.</li>
<li>Changed the following issues from Review to CD1: <a href="lwg-defects.html#23">23</a>, <a href="lwg-defects.html#675">675</a>, <a href="lwg-defects.html#692">692</a>, <a href="lwg-defects.html#698">698</a>, <a href="lwg-defects.html#709">709</a>, <a href="lwg-defects.html#734">734</a>, <a href="lwg-defects.html#804">804</a>, <a href="lwg-defects.html#823">823</a>.</li>
<li>Changed the following issues from WP to CD1: <a href="lwg-defects.html#44">44</a>, <a href="lwg-defects.html#49">49</a>, <a href="lwg-defects.html#76">76</a>, <a href="lwg-defects.html#91">91</a>, <a href="lwg-defects.html#92">92</a>, <a href="lwg-defects.html#98">98</a>, <a href="lwg-defects.html#103">103</a>, <a href="lwg-defects.html#109">109</a>, <a href="lwg-defects.html#117">117</a>, <a href="lwg-defects.html#118">118</a>, <a href="lwg-defects.html#120">120</a>, <a href="lwg-defects.html#123">123</a>, <a href="lwg-defects.html#136">136</a>, <a href="lwg-defects.html#153">153</a>, <a href="lwg-defects.html#165">165</a>, <a href="lwg-defects.html#167">167</a>, <a href="lwg-defects.html#171">171</a>, <a href="lwg-defects.html#179">179</a>, <a href="lwg-defects.html#182">182</a>, <a href="lwg-defects.html#183">183</a>, <a href="lwg-defects.html#184">184</a>, <a href="lwg-defects.html#185">185</a>, <a href="lwg-defects.html#186">186</a>, <a href="lwg-defects.html#187">187</a>, <a href="lwg-defects.html#198">198</a>, <a href="lwg-defects.html#200">200</a>, <a href="lwg-defects.html#201">201</a>, <a href="lwg-defects.html#202">202</a>, <a href="lwg-defects.html#206">206</a>, <a href="lwg-defects.html#214">214</a>, <a href="lwg-defects.html#221">221</a>, <a href="lwg-defects.html#225">225</a>, <a href="lwg-defects.html#226">226</a>, <a href="lwg-defects.html#228">228</a>, <a href="lwg-defects.html#229">229</a>, <a href="lwg-defects.html#230">230</a>, <a href="lwg-defects.html#231">231</a>, <a href="lwg-defects.html#232">232</a>, <a href="lwg-defects.html#233">233</a>, <a href="lwg-defects.html#234">234</a>, <a href="lwg-defects.html#235">235</a>, <a href="lwg-defects.html#237">237</a>, <a href="lwg-defects.html#238">238</a>, <a href="lwg-defects.html#239">239</a>, <a href="lwg-defects.html#240">240</a>, <a href="lwg-defects.html#241">241</a>, <a href="lwg-defects.html#242">242</a>, <a href="lwg-defects.html#243">243</a>, <a href="lwg-defects.html#247">247</a>, <a href="lwg-defects.html#248">248</a>, <a href="lwg-defects.html#250">250</a>, <a href="lwg-defects.html#251">251</a>, <a href="lwg-defects.html#252">252</a>, <a href="lwg-defects.html#253">253</a>, <a href="lwg-defects.html#254">254</a>, <a href="lwg-defects.html#256">256</a>, <a href="lwg-defects.html#258">258</a>, <a href="lwg-defects.html#259">259</a>, <a href="lwg-defects.html#260">260</a>, <a href="lwg-defects.html#261">261</a>, <a href="lwg-defects.html#262">262</a>, <a href="lwg-defects.html#263">263</a>, <a href="lwg-defects.html#264">264</a>, <a href="lwg-defects.html#265">265</a>, <a href="lwg-defects.html#266">266</a>, <a href="lwg-defects.html#268">268</a>, <a href="lwg-defects.html#270">270</a>, <a href="lwg-defects.html#271">271</a>, <a href="lwg-defects.html#272">272</a>, <a href="lwg-defects.html#273">273</a>, <a href="lwg-defects.html#274">274</a>, <a href="lwg-defects.html#275">275</a>, <a href="lwg-defects.html#276">276</a>, <a href="lwg-defects.html#278">278</a>, <a href="lwg-defects.html#280">280</a>, <a href="lwg-defects.html#281">281</a>, <a href="lwg-defects.html#282">282</a>, <a href="lwg-defects.html#283">283</a>, <a href="lwg-defects.html#284">284</a>, <a href="lwg-defects.html#285">285</a>, <a href="lwg-defects.html#286">286</a>, <a href="lwg-defects.html#288">288</a>, <a href="lwg-defects.html#291">291</a>, <a href="lwg-defects.html#292">292</a>, <a href="lwg-defects.html#294">294</a>, <a href="lwg-defects.html#295">295</a>, <a href="lwg-defects.html#297">297</a>, <a href="lwg-defects.html#298">298</a>, <a href="lwg-defects.html#300">300</a>, <a href="lwg-defects.html#301">301</a>, <a href="lwg-defects.html#303">303</a>, <a href="lwg-defects.html#305">305</a>, <a href="lwg-defects.html#306">306</a>, <a href="lwg-defects.html#307">307</a>, <a href="lwg-defects.html#308">308</a>, <a href="lwg-defects.html#310">310</a>, <a href="lwg-defects.html#311">311</a>, <a href="lwg-defects.html#312">312</a>, <a href="lwg-defects.html#315">315</a>, <a href="lwg-defects.html#316">316</a>, <a href="lwg-defects.html#317">317</a>, <a href="lwg-defects.html#318">318</a>, <a href="lwg-defects.html#319">319</a>, <a href="lwg-defects.html#320">320</a>, <a href="lwg-defects.html#321">321</a>, <a href="lwg-defects.html#322">322</a>, <a href="lwg-defects.html#324">324</a>, <a href="lwg-defects.html#325">325</a>, <a href="lwg-defects.html#327">327</a>, <a href="lwg-defects.html#328">328</a>, <a href="lwg-defects.html#329">329</a>, <a href="lwg-defects.html#331">331</a>, <a href="lwg-defects.html#333">333</a>, <a href="lwg-defects.html#334">334</a>, <a href="lwg-defects.html#335">335</a>, <a href="lwg-defects.html#336">336</a>, <a href="lwg-defects.html#337">337</a>, <a href="lwg-defects.html#338">338</a>, <a href="lwg-defects.html#339">339</a>, <a href="lwg-defects.html#340">340</a>, <a href="lwg-defects.html#341">341</a>, <a href="lwg-defects.html#345">345</a>, <a href="lwg-defects.html#346">346</a>, <a href="lwg-defects.html#347">347</a>, <a href="lwg-defects.html#349">349</a>, <a href="lwg-defects.html#352">352</a>, <a href="lwg-defects.html#354">354</a>, <a href="lwg-defects.html#355">355</a>, <a href="lwg-defects.html#358">358</a>, <a href="lwg-defects.html#359">359</a>, <a href="lwg-defects.html#360">360</a>, <a href="lwg-defects.html#362">362</a>, <a href="lwg-defects.html#363">363</a>, <a href="lwg-defects.html#364">364</a>, <a href="lwg-defects.html#365">365</a>, <a href="lwg-defects.html#369">369</a>, <a href="lwg-defects.html#370">370</a>, <a href="lwg-defects.html#371">371</a>, <a href="lwg-defects.html#373">373</a>, <a href="lwg-defects.html#375">375</a>, <a href="lwg-defects.html#376">376</a>, <a href="lwg-defects.html#379">379</a>, <a href="lwg-defects.html#380">380</a>, <a href="lwg-defects.html#381">381</a>, <a href="lwg-defects.html#383">383</a>, <a href="lwg-defects.html#384">384</a>, <a href="lwg-defects.html#389">389</a>, <a href="lwg-defects.html#391">391</a>, <a href="lwg-defects.html#395">395</a>, <a href="lwg-defects.html#400">400</a>, <a href="lwg-defects.html#401">401</a>, <a href="lwg-defects.html#402">402</a>, <a href="lwg-defects.html#403">403</a>, <a href="lwg-defects.html#404">404</a>, <a href="lwg-defects.html#405">405</a>, <a href="lwg-defects.html#407">407</a>, <a href="lwg-defects.html#410">410</a>, <a href="lwg-defects.html#411">411</a>, <a href="lwg-defects.html#412">412</a>, <a href="lwg-defects.html#414">414</a>, <a href="lwg-defects.html#415">415</a>, <a href="lwg-defects.html#416">416</a>, <a href="lwg-defects.html#420">420</a>, <a href="lwg-defects.html#422">422</a>, <a href="lwg-defects.html#425">425</a>, <a href="lwg-defects.html#426">426</a>, <a href="lwg-defects.html#428">428</a>, <a href="lwg-defects.html#432">432</a>, <a href="lwg-defects.html#435">435</a>, <a href="lwg-defects.html#436">436</a>, <a href="lwg-defects.html#441">441</a>, <a href="lwg-defects.html#442">442</a>, <a href="lwg-defects.html#443">443</a>, <a href="lwg-defects.html#448">448</a>, <a href="lwg-defects.html#449">449</a>, <a href="lwg-defects.html#453">453</a>, <a href="lwg-defects.html#456">456</a>, <a href="lwg-defects.html#461">461</a>, <a href="lwg-defects.html#464">464</a>, <a href="lwg-defects.html#465">465</a>, <a href="lwg-defects.html#467">467</a>, <a href="lwg-defects.html#468">468</a>, <a href="lwg-defects.html#474">474</a>, <a href="lwg-defects.html#475">475</a>, <a href="lwg-defects.html#478">478</a>, <a href="lwg-defects.html#488">488</a>, <a href="lwg-defects.html#495">495</a>, <a href="lwg-defects.html#496">496</a>, <a href="lwg-defects.html#497">497</a>, <a href="lwg-defects.html#505">505</a>, <a href="lwg-defects.html#507">507</a>, <a href="lwg-defects.html#508">508</a>, <a href="lwg-defects.html#518">518</a>, <a href="lwg-defects.html#519">519</a>, <a href="lwg-defects.html#520">520</a>, <a href="lwg-defects.html#521">521</a>, <a href="lwg-defects.html#524">524</a>, <a href="lwg-defects.html#527">527</a>, <a href="lwg-defects.html#530">530</a>, <a href="lwg-defects.html#531">531</a>, <a href="lwg-defects.html#534">534</a>, <a href="lwg-defects.html#535">535</a>, <a href="lwg-defects.html#537">537</a>, <a href="lwg-defects.html#538">538</a>, <a href="lwg-defects.html#540">540</a>, <a href="lwg-defects.html#541">541</a>, <a href="lwg-defects.html#542">542</a>, <a href="lwg-defects.html#543">543</a>, <a href="lwg-defects.html#545">545</a>, <a href="lwg-defects.html#550">550</a>, <a href="lwg-defects.html#551">551</a>, <a href="lwg-defects.html#552">552</a>, <a href="lwg-defects.html#559">559</a>, <a href="lwg-defects.html#561">561</a>, <a href="lwg-defects.html#562">562</a>, <a href="lwg-defects.html#563">563</a>, <a href="lwg-defects.html#566">566</a>, <a href="lwg-defects.html#567">567</a>, <a href="lwg-defects.html#574">574</a>, <a href="lwg-defects.html#575">575</a>, <a href="lwg-defects.html#576">576</a>, <a href="lwg-defects.html#577">577</a>, <a href="lwg-defects.html#578">578</a>, <a href="lwg-defects.html#581">581</a>, <a href="lwg-defects.html#586">586</a>, <a href="lwg-defects.html#589">589</a>, <a href="lwg-defects.html#593">593</a>, <a href="lwg-defects.html#595">595</a>, <a href="lwg-defects.html#596">596</a>, <a href="lwg-defects.html#607">607</a>, <a href="lwg-defects.html#608">608</a>, <a href="lwg-defects.html#609">609</a>, <a href="lwg-defects.html#610">610</a>, <a href="lwg-defects.html#611">611</a>, <a href="lwg-defects.html#612">612</a>, <a href="lwg-defects.html#613">613</a>, <a href="lwg-defects.html#616">616</a>, <a href="lwg-defects.html#618">618</a>, <a href="lwg-defects.html#619">619</a>, <a href="lwg-defects.html#620">620</a>, <a href="lwg-defects.html#621">621</a>, <a href="lwg-defects.html#622">622</a>, <a href="lwg-defects.html#623">623</a>, <a href="lwg-defects.html#624">624</a>, <a href="lwg-defects.html#628">628</a>, <a href="lwg-defects.html#634">634</a>, <a href="lwg-defects.html#638">638</a>, <a href="lwg-defects.html#640">640</a>, <a href="lwg-defects.html#643">643</a>, <a href="lwg-defects.html#646">646</a>, <a href="lwg-defects.html#650">650</a>, <a href="lwg-defects.html#651">651</a>, <a href="lwg-defects.html#652">652</a>, <a href="lwg-defects.html#654">654</a>, <a href="lwg-defects.html#655">655</a>, <a href="lwg-defects.html#660">660</a>, <a href="lwg-defects.html#661">661</a>, <a href="lwg-defects.html#664">664</a>, <a href="lwg-defects.html#665">665</a>, <a href="lwg-defects.html#666">666</a>, <a href="lwg-defects.html#672">672</a>, <a href="lwg-defects.html#673">673</a>, <a href="lwg-defects.html#674">674</a>, <a href="lwg-defects.html#677">677</a>, <a href="lwg-defects.html#678">678</a>, <a href="lwg-defects.html#679">679</a>, <a href="lwg-defects.html#680">680</a>, <a href="lwg-defects.html#681">681</a>, <a href="lwg-defects.html#682">682</a>, <a href="lwg-defects.html#685">685</a>, <a href="lwg-defects.html#687">687</a>, <a href="lwg-defects.html#689">689</a>, <a href="lwg-defects.html#693">693</a>, <a href="lwg-defects.html#694">694</a>, <a href="lwg-defects.html#695">695</a>, <a href="lwg-defects.html#699">699</a>, <a href="lwg-defects.html#700">700</a>, <a href="lwg-defects.html#703">703</a>, <a href="lwg-defects.html#705">705</a>, <a href="lwg-defects.html#706">706</a>, <a href="lwg-defects.html#710">710</a>, <a href="lwg-defects.html#712">712</a>, <a href="lwg-defects.html#715">715</a>, <a href="lwg-defects.html#722">722</a>, <a href="lwg-defects.html#740">740</a>, <a href="lwg-defects.html#743">743</a>, <a href="lwg-defects.html#744">744</a>, <a href="lwg-defects.html#746">746</a>, <a href="lwg-defects.html#749">749</a>, <a href="lwg-defects.html#755">755</a>, <a href="lwg-defects.html#759">759</a>, <a href="lwg-defects.html#761">761</a>, <a href="lwg-defects.html#766">766</a>, <a href="lwg-defects.html#768">768</a>, <a href="lwg-defects.html#770">770</a>, <a href="lwg-defects.html#775">775</a>, <a href="lwg-defects.html#777">777</a>, <a href="lwg-defects.html#778">778</a>, <a href="lwg-defects.html#781">781</a>, <a href="lwg-defects.html#782">782</a>, <a href="lwg-defects.html#783">783</a>, <a href="lwg-defects.html#789">789</a>, <a href="lwg-defects.html#792">792</a>, <a href="lwg-defects.html#798">798</a>.</li>
<li>Changed the following issues from Open to Dup: <a href="lwg-closed.html#670">670</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#849">849</a>, <a href="lwg-closed.html#855">855</a>, <a href="lwg-defects.html#871">871</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#454">454</a>, <a href="lwg-closed.html#832">832</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#811">811</a>, <a href="lwg-closed.html#812">812</a>, <a href="lwg-closed.html#841">841</a>, <a href="lwg-closed.html#864">864</a>, <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#872">872</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#299">299</a>, <a href="lwg-closed.html#484">484</a>, <a href="lwg-defects.html#556">556</a>, <a href="lwg-closed.html#631">631</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#742">742</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#532">532</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-closed.html#717">717</a>, <a href="lwg-closed.html#725">725</a>, <a href="lwg-closed.html#738">738</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-closed.html#721">721</a>, <a href="lwg-closed.html#751">751</a>, <a href="lwg-defects.html#814">814</a>, <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#817">817</a>, <a href="lwg-defects.html#819">819</a>, <a href="lwg-defects.html#827">827</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-defects.html#838">838</a>, <a href="lwg-defects.html#847">847</a>, <a href="lwg-defects.html#857">857</a>, <a href="lwg-defects.html#859">859</a>, <a href="lwg-defects.html#860">860</a>, <a href="lwg-defects.html#861">861</a>, <a href="lwg-defects.html#868">868</a>, <a href="lwg-closed.html#873">873</a>, <a href="lwg-defects.html#876">876</a>, <a href="lwg-closed.html#877">877</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to Open: <a href="lwg-closed.html#424">424</a>, <a href="lwg-defects.html#625">625</a>.</li>
<li>Changed the following issues from Review to Open: <a href="lwg-closed.html#851">851</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#788">788</a>, <a href="lwg-defects.html#821">821</a>, <a href="lwg-defects.html#866">866</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#753">753</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#752">752</a>, <a href="lwg-defects.html#758">758</a>, <a href="lwg-defects.html#803">803</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#765">765</a>, <a href="lwg-closed.html#822">822</a>, <a href="lwg-defects.html#853">853</a>, <a href="lwg-defects.html#854">854</a>, <a href="lwg-defects.html#869">869</a>, <a href="lwg-defects.html#878">878</a>.</li>
<li>Changed the following issues from TC to TC1: <a href="lwg-defects.html#1">1</a>, <a href="lwg-defects.html#3">3</a>, <a href="lwg-defects.html#5">5</a>, <a href="lwg-defects.html#7">7</a>, <a href="lwg-defects.html#8">8</a>, <a href="lwg-defects.html#9">9</a>, <a href="lwg-defects.html#11">11</a>, <a href="lwg-defects.html#13">13</a>, <a href="lwg-defects.html#14">14</a>, <a href="lwg-defects.html#15">15</a>, <a href="lwg-defects.html#16">16</a>, <a href="lwg-defects.html#17">17</a>, <a href="lwg-defects.html#18">18</a>, <a href="lwg-defects.html#19">19</a>, <a href="lwg-defects.html#20">20</a>, <a href="lwg-defects.html#21">21</a>, <a href="lwg-defects.html#22">22</a>, <a href="lwg-defects.html#24">24</a>, <a href="lwg-defects.html#25">25</a>, <a href="lwg-defects.html#26">26</a>, <a href="lwg-defects.html#27">27</a>, <a href="lwg-defects.html#28">28</a>, <a href="lwg-defects.html#29">29</a>, <a href="lwg-defects.html#30">30</a>, <a href="lwg-defects.html#31">31</a>, <a href="lwg-defects.html#32">32</a>, <a href="lwg-defects.html#33">33</a>, <a href="lwg-defects.html#34">34</a>, <a href="lwg-defects.html#35">35</a>, <a href="lwg-defects.html#36">36</a>, <a href="lwg-defects.html#37">37</a>, <a href="lwg-defects.html#38">38</a>, <a href="lwg-defects.html#39">39</a>, <a href="lwg-defects.html#40">40</a>, <a href="lwg-defects.html#41">41</a>, <a href="lwg-defects.html#42">42</a>, <a href="lwg-defects.html#46">46</a>, <a href="lwg-defects.html#47">47</a>, <a href="lwg-defects.html#48">48</a>, <a href="lwg-defects.html#50">50</a>, <a href="lwg-defects.html#51">51</a>, <a href="lwg-defects.html#52">52</a>, <a href="lwg-defects.html#53">53</a>, <a href="lwg-defects.html#54">54</a>, <a href="lwg-defects.html#55">55</a>, <a href="lwg-defects.html#56">56</a>, <a href="lwg-defects.html#57">57</a>, <a href="lwg-defects.html#59">59</a>, <a href="lwg-defects.html#60">60</a>, <a href="lwg-defects.html#61">61</a>, <a href="lwg-defects.html#62">62</a>, <a href="lwg-defects.html#63">63</a>, <a href="lwg-defects.html#64">64</a>, <a href="lwg-defects.html#66">66</a>, <a href="lwg-defects.html#68">68</a>, <a href="lwg-defects.html#69">69</a>, <a href="lwg-defects.html#70">70</a>, <a href="lwg-defects.html#71">71</a>, <a href="lwg-defects.html#74">74</a>, <a href="lwg-defects.html#75">75</a>, <a href="lwg-defects.html#78">78</a>, <a href="lwg-defects.html#79">79</a>, <a href="lwg-defects.html#80">80</a>, <a href="lwg-defects.html#83">83</a>, <a href="lwg-defects.html#86">86</a>, <a href="lwg-defects.html#90">90</a>, <a href="lwg-defects.html#106">106</a>, <a href="lwg-defects.html#108">108</a>, <a href="lwg-defects.html#110">110</a>, <a href="lwg-defects.html#112">112</a>, <a href="lwg-defects.html#114">114</a>, <a href="lwg-defects.html#115">115</a>, <a href="lwg-defects.html#119">119</a>, <a href="lwg-defects.html#122">122</a>, <a href="lwg-defects.html#124">124</a>, <a href="lwg-defects.html#125">125</a>, <a href="lwg-defects.html#126">126</a>, <a href="lwg-defects.html#127">127</a>, <a href="lwg-defects.html#129">129</a>, <a href="lwg-defects.html#132">132</a>, <a href="lwg-defects.html#133">133</a>, <a href="lwg-defects.html#134">134</a>, <a href="lwg-defects.html#137">137</a>, <a href="lwg-defects.html#139">139</a>, <a href="lwg-defects.html#141">141</a>, <a href="lwg-defects.html#142">142</a>, <a href="lwg-defects.html#144">144</a>, <a href="lwg-defects.html#146">146</a>, <a href="lwg-defects.html#147">147</a>, <a href="lwg-defects.html#148">148</a>, <a href="lwg-defects.html#150">150</a>, <a href="lwg-defects.html#151">151</a>, <a href="lwg-defects.html#152">152</a>, <a href="lwg-defects.html#154">154</a>, <a href="lwg-defects.html#155">155</a>, <a href="lwg-defects.html#156">156</a>, <a href="lwg-defects.html#158">158</a>, <a href="lwg-defects.html#159">159</a>, <a href="lwg-defects.html#160">160</a>, <a href="lwg-defects.html#161">161</a>, <a href="lwg-defects.html#164">164</a>, <a href="lwg-defects.html#168">168</a>, <a href="lwg-defects.html#169">169</a>, <a href="lwg-defects.html#170">170</a>, <a href="lwg-defects.html#172">172</a>, <a href="lwg-defects.html#173">173</a>, <a href="lwg-defects.html#174">174</a>, <a href="lwg-defects.html#175">175</a>, <a href="lwg-defects.html#176">176</a>, <a href="lwg-defects.html#181">181</a>, <a href="lwg-defects.html#189">189</a>, <a href="lwg-defects.html#193">193</a>, <a href="lwg-defects.html#195">195</a>, <a href="lwg-defects.html#199">199</a>, <a href="lwg-defects.html#208">208</a>, <a href="lwg-defects.html#209">209</a>, <a href="lwg-defects.html#210">210</a>, <a href="lwg-defects.html#211">211</a>, <a href="lwg-defects.html#212">212</a>, <a href="lwg-defects.html#217">217</a>, <a href="lwg-defects.html#220">220</a>, <a href="lwg-defects.html#222">222</a>, <a href="lwg-defects.html#223">223</a>, <a href="lwg-defects.html#224">224</a>, <a href="lwg-defects.html#227">227</a>.</li>
</ul></li>
</ul>
</li>
<li>R59: 
2008-08-22 pre-San Francisco mailing.
<ul>
<li><b>Summary:</b><ul>
<li>192 open issues, up by 9.</li>
<li>686 closed issues, up by 0.</li>
<li>878 issues total, up by 9.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#871">871</a>, <a href="lwg-defects.html#872">872</a>, <a href="lwg-closed.html#873">873</a>, <a href="lwg-defects.html#874">874</a>, <a href="lwg-defects.html#875">875</a>, <a href="lwg-defects.html#876">876</a>, <a href="lwg-closed.html#877">877</a>, <a href="lwg-defects.html#878">878</a>.</li>
</ul></li>
</ul>
</li>
<li>R58: 
2008-07-28 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>183 open issues, up by 12.</li>
<li>686 closed issues, down by 4.</li>
<li>869 issues total, up by 8.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-closed.html#862">862</a>, <a href="lwg-closed.html#863">863</a>, <a href="lwg-closed.html#864">864</a>, <a href="lwg-defects.html#865">865</a>, <a href="lwg-defects.html#866">866</a>, <a href="lwg-closed.html#867">867</a>, <a href="lwg-defects.html#868">868</a>, <a href="lwg-defects.html#869">869</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#393">393</a>, <a href="lwg-closed.html#557">557</a>, <a href="lwg-closed.html#592">592</a>, <a href="lwg-closed.html#754">754</a>, <a href="lwg-closed.html#757">757</a>.</li>
<li>Changed the following issues from Pending WP to Open: <a href="lwg-closed.html#644">644</a>.</li>
<li>Changed the following issues from WP to Ready: <a href="lwg-defects.html#387">387</a>, <a href="lwg-defects.html#629">629</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to Review: <a href="lwg-defects.html#709">709</a>.</li>
</ul></li>
</ul>
</li>
<li>R57: 
2008-06-27 post-Sophia Antipolis mailing.
<ul>
<li><b>Summary:</b><ul>
<li>171 open issues, down by 20.</li>
<li>690 closed issues, up by 43.</li>
<li>861 issues total, up by 23.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issues: <a href="lwg-closed.html#840">840</a>.</li>
<li>Added the following New issues: <a href="lwg-closed.html#841">841</a>, <a href="lwg-defects.html#843">843</a>, <a href="lwg-defects.html#845">845</a>, <a href="lwg-defects.html#846">846</a>, <a href="lwg-defects.html#847">847</a>, <a href="lwg-closed.html#849">849</a>, <a href="lwg-defects.html#853">853</a>, <a href="lwg-defects.html#854">854</a>, <a href="lwg-closed.html#855">855</a>, <a href="lwg-defects.html#856">856</a>, <a href="lwg-defects.html#857">857</a>, <a href="lwg-defects.html#858">858</a>, <a href="lwg-defects.html#859">859</a>, <a href="lwg-defects.html#860">860</a>, <a href="lwg-defects.html#861">861</a>.</li>
<li>Added the following Open issues: <a href="lwg-closed.html#839">839</a>.</li>
<li>Added the following Ready issues: <a href="lwg-defects.html#842">842</a>, <a href="lwg-defects.html#844">844</a>, <a href="lwg-defects.html#848">848</a>, <a href="lwg-defects.html#850">850</a>, <a href="lwg-defects.html#852">852</a>.</li>
<li>Added the following Review issues: <a href="lwg-closed.html#851">851</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#826">826</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#570">570</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#786">786</a>, <a href="lwg-closed.html#831">831</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-defects.html#756">756</a>, <a href="lwg-defects.html#767">767</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#723">723</a>, <a href="lwg-closed.html#726">726</a>, <a href="lwg-defects.html#794">794</a>, <a href="lwg-defects.html#815">815</a>, <a href="lwg-defects.html#825">825</a>, <a href="lwg-closed.html#830">830</a>, <a href="lwg-closed.html#833">833</a>, <a href="lwg-defects.html#834">834</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="lwg-defects.html#471">471</a>.</li>
<li>Changed the following issues from Review to Open: <a href="lwg-defects.html#539">539</a>, <a href="lwg-defects.html#711">711</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#713">713</a>, <a href="lwg-defects.html#714">714</a>, <a href="lwg-defects.html#769">769</a>, <a href="lwg-defects.html#772">772</a>, <a href="lwg-defects.html#779">779</a>, <a href="lwg-defects.html#787">787</a>, <a href="lwg-defects.html#805">805</a>, <a href="lwg-defects.html#806">806</a>, <a href="lwg-defects.html#807">807</a>, <a href="lwg-defects.html#808">808</a>, <a href="lwg-defects.html#809">809</a>, <a href="lwg-defects.html#813">813</a>, <a href="lwg-defects.html#824">824</a>, <a href="lwg-defects.html#829">829</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#180">180</a>, <a href="lwg-defects.html#396">396</a>, <a href="lwg-defects.html#522">522</a>, <a href="lwg-defects.html#720">720</a>, <a href="lwg-defects.html#762">762</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#691">691</a>, <a href="lwg-defects.html#728">728</a>, <a href="lwg-defects.html#771">771</a>, <a href="lwg-defects.html#776">776</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#692">692</a>, <a href="lwg-defects.html#698">698</a>, <a href="lwg-defects.html#752">752</a>, <a href="lwg-defects.html#804">804</a>, <a href="lwg-defects.html#823">823</a>, <a href="lwg-defects.html#828">828</a>, <a href="lwg-closed.html#832">832</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#23">23</a>, <a href="lwg-defects.html#675">675</a>, <a href="lwg-defects.html#734">734</a>, <a href="lwg-defects.html#803">803</a>.</li>
<li>Changed the following issues from Ready to Review: <a href="lwg-defects.html#758">758</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#387">387</a>, <a href="lwg-defects.html#518">518</a>, <a href="lwg-defects.html#550">550</a>, <a href="lwg-defects.html#574">574</a>, <a href="lwg-defects.html#595">595</a>, <a href="lwg-defects.html#596">596</a>, <a href="lwg-defects.html#612">612</a>, <a href="lwg-defects.html#618">618</a>, <a href="lwg-defects.html#629">629</a>, <a href="lwg-defects.html#638">638</a>, <a href="lwg-defects.html#672">672</a>, <a href="lwg-defects.html#673">673</a>, <a href="lwg-defects.html#685">685</a>, <a href="lwg-defects.html#710">710</a>, <a href="lwg-defects.html#715">715</a>, <a href="lwg-defects.html#722">722</a>, <a href="lwg-defects.html#740">740</a>, <a href="lwg-defects.html#743">743</a>, <a href="lwg-defects.html#744">744</a>, <a href="lwg-defects.html#746">746</a>, <a href="lwg-defects.html#749">749</a>, <a href="lwg-defects.html#755">755</a>, <a href="lwg-defects.html#759">759</a>, <a href="lwg-defects.html#761">761</a>, <a href="lwg-defects.html#766">766</a>, <a href="lwg-defects.html#768">768</a>, <a href="lwg-defects.html#770">770</a>, <a href="lwg-defects.html#775">775</a>, <a href="lwg-defects.html#777">777</a>, <a href="lwg-defects.html#778">778</a>, <a href="lwg-defects.html#781">781</a>, <a href="lwg-defects.html#782">782</a>, <a href="lwg-defects.html#783">783</a>, <a href="lwg-defects.html#789">789</a>, <a href="lwg-defects.html#792">792</a>, <a href="lwg-defects.html#798">798</a>.</li>
</ul></li>
</ul>
</li>
<li>R56: 
2008-05-16 pre-Sophia Antipolis mailing.
<ul>
<li><b>Summary:</b><ul>
<li>191 open issues, up by 24.</li>
<li>647 closed issues, up by 1.</li>
<li>838 issues total, up by 25.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#814">814</a>, <a href="lwg-defects.html#815">815</a>, <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#817">817</a>, <a href="lwg-defects.html#818">818</a>, <a href="lwg-defects.html#819">819</a>, <a href="lwg-defects.html#820">820</a>, <a href="lwg-defects.html#821">821</a>, <a href="lwg-closed.html#822">822</a>, <a href="lwg-defects.html#823">823</a>, <a href="lwg-defects.html#824">824</a>, <a href="lwg-defects.html#825">825</a>, <a href="lwg-closed.html#826">826</a>, <a href="lwg-defects.html#827">827</a>, <a href="lwg-defects.html#828">828</a>, <a href="lwg-defects.html#829">829</a>, <a href="lwg-closed.html#830">830</a>, <a href="lwg-closed.html#831">831</a>, <a href="lwg-closed.html#832">832</a>, <a href="lwg-closed.html#833">833</a>, <a href="lwg-defects.html#834">834</a>, <a href="lwg-defects.html#835">835</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-closed.html#837">837</a>, <a href="lwg-defects.html#838">838</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#802">802</a>.</li>
</ul></li>
</ul>
</li>
<li>R55: 
2008-03-14 post-Bellevue mailing.
<ul>
<li><b>Summary:</b><ul>
<li>167 open issues, down by 39.</li>
<li>646 closed issues, up by 65.</li>
<li>813 issues total, up by 26.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following Dup issues: <a href="lwg-closed.html#795">795</a>.</li>
<li>Added the following NAD issues: <a href="lwg-closed.html#790">790</a>, <a href="lwg-closed.html#791">791</a>, <a href="lwg-closed.html#796">796</a>, <a href="lwg-closed.html#797">797</a>, <a href="lwg-closed.html#799">799</a>.</li>
<li>Added the following New issues: <a href="lwg-defects.html#788">788</a>, <a href="lwg-defects.html#794">794</a>, <a href="lwg-closed.html#802">802</a>, <a href="lwg-defects.html#804">804</a>, <a href="lwg-defects.html#805">805</a>, <a href="lwg-defects.html#806">806</a>, <a href="lwg-defects.html#807">807</a>, <a href="lwg-defects.html#808">808</a>, <a href="lwg-defects.html#809">809</a>, <a href="lwg-defects.html#810">810</a>, <a href="lwg-defects.html#811">811</a>, <a href="lwg-closed.html#812">812</a>, <a href="lwg-defects.html#813">813</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#793">793</a>, <a href="lwg-defects.html#800">800</a>, <a href="lwg-defects.html#801">801</a>, <a href="lwg-defects.html#803">803</a>.</li>
<li>Added the following Ready issues: <a href="lwg-defects.html#789">789</a>, <a href="lwg-defects.html#792">792</a>, <a href="lwg-defects.html#798">798</a>.</li>
<li>Changed the following issues from NAD Future to Dup: <a href="lwg-closed.html#116">116</a>.</li>
<li>Changed the following issues from NAD Future to NAD: <a href="lwg-closed.html#188">188</a>, <a href="lwg-closed.html#323">323</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#729">729</a>, <a href="lwg-closed.html#730">730</a>, <a href="lwg-closed.html#731">731</a>, <a href="lwg-closed.html#733">733</a>, <a href="lwg-closed.html#735">735</a>, <a href="lwg-closed.html#736">736</a>, <a href="lwg-closed.html#737">737</a>, <a href="lwg-closed.html#739">739</a>, <a href="lwg-closed.html#741">741</a>, <a href="lwg-closed.html#745">745</a>, <a href="lwg-closed.html#748">748</a>, <a href="lwg-closed.html#763">763</a>, <a href="lwg-closed.html#764">764</a>, <a href="lwg-closed.html#773">773</a>, <a href="lwg-closed.html#784">784</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#388">388</a>, <a href="lwg-closed.html#462">462</a>, <a href="lwg-closed.html#579">579</a>, <a href="lwg-closed.html#627">627</a>, <a href="lwg-closed.html#653">653</a>, <a href="lwg-closed.html#686">686</a>, <a href="lwg-closed.html#707">707</a>.</li>
<li>Changed the following issues from NAD Future to NAD Editorial: <a href="lwg-closed.html#140">140</a>, <a href="lwg-closed.html#390">390</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#529">529</a>, <a href="lwg-closed.html#626">626</a>.</li>
<li>Changed the following issues from Review to NAD Editorial: <a href="lwg-closed.html#645">645</a>, <a href="lwg-closed.html#684">684</a>.</li>
<li>Changed the following issues from NAD Future to Open: <a href="lwg-closed.html#128">128</a>, <a href="lwg-defects.html#180">180</a>, <a href="lwg-closed.html#190">190</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-closed.html#617">617</a>, <a href="lwg-closed.html#718">718</a>, <a href="lwg-defects.html#719">719</a>, <a href="lwg-defects.html#720">720</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#732">732</a>, <a href="lwg-defects.html#734">734</a>, <a href="lwg-defects.html#742">742</a>, <a href="lwg-closed.html#747">747</a>, <a href="lwg-closed.html#750">750</a>, <a href="lwg-defects.html#753">753</a>, <a href="lwg-defects.html#756">756</a>, <a href="lwg-closed.html#760">760</a>, <a href="lwg-defects.html#762">762</a>, <a href="lwg-defects.html#767">767</a>, <a href="lwg-defects.html#774">774</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="lwg-defects.html#675">675</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#688">688</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="lwg-defects.html#709">709</a>, <a href="lwg-closed.html#717">717</a>, <a href="lwg-closed.html#725">725</a>, <a href="lwg-closed.html#738">738</a>, <a href="lwg-closed.html#754">754</a>, <a href="lwg-closed.html#757">757</a>.</li>
<li>Changed the following issues from Open to Pending NAD Editorial: <a href="lwg-closed.html#424">424</a>, <a href="lwg-closed.html#557">557</a>, <a href="lwg-defects.html#625">625</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#710">710</a>, <a href="lwg-defects.html#715">715</a>, <a href="lwg-defects.html#722">722</a>, <a href="lwg-defects.html#740">740</a>, <a href="lwg-defects.html#743">743</a>, <a href="lwg-defects.html#744">744</a>, <a href="lwg-defects.html#746">746</a>, <a href="lwg-defects.html#749">749</a>, <a href="lwg-defects.html#755">755</a>, <a href="lwg-defects.html#758">758</a>, <a href="lwg-defects.html#759">759</a>, <a href="lwg-defects.html#761">761</a>, <a href="lwg-defects.html#766">766</a>, <a href="lwg-defects.html#768">768</a>, <a href="lwg-defects.html#770">770</a>, <a href="lwg-defects.html#775">775</a>, <a href="lwg-defects.html#777">777</a>, <a href="lwg-defects.html#778">778</a>, <a href="lwg-defects.html#781">781</a>, <a href="lwg-defects.html#782">782</a>, <a href="lwg-defects.html#783">783</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#387">387</a>, <a href="lwg-defects.html#471">471</a>, <a href="lwg-defects.html#550">550</a>, <a href="lwg-defects.html#612">612</a>, <a href="lwg-defects.html#629">629</a>, <a href="lwg-defects.html#673">673</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#518">518</a>, <a href="lwg-defects.html#574">574</a>, <a href="lwg-defects.html#596">596</a>, <a href="lwg-defects.html#618">618</a>, <a href="lwg-defects.html#638">638</a>, <a href="lwg-defects.html#672">672</a>, <a href="lwg-defects.html#685">685</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#711">711</a>, <a href="lwg-defects.html#728">728</a>, <a href="lwg-defects.html#771">771</a>, <a href="lwg-defects.html#776">776</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#539">539</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#561">561</a>, <a href="lwg-defects.html#562">562</a>, <a href="lwg-defects.html#563">563</a>, <a href="lwg-defects.html#567">567</a>, <a href="lwg-defects.html#581">581</a>, <a href="lwg-defects.html#620">620</a>, <a href="lwg-defects.html#621">621</a>, <a href="lwg-defects.html#622">622</a>, <a href="lwg-defects.html#623">623</a>, <a href="lwg-defects.html#624">624</a>, <a href="lwg-defects.html#661">661</a>, <a href="lwg-defects.html#664">664</a>, <a href="lwg-defects.html#665">665</a>, <a href="lwg-defects.html#666">666</a>, <a href="lwg-defects.html#674">674</a>, <a href="lwg-defects.html#679">679</a>, <a href="lwg-defects.html#680">680</a>, <a href="lwg-defects.html#687">687</a>, <a href="lwg-defects.html#689">689</a>, <a href="lwg-defects.html#693">693</a>, <a href="lwg-defects.html#694">694</a>, <a href="lwg-defects.html#695">695</a>, <a href="lwg-defects.html#700">700</a>, <a href="lwg-defects.html#703">703</a>, <a href="lwg-defects.html#705">705</a>, <a href="lwg-defects.html#706">706</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="lwg-defects.html#527">527</a>.</li>
</ul></li>
</ul>
</li>
<li>R54: 
2008-02-01 pre-Bellevue mailing.
<ul>
<li><b>Summary:</b><ul>
<li>206 open issues, up by 23.</li>
<li>581 closed issues, up by 0.</li>
<li>787 issues total, up by 23.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#765">765</a>, <a href="lwg-defects.html#766">766</a>, <a href="lwg-defects.html#767">767</a>, <a href="lwg-defects.html#768">768</a>, <a href="lwg-defects.html#769">769</a>, <a href="lwg-defects.html#770">770</a>, <a href="lwg-defects.html#771">771</a>, <a href="lwg-defects.html#772">772</a>, <a href="lwg-closed.html#773">773</a>, <a href="lwg-defects.html#774">774</a>, <a href="lwg-defects.html#775">775</a>, <a href="lwg-defects.html#776">776</a>, <a href="lwg-defects.html#777">777</a>, <a href="lwg-defects.html#778">778</a>, <a href="lwg-defects.html#779">779</a>, <a href="lwg-defects.html#780">780</a>, <a href="lwg-defects.html#781">781</a>, <a href="lwg-defects.html#782">782</a>, <a href="lwg-defects.html#783">783</a>, <a href="lwg-closed.html#784">784</a>, <a href="lwg-closed.html#785">785</a>, <a href="lwg-defects.html#786">786</a>, <a href="lwg-defects.html#787">787</a>.</li>
<li>Changed the following issues from NAD Future to Dup: <a href="lwg-closed.html#105">105</a>, <a href="lwg-closed.html#348">348</a>.</li>
<li>Changed the following issues from NAD Future to NAD Editorial: <a href="lwg-defects.html#353">353</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#697">697</a>.</li>
<li>Changed the following issues from NAD Future to Open: <a href="lwg-closed.html#388">388</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#527">527</a>.</li>
</ul></li>
</ul>
</li>
<li>R53: 
2007-12-09 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>183 open issues, up by 11.</li>
<li>581 closed issues, down by 1.</li>
<li>764 issues total, up by 10.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#755">755</a>, <a href="lwg-defects.html#756">756</a>, <a href="lwg-closed.html#757">757</a>, <a href="lwg-defects.html#758">758</a>, <a href="lwg-defects.html#759">759</a>, <a href="lwg-closed.html#760">760</a>, <a href="lwg-defects.html#761">761</a>, <a href="lwg-defects.html#762">762</a>, <a href="lwg-closed.html#763">763</a>, <a href="lwg-closed.html#764">764</a>.</li>
<li>Changed the following issues from NAD to Open: <a href="lwg-closed.html#463">463</a>.</li>
<li>Changed the following issues from Pending WP to WP: <a href="lwg-defects.html#607">607</a>, <a href="lwg-defects.html#608">608</a>, <a href="lwg-defects.html#654">654</a>, <a href="lwg-defects.html#655">655</a>, <a href="lwg-defects.html#677">677</a>, <a href="lwg-defects.html#682">682</a>.</li>
</ul></li>
</ul>
</li>
<li>R52: 
2007-10-19 post-Kona mailing.
<ul>
<li><b>Summary:</b><ul>
<li>172 open issues, up by 4.</li>
<li>582 closed issues, up by 27.</li>
<li>754 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#724">724</a>, <a href="lwg-closed.html#725">725</a>, <a href="lwg-closed.html#726">726</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#728">728</a>, <a href="lwg-closed.html#729">729</a>, <a href="lwg-closed.html#730">730</a>, <a href="lwg-closed.html#731">731</a>, <a href="lwg-defects.html#732">732</a>, <a href="lwg-closed.html#733">733</a>, <a href="lwg-defects.html#734">734</a>, <a href="lwg-closed.html#735">735</a>, <a href="lwg-closed.html#736">736</a>, <a href="lwg-closed.html#737">737</a>, <a href="lwg-closed.html#738">738</a>, <a href="lwg-closed.html#739">739</a>, <a href="lwg-defects.html#740">740</a>, <a href="lwg-closed.html#741">741</a>, <a href="lwg-defects.html#742">742</a>, <a href="lwg-defects.html#743">743</a>, <a href="lwg-defects.html#744">744</a>, <a href="lwg-closed.html#745">745</a>, <a href="lwg-defects.html#746">746</a>, <a href="lwg-closed.html#747">747</a>, <a href="lwg-closed.html#748">748</a>, <a href="lwg-defects.html#749">749</a>, <a href="lwg-closed.html#750">750</a>, <a href="lwg-closed.html#751">751</a>, <a href="lwg-defects.html#752">752</a>, <a href="lwg-defects.html#753">753</a>, <a href="lwg-closed.html#754">754</a>.</li>
<li>Changed the following issues from NAD Future to Dup: <a href="lwg-closed.html#77">77</a>, <a href="lwg-closed.html#350">350</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#639">639</a>, <a href="lwg-closed.html#657">657</a>, <a href="lwg-closed.html#663">663</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#548">548</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-closed.html#546">546</a>, <a href="lwg-defects.html#550">550</a>, <a href="lwg-defects.html#564">564</a>, <a href="lwg-defects.html#565">565</a>, <a href="lwg-closed.html#573">573</a>, <a href="lwg-closed.html#585">585</a>, <a href="lwg-closed.html#588">588</a>, <a href="lwg-closed.html#627">627</a>, <a href="lwg-defects.html#629">629</a>, <a href="lwg-defects.html#630">630</a>, <a href="lwg-closed.html#632">632</a>, <a href="lwg-defects.html#635">635</a>, <a href="lwg-closed.html#653">653</a>, <a href="lwg-defects.html#659">659</a>, <a href="lwg-closed.html#667">667</a>, <a href="lwg-closed.html#668">668</a>, <a href="lwg-closed.html#669">669</a>, <a href="lwg-closed.html#670">670</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#673">673</a>, <a href="lwg-closed.html#686">686</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-closed.html#707">707</a>, <a href="lwg-closed.html#708">708</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="lwg-closed.html#393">393</a>, <a href="lwg-closed.html#592">592</a>.</li>
<li>Changed the following issues from New to Pending WP: <a href="lwg-defects.html#607">607</a>, <a href="lwg-defects.html#608">608</a>, <a href="lwg-defects.html#654">654</a>, <a href="lwg-defects.html#655">655</a>, <a href="lwg-defects.html#677">677</a>, <a href="lwg-defects.html#682">682</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#561">561</a>, <a href="lwg-defects.html#562">562</a>, <a href="lwg-defects.html#563">563</a>, <a href="lwg-defects.html#567">567</a>, <a href="lwg-defects.html#581">581</a>, <a href="lwg-defects.html#595">595</a>, <a href="lwg-defects.html#620">620</a>, <a href="lwg-defects.html#621">621</a>, <a href="lwg-defects.html#622">622</a>, <a href="lwg-defects.html#623">623</a>, <a href="lwg-defects.html#624">624</a>, <a href="lwg-defects.html#661">661</a>, <a href="lwg-defects.html#664">664</a>, <a href="lwg-defects.html#665">665</a>, <a href="lwg-defects.html#666">666</a>, <a href="lwg-defects.html#674">674</a>, <a href="lwg-defects.html#675">675</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#679">679</a>, <a href="lwg-defects.html#687">687</a>, <a href="lwg-defects.html#688">688</a>, <a href="lwg-defects.html#689">689</a>, <a href="lwg-defects.html#693">693</a>, <a href="lwg-defects.html#694">694</a>, <a href="lwg-defects.html#695">695</a>, <a href="lwg-defects.html#700">700</a>, <a href="lwg-defects.html#703">703</a>, <a href="lwg-defects.html#705">705</a>, <a href="lwg-defects.html#706">706</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#680">680</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#574">574</a>, <a href="lwg-defects.html#596">596</a>, <a href="lwg-defects.html#618">618</a>, <a href="lwg-defects.html#638">638</a>, <a href="lwg-closed.html#645">645</a>, <a href="lwg-defects.html#672">672</a>, <a href="lwg-closed.html#684">684</a>, <a href="lwg-defects.html#685">685</a>, <a href="lwg-defects.html#691">691</a>.</li>
<li>Changed the following issues from New to WP: <a href="lwg-defects.html#552">552</a>, <a href="lwg-defects.html#634">634</a>, <a href="lwg-defects.html#650">650</a>, <a href="lwg-defects.html#651">651</a>, <a href="lwg-defects.html#652">652</a>, <a href="lwg-defects.html#678">678</a>, <a href="lwg-defects.html#681">681</a>, <a href="lwg-defects.html#699">699</a>, <a href="lwg-defects.html#712">712</a>.</li>
<li>Changed the following issues from Open to WP: <a href="lwg-defects.html#258">258</a>, <a href="lwg-defects.html#401">401</a>, <a href="lwg-defects.html#524">524</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#488">488</a>, <a href="lwg-defects.html#577">577</a>, <a href="lwg-defects.html#660">660</a>.</li>
</ul></li>
</ul>
</li>
<li>R51: 
2007-09-09 pre-Kona mailing.
<ul>
<li><b>Summary:</b><ul>
<li>168 open issues, up by 15.</li>
<li>555 closed issues, up by 0.</li>
<li>723 issues total, up by 15.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#709">709</a>, <a href="lwg-defects.html#710">710</a>, <a href="lwg-defects.html#711">711</a>, <a href="lwg-defects.html#712">712</a>, <a href="lwg-defects.html#713">713</a>, <a href="lwg-defects.html#714">714</a>, <a href="lwg-defects.html#715">715</a>, <a href="lwg-defects.html#716">716</a>, <a href="lwg-closed.html#717">717</a>, <a href="lwg-closed.html#718">718</a>, <a href="lwg-defects.html#719">719</a>, <a href="lwg-defects.html#720">720</a>, <a href="lwg-closed.html#721">721</a>, <a href="lwg-defects.html#722">722</a>, <a href="lwg-defects.html#723">723</a>.</li>
</ul></li>
</ul>
</li>
<li>R50: 
2007-08-05 post-Toronto mailing.
<ul>
<li><b>Summary:</b><ul>
<li>153 open issues, down by 5.</li>
<li>555 closed issues, up by 17.</li>
<li>708 issues total, up by 12.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#697">697</a>, <a href="lwg-defects.html#698">698</a>, <a href="lwg-defects.html#699">699</a>, <a href="lwg-defects.html#700">700</a>, <a href="lwg-closed.html#701">701</a>, <a href="lwg-closed.html#702">702</a>, <a href="lwg-defects.html#703">703</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#705">705</a>, <a href="lwg-defects.html#706">706</a>, <a href="lwg-closed.html#707">707</a>, <a href="lwg-closed.html#708">708</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#583">583</a>, <a href="lwg-closed.html#584">584</a>, <a href="lwg-closed.html#662">662</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#528">528</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-closed.html#637">637</a>, <a href="lwg-closed.html#647">647</a>, <a href="lwg-defects.html#658">658</a>, <a href="lwg-closed.html#690">690</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-defects.html#525">525</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#553">553</a>, <a href="lwg-closed.html#571">571</a>, <a href="lwg-closed.html#591">591</a>, <a href="lwg-closed.html#633">633</a>, <a href="lwg-closed.html#636">636</a>, <a href="lwg-closed.html#641">641</a>, <a href="lwg-closed.html#642">642</a>, <a href="lwg-closed.html#648">648</a>, <a href="lwg-closed.html#649">649</a>, <a href="lwg-closed.html#656">656</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-closed.html#579">579</a>, <a href="lwg-closed.html#631">631</a>, <a href="lwg-defects.html#680">680</a>.</li>
<li>Changed the following issues from Pending WP to Open: <a href="lwg-defects.html#258">258</a>.</li>
<li>Changed the following issues from Ready to Pending WP: <a href="lwg-closed.html#644">644</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#577">577</a>, <a href="lwg-defects.html#660">660</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#488">488</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#518">518</a>.</li>
<li>Changed the following issues from Ready to TRDec: <a href="lwg-defects.html#604">604</a>.</li>
<li>Changed the following issues from DR to WP: <a href="lwg-defects.html#453">453</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#531">531</a>, <a href="lwg-defects.html#551">551</a>, <a href="lwg-defects.html#566">566</a>, <a href="lwg-defects.html#628">628</a>, <a href="lwg-defects.html#640">640</a>, <a href="lwg-defects.html#643">643</a>, <a href="lwg-defects.html#646">646</a>.</li>
</ul></li>
</ul>
</li>
<li>R49: 
2007-06-23 pre-Toronto mailing.
<ul>
<li><b>Summary:</b><ul>
<li>158 open issues, up by 13.</li>
<li>538 closed issues, up by 7.</li>
<li>696 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#677">677</a>, <a href="lwg-defects.html#678">678</a>, <a href="lwg-defects.html#679">679</a>, <a href="lwg-defects.html#680">680</a>, <a href="lwg-defects.html#681">681</a>, <a href="lwg-defects.html#682">682</a>, <a href="lwg-closed.html#684">684</a>, <a href="lwg-defects.html#685">685</a>, <a href="lwg-closed.html#686">686</a>, <a href="lwg-defects.html#687">687</a>, <a href="lwg-defects.html#688">688</a>, <a href="lwg-defects.html#689">689</a>, <a href="lwg-closed.html#690">690</a>, <a href="lwg-defects.html#691">691</a>, <a href="lwg-defects.html#692">692</a>, <a href="lwg-defects.html#693">693</a>, <a href="lwg-defects.html#694">694</a>, <a href="lwg-defects.html#695">695</a>, <a href="lwg-defects.html#696">696</a>.</li>
<li>Added the following Pending NAD Editorial issues: <a href="lwg-closed.html#683">683</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-closed.html#587">587</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#590">590</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="lwg-closed.html#636">636</a>, <a href="lwg-closed.html#642">642</a>, <a href="lwg-closed.html#648">648</a>, <a href="lwg-closed.html#649">649</a>.</li>
</ul></li>
</ul>
</li>
<li>R48: 
2007-05-06 post-Oxford mailing.
<ul>
<li><b>Summary:</b><ul>
<li>145 open issues, down by 33.</li>
<li>531 closed issues, up by 53.</li>
<li>676 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-closed.html#657">657</a>, <a href="lwg-defects.html#658">658</a>, <a href="lwg-defects.html#659">659</a>, <a href="lwg-defects.html#660">660</a>, <a href="lwg-defects.html#661">661</a>, <a href="lwg-closed.html#662">662</a>, <a href="lwg-closed.html#663">663</a>, <a href="lwg-defects.html#664">664</a>, <a href="lwg-defects.html#665">665</a>, <a href="lwg-defects.html#666">666</a>, <a href="lwg-closed.html#667">667</a>, <a href="lwg-closed.html#668">668</a>, <a href="lwg-closed.html#669">669</a>, <a href="lwg-closed.html#670">670</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#672">672</a>, <a href="lwg-defects.html#673">673</a>, <a href="lwg-defects.html#674">674</a>, <a href="lwg-defects.html#675">675</a>, <a href="lwg-defects.html#676">676</a>.</li>
<li>Changed the following issues from Tentatively Ready to Dup: <a href="lwg-closed.html#479">479</a>, <a href="lwg-closed.html#536">536</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD: <a href="lwg-closed.html#385">385</a>, <a href="lwg-closed.html#463">463</a>, <a href="lwg-closed.html#466">466</a>, <a href="lwg-closed.html#470">470</a>, <a href="lwg-closed.html#515">515</a>, <a href="lwg-closed.html#526">526</a>, <a href="lwg-closed.html#547">547</a>, <a href="lwg-closed.html#560">560</a>, <a href="lwg-closed.html#572">572</a>.</li>
<li>Changed the following issues from NAD to NAD Editorial: <a href="lwg-closed.html#351">351</a>, <a href="lwg-closed.html#357">357</a>, <a href="lwg-closed.html#368">368</a>, <a href="lwg-closed.html#499">499</a>, <a href="lwg-closed.html#504">504</a>, <a href="lwg-closed.html#512">512</a>, <a href="lwg-closed.html#513">513</a>, <a href="lwg-closed.html#514">514</a>, <a href="lwg-closed.html#516">516</a>, <a href="lwg-closed.html#544">544</a>, <a href="lwg-closed.html#549">549</a>, <a href="lwg-closed.html#555">555</a>, <a href="lwg-closed.html#558">558</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="lwg-defects.html#482">482</a>, <a href="lwg-closed.html#615">615</a>.</li>
<li>Changed the following issues from NAD_Future to NAD Future: <a href="lwg-closed.html#77">77</a>, <a href="lwg-closed.html#105">105</a>, <a href="lwg-closed.html#111">111</a>, <a href="lwg-closed.html#116">116</a>, <a href="lwg-closed.html#128">128</a>, <a href="lwg-closed.html#138">138</a>, <a href="lwg-closed.html#140">140</a>, <a href="lwg-defects.html#149">149</a>, <a href="lwg-defects.html#180">180</a>, <a href="lwg-closed.html#188">188</a>, <a href="lwg-closed.html#190">190</a>, <a href="lwg-closed.html#219">219</a>, <a href="lwg-closed.html#323">323</a>, <a href="lwg-closed.html#348">348</a>, <a href="lwg-closed.html#350">350</a>, <a href="lwg-defects.html#353">353</a>, <a href="lwg-closed.html#388">388</a>, <a href="lwg-closed.html#390">390</a>.</li>
<li>Changed the following issues from Tentatively Ready to Open: <a href="lwg-defects.html#471">471</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="lwg-closed.html#633">633</a>, <a href="lwg-closed.html#641">641</a>, <a href="lwg-closed.html#656">656</a>.</li>
<li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="lwg-closed.html#532">532</a>, <a href="lwg-closed.html#553">553</a>, <a href="lwg-closed.html#571">571</a>, <a href="lwg-closed.html#591">591</a>, <a href="lwg-defects.html#594">594</a>.</li>
<li>Changed the following issues from Tentatively Ready to Pending WP: <a href="lwg-defects.html#258">258</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#566">566</a>, <a href="lwg-defects.html#628">628</a>, <a href="lwg-defects.html#640">640</a>, <a href="lwg-defects.html#643">643</a>, <a href="lwg-closed.html#644">644</a>, <a href="lwg-defects.html#646">646</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#531">531</a>, <a href="lwg-defects.html#551">551</a>, <a href="lwg-defects.html#604">604</a>.</li>
<li>Changed the following issues from Ready to TRDec: <a href="lwg-defects.html#598">598</a>, <a href="lwg-defects.html#599">599</a>, <a href="lwg-defects.html#600">600</a>, <a href="lwg-defects.html#601">601</a>, <a href="lwg-defects.html#602">602</a>, <a href="lwg-defects.html#603">603</a>, <a href="lwg-defects.html#605">605</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#543">543</a>, <a href="lwg-defects.html#545">545</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="lwg-defects.html#201">201</a>, <a href="lwg-defects.html#206">206</a>, <a href="lwg-defects.html#233">233</a>, <a href="lwg-defects.html#254">254</a>, <a href="lwg-defects.html#416">416</a>, <a href="lwg-defects.html#422">422</a>, <a href="lwg-defects.html#456">456</a>, <a href="lwg-defects.html#534">534</a>, <a href="lwg-defects.html#542">542</a>, <a href="lwg-defects.html#559">559</a>, <a href="lwg-defects.html#575">575</a>, <a href="lwg-defects.html#576">576</a>, <a href="lwg-defects.html#578">578</a>, <a href="lwg-defects.html#586">586</a>, <a href="lwg-defects.html#589">589</a>, <a href="lwg-defects.html#593">593</a>, <a href="lwg-defects.html#609">609</a>, <a href="lwg-defects.html#610">610</a>, <a href="lwg-defects.html#611">611</a>, <a href="lwg-defects.html#613">613</a>, <a href="lwg-defects.html#616">616</a>, <a href="lwg-defects.html#619">619</a>.</li>
</ul></li>
</ul>
</li>
<li>R47: 
2007-03-09 pre-Oxford mailing.
<ul>
<li><b>Summary:</b><ul>
<li>178 open issues, up by 37.</li>
<li>478 closed issues, up by 0.</li>
<li>656 issues total, up by 37.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#620">620</a>, <a href="lwg-defects.html#621">621</a>, <a href="lwg-defects.html#622">622</a>, <a href="lwg-defects.html#623">623</a>, <a href="lwg-defects.html#624">624</a>, <a href="lwg-closed.html#627">627</a>, <a href="lwg-defects.html#628">628</a>, <a href="lwg-defects.html#629">629</a>, <a href="lwg-defects.html#630">630</a>, <a href="lwg-closed.html#631">631</a>, <a href="lwg-closed.html#632">632</a>, <a href="lwg-closed.html#633">633</a>, <a href="lwg-defects.html#634">634</a>, <a href="lwg-defects.html#635">635</a>, <a href="lwg-closed.html#636">636</a>, <a href="lwg-closed.html#637">637</a>, <a href="lwg-defects.html#638">638</a>, <a href="lwg-closed.html#639">639</a>, <a href="lwg-defects.html#640">640</a>, <a href="lwg-closed.html#641">641</a>, <a href="lwg-closed.html#642">642</a>, <a href="lwg-defects.html#643">643</a>, <a href="lwg-closed.html#644">644</a>, <a href="lwg-closed.html#645">645</a>, <a href="lwg-defects.html#646">646</a>, <a href="lwg-closed.html#647">647</a>, <a href="lwg-closed.html#648">648</a>, <a href="lwg-closed.html#649">649</a>, <a href="lwg-defects.html#650">650</a>, <a href="lwg-defects.html#651">651</a>, <a href="lwg-defects.html#652">652</a>, <a href="lwg-closed.html#653">653</a>, <a href="lwg-defects.html#654">654</a>, <a href="lwg-defects.html#655">655</a>, <a href="lwg-closed.html#656">656</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#625">625</a>, <a href="lwg-closed.html#626">626</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-closed.html#570">570</a>, <a href="lwg-closed.html#580">580</a>, <a href="lwg-closed.html#582">582</a>, <a href="lwg-closed.html#590">590</a>, <a href="lwg-defects.html#612">612</a>, <a href="lwg-closed.html#614">614</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-closed.html#547">547</a>, <a href="lwg-closed.html#553">553</a>, <a href="lwg-closed.html#560">560</a>, <a href="lwg-closed.html#571">571</a>, <a href="lwg-closed.html#572">572</a>, <a href="lwg-defects.html#575">575</a>, <a href="lwg-defects.html#576">576</a>, <a href="lwg-defects.html#578">578</a>, <a href="lwg-defects.html#586">586</a>, <a href="lwg-defects.html#589">589</a>, <a href="lwg-closed.html#591">591</a>, <a href="lwg-defects.html#593">593</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-defects.html#609">609</a>, <a href="lwg-defects.html#610">610</a>, <a href="lwg-defects.html#611">611</a>, <a href="lwg-defects.html#613">613</a>, <a href="lwg-closed.html#615">615</a>, <a href="lwg-defects.html#616">616</a>, <a href="lwg-defects.html#619">619</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#201">201</a>, <a href="lwg-defects.html#206">206</a>, <a href="lwg-defects.html#233">233</a>, <a href="lwg-defects.html#254">254</a>, <a href="lwg-defects.html#258">258</a>, <a href="lwg-closed.html#385">385</a>, <a href="lwg-defects.html#416">416</a>, <a href="lwg-defects.html#422">422</a>, <a href="lwg-defects.html#456">456</a>, <a href="lwg-closed.html#463">463</a>, <a href="lwg-closed.html#466">466</a>, <a href="lwg-closed.html#470">470</a>, <a href="lwg-defects.html#471">471</a>, <a href="lwg-closed.html#479">479</a>, <a href="lwg-defects.html#482">482</a>, <a href="lwg-closed.html#515">515</a>, <a href="lwg-closed.html#526">526</a>, <a href="lwg-closed.html#532">532</a>, <a href="lwg-closed.html#536">536</a>, <a href="lwg-defects.html#542">542</a>, <a href="lwg-defects.html#559">559</a>.</li>
<li>Changed the following issues from Review to Tentatively Ready: <a href="lwg-defects.html#534">534</a>.</li>
</ul></li>
</ul>
</li>
<li>R46: 
2007-01-12 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>141 open issues, up by 11.</li>
<li>478 closed issues, down by 1.</li>
<li>619 issues total, up by 10.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-defects.html#610">610</a>, <a href="lwg-defects.html#611">611</a>, <a href="lwg-defects.html#612">612</a>, <a href="lwg-defects.html#613">613</a>, <a href="lwg-closed.html#614">614</a>, <a href="lwg-closed.html#615">615</a>, <a href="lwg-defects.html#616">616</a>, <a href="lwg-closed.html#617">617</a>, <a href="lwg-defects.html#618">618</a>, <a href="lwg-defects.html#619">619</a>.</li>
</ul></li>
</ul>
</li>
<li>R45: 
2006-11-03 post-Portland mailing.
<ul>
<li><b>Summary:</b><ul>
<li>130 open issues, up by 0.</li>
<li>479 closed issues, up by 17.</li>
<li>609 issues total, up by 17.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Moved issues <a href="lwg-defects.html#520">520</a>, <a href="lwg-defects.html#521">521</a>, <a href="lwg-defects.html#530">530</a>, <a href="lwg-defects.html#535">535</a>, <a href="lwg-defects.html#537">537</a>, <a href="lwg-defects.html#538">538</a>, <a href="lwg-defects.html#540">540</a>, <a href="lwg-defects.html#541">541</a> to WP.</li>
<li>Moved issues <a href="lwg-closed.html#504">504</a>, <a href="lwg-closed.html#512">512</a>, <a href="lwg-closed.html#516">516</a>, <a href="lwg-closed.html#544">544</a>, <a href="lwg-closed.html#549">549</a>, <a href="lwg-closed.html#554">554</a>, <a href="lwg-closed.html#555">555</a>, <a href="lwg-closed.html#558">558</a> to NAD.</li>
<li>Moved issue <a href="lwg-closed.html#569">569</a> to Dup.</li>
<li>Moved issues <a href="lwg-defects.html#518">518</a>, <a href="lwg-closed.html#523">523</a>, <a href="lwg-defects.html#524">524</a>, <a href="lwg-defects.html#542">542</a>, <a href="lwg-defects.html#556">556</a>, <a href="lwg-closed.html#557">557</a>, <a href="lwg-defects.html#559">559</a>, <a href="lwg-closed.html#597">597</a>, <a href="lwg-closed.html#606">606</a> to Open.</li>
<li>Moved issues <a href="lwg-defects.html#543">543</a>, <a href="lwg-defects.html#545">545</a>, <a href="lwg-closed.html#549">549</a>, <a href="lwg-closed.html#549">549</a>, <a href="lwg-defects.html#598">598</a> - <a href="lwg-defects.html#603">603</a>, <a href="lwg-defects.html#605">605</a> to Ready.</li>
<li>Moved issues <a href="lwg-defects.html#531">531</a>, <a href="lwg-defects.html#551">551</a>, <a href="lwg-defects.html#604">604</a> to Review.</li>
<li>Added new issues <a href="lwg-defects.html#593">593</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-defects.html#595">595</a>, <a href="lwg-defects.html#596">596</a>, <a href="lwg-closed.html#597">597</a>, <a href="lwg-defects.html#598">598</a>, <a href="lwg-defects.html#599">599</a>, <a href="lwg-defects.html#600">600</a>, <a href="lwg-defects.html#601">601</a>, <a href="lwg-defects.html#602">602</a>, <a href="lwg-defects.html#603">603</a>, <a href="lwg-defects.html#604">604</a>, <a href="lwg-defects.html#605">605</a>, <a href="lwg-closed.html#606">606</a>, <a href="lwg-defects.html#607">607</a>, <a href="lwg-defects.html#608">608</a>, <a href="lwg-defects.html#609">609</a>.</li>
</ul></li>
</ul>
</li>
<li>R44: 
2006-09-08 pre-Portland mailing.
<ul>
<li><b>Summary:</b><ul>
<li>130 open issues, up by 6.</li>
<li>462 closed issues, down by 1.</li>
<li>592 issues total, up by 5.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-closed.html#583">583</a>, <a href="lwg-closed.html#584">584</a>, <a href="lwg-closed.html#585">585</a>, <a href="lwg-defects.html#586">586</a>, <a href="lwg-closed.html#587">587</a>, <a href="lwg-closed.html#588">588</a>, <a href="lwg-defects.html#589">589</a>, <a href="lwg-closed.html#590">590</a>, <a href="lwg-closed.html#591">591</a>, <a href="lwg-closed.html#592">592</a>.</li>
</ul></li>
</ul>
</li>
<li>R43: 
2006-06-23 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>124 open issues, up by 14.</li>
<li>463 closed issues, down by 1.</li>
<li>587 issues total, up by 13.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-defects.html#575">575</a>, <a href="lwg-defects.html#576">576</a>, <a href="lwg-defects.html#577">577</a>, <a href="lwg-defects.html#578">578</a>, <a href="lwg-closed.html#579">579</a>, <a href="lwg-closed.html#580">580</a>, <a href="lwg-defects.html#581">581</a>, <a href="lwg-closed.html#582">582</a>.</li>
<li>Reopened <a href="lwg-closed.html#255">255</a>.</li>
<li>Moved issues <a href="lwg-defects.html#520">520</a>, <a href="lwg-defects.html#541">541</a>, <a href="lwg-closed.html#544">544</a>, <a href="lwg-closed.html#569">569</a> to Tentatively Ready.</li>
</ul></li>
</ul>
</li>
<li>R42: 
2006-04-21 post-Berlin mailing.
<ul>
<li><b>Summary:</b><ul>
<li>110 open issues, down by 16.</li>
<li>464 closed issues, up by 24.</li>
<li>574 issues total, up by 8.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-defects.html#567">567</a>, <a href="lwg-closed.html#568">568</a>, <a href="lwg-closed.html#569">569</a>, <a href="lwg-closed.html#570">570</a>, <a href="lwg-closed.html#571">571</a>, <a href="lwg-closed.html#572">572</a>.</li>
<li>Moved issues <a href="lwg-closed.html#499">499</a>, <a href="lwg-closed.html#501">501</a>, <a href="lwg-closed.html#506">506</a>, <a href="lwg-closed.html#509">509</a>, <a href="lwg-closed.html#510">510</a>, <a href="lwg-closed.html#511">511</a>, <a href="lwg-closed.html#513">513</a>, <a href="lwg-closed.html#514">514</a>, <a href="lwg-closed.html#517">517</a> to NAD.</li>
<li>Moved issues <a href="lwg-closed.html#502">502</a>, <a href="lwg-closed.html#503">503</a>, <a href="lwg-closed.html#515">515</a>, <a href="lwg-closed.html#516">516</a>, <a href="lwg-defects.html#522">522</a>, <a href="lwg-defects.html#525">525</a>, <a href="lwg-closed.html#526">526</a>, <a href="lwg-defects.html#527">527</a>, <a href="lwg-closed.html#528">528</a>, <a href="lwg-closed.html#529">529</a>, <a href="lwg-closed.html#532">532</a>, <a href="lwg-closed.html#536">536</a>, <a href="lwg-defects.html#539">539</a>, <a href="lwg-closed.html#548">548</a> to Open.</li>
<li>Moved issue <a href="lwg-closed.html#504">504</a>, <a href="lwg-closed.html#512">512</a>, <a href="lwg-defects.html#521">521</a>, <a href="lwg-defects.html#530">530</a>, <a href="lwg-defects.html#531">531</a>, <a href="lwg-defects.html#535">535</a>, <a href="lwg-defects.html#537">537</a>, <a href="lwg-defects.html#538">538</a>, <a href="lwg-defects.html#540">540</a>, <a href="lwg-closed.html#549">549</a> to Ready.</li>
<li>Moved issues <a href="lwg-defects.html#247">247</a>, <a href="lwg-defects.html#294">294</a>, <a href="lwg-defects.html#362">362</a>, <a href="lwg-defects.html#369">369</a>, <a href="lwg-defects.html#371">371</a>, <a href="lwg-defects.html#376">376</a>, <a href="lwg-defects.html#384">384</a>, <a href="lwg-defects.html#475">475</a>, <a href="lwg-defects.html#478">478</a>, <a href="lwg-defects.html#495">495</a>, <a href="lwg-defects.html#497">497</a>, <a href="lwg-defects.html#505">505</a>, <a href="lwg-defects.html#507">507</a>, <a href="lwg-defects.html#508">508</a>, <a href="lwg-defects.html#519">519</a> to WP.</li>
<li>Moved issue <a href="lwg-defects.html#534">534</a> to Review.</li>
</ul></li>
</ul>
</li>
<li>R41: 
2006-02-24 pre-Berlin mailing.
<ul>
<li><b>Summary:</b><ul>
<li>126 open issues, up by 31.</li>
<li>440 closed issues, up by 0.</li>
<li>566 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-closed.html#536">536</a>, <a href="lwg-defects.html#537">537</a>, <a href="lwg-defects.html#538">538</a>, <a href="lwg-defects.html#539">539</a>, <a href="lwg-defects.html#540">540</a>, <a href="lwg-defects.html#541">541</a>, <a href="lwg-defects.html#542">542</a>, <a href="lwg-defects.html#543">543</a>, <a href="lwg-closed.html#544">544</a>, <a href="lwg-defects.html#545">545</a>, <a href="lwg-closed.html#546">546</a>, <a href="lwg-closed.html#547">547</a>, <a href="lwg-closed.html#548">548</a>, <a href="lwg-closed.html#549">549</a>, <a href="lwg-defects.html#550">550</a> ,<a href="lwg-defects.html#551">551</a>, <a href="lwg-defects.html#552">552</a>, <a href="lwg-closed.html#553">553</a>, <a href="lwg-closed.html#554">554</a>, <a href="lwg-closed.html#555">555</a>, <a href="lwg-defects.html#556">556</a>, <a href="lwg-closed.html#557">557</a>, <a href="lwg-closed.html#558">558</a>, <a href="lwg-defects.html#559">559</a>, <a href="lwg-closed.html#560">560</a>, <a href="lwg-defects.html#561">561</a>, <a href="lwg-defects.html#562">562</a>, <a href="lwg-defects.html#563">563</a>, <a href="lwg-defects.html#564">564</a>, <a href="lwg-defects.html#565">565</a>, <a href="lwg-defects.html#566">566</a>.</li>
<li>Moved <a href="lwg-closed.html#342">342</a> from Ready to Open.</li>
<li>Reopened <a href="lwg-closed.html#309">309</a>.</li>
</ul></li>
</ul>
</li>
<li>R40: 
2005-12-16 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>95 open issues.</li>
<li>440 closed issues.</li>
<li>535 issues total.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-closed.html#529">529</a>, <a href="lwg-defects.html#530">530</a>, <a href="lwg-defects.html#531">531</a>, <a href="lwg-closed.html#532">532</a>, <a href="lwg-defects.html#533">533</a>, <a href="lwg-defects.html#534">534</a>, <a href="lwg-defects.html#535">535</a>.</li>
</ul></li>
</ul>
</li>
<li>R39: 
2005-10-14 post-Mont Tremblant mailing.
Added new issues <a href="lwg-closed.html#526">526</a>-<a href="lwg-closed.html#528">528</a>.
Moved issues <a href="lwg-defects.html#280">280</a>, <a href="lwg-defects.html#461">461</a>, <a href="lwg-defects.html#464">464</a>, <a href="lwg-defects.html#465">465</a>, <a href="lwg-defects.html#467">467</a>, <a href="lwg-defects.html#468">468</a>, <a href="lwg-defects.html#474">474</a>, <a href="lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
Moved issues <a href="lwg-defects.html#247">247</a>, <a href="lwg-defects.html#294">294</a>, <a href="lwg-closed.html#342">342</a>, <a href="lwg-defects.html#362">362</a>, <a href="lwg-defects.html#369">369</a>, <a href="lwg-defects.html#371">371</a>, <a href="lwg-defects.html#376">376</a>, <a href="lwg-defects.html#384">384</a>, <a href="lwg-defects.html#475">475</a>, <a href="lwg-defects.html#478">478</a>, <a href="lwg-defects.html#495">495</a>, <a href="lwg-defects.html#497">497</a> from Review to Ready.
Moved issues <a href="lwg-defects.html#498">498</a>, <a href="lwg-closed.html#504">504</a>, <a href="lwg-closed.html#506">506</a>, <a href="lwg-closed.html#509">509</a>, <a href="lwg-closed.html#510">510</a>, <a href="lwg-closed.html#511">511</a>, <a href="lwg-closed.html#512">512</a>, <a href="lwg-closed.html#513">513</a>, <a href="lwg-closed.html#514">514</a> from New to Open.
Moved issues <a href="lwg-defects.html#505">505</a>, <a href="lwg-defects.html#507">507</a>, <a href="lwg-defects.html#508">508</a>, <a href="lwg-defects.html#519">519</a> from New to Ready.
Moved issue <a href="lwg-closed.html#500">500</a> from New to NAD.
Moved issue <a href="lwg-defects.html#518">518</a> from New to Review.
</li>
<li>R38: 
2005-07-03 pre-Mont Tremblant mailing.
Merged open TR1 issues in <a href="lwg-closed.html#504">504</a>-<a href="lwg-defects.html#522">522</a>.
Added new issues <a href="lwg-closed.html#523">523</a>-<a href="lwg-closed.html#523">523</a>
</li>
<li>R37: 
2005-06 mid-term mailing.
Added new issues <a href="lwg-defects.html#498">498</a>-<a href="lwg-closed.html#503">503</a>.
</li>
<li>R36: 
2005-04 post-Lillehammer mailing. All issues in "ready" status except
for <a href="lwg-closed.html#454">454</a> were moved to "DR" status, and all issues
previously in "DR" status were moved to "WP".
</li>
<li>R35: 
2005-03 pre-Lillehammer mailing.
</li>
<li>R34: 
2005-01 mid-term mailing.  Added new issues <a href="lwg-defects.html#488">488</a>-<a href="lwg-closed.html#494">494</a>.
</li>
<li>R33: 
2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
</li>
<li>R32: 
2004-09 pre-Redmond mailing: reflects new proposed resolutions and
new issues received after the 2004-07 mailing.  Added
new issues <a href="lwg-closed.html#479">479</a>-<a href="lwg-closed.html#481">481</a>.
</li>
<li>R31: 
2004-07 mid-term mailing: reflects new proposed resolutions and
new issues received after the post-Sydney mailing.  Added
new issues <a href="lwg-closed.html#463">463</a>-<a href="lwg-defects.html#478">478</a>.
</li>
<li>R30: 
Post-Sydney mailing: reflects decisions made at the Sydney meeting.
Voted all "Ready" issues from R29 into the working paper.
Added new issues <a href="lwg-defects.html#460">460</a>-<a href="lwg-closed.html#462">462</a>.
</li>
<li>R29: 
Pre-Sydney mailing.  Added new issues <a href="lwg-defects.html#441">441</a>-<a href="lwg-defects.html#457">457</a>.
</li>
<li>R28: 
Post-Kona mailing: reflects decisions made at the Kona meeting.
Added new issues <a href="lwg-defects.html#432">432</a>-<a href="lwg-closed.html#440">440</a>.
</li>
<li>R27: 
Pre-Kona mailing.  Added new issues <a href="lwg-defects.html#404">404</a>-<a href="lwg-defects.html#431">431</a>.
</li>
<li>R26: 
Post-Oxford mailing: reflects decisions made at the Oxford meeting.
All issues in Ready status were voted into DR status.  All issues in
DR status were voted into WP status.
</li>
<li>R25: 
Pre-Oxford mailing.  Added new issues <a href="lwg-closed.html#390">390</a>-<a href="lwg-defects.html#402">402</a>.
</li>
<li>R24: 
Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
meeting.  All Ready issues from R23 with the exception of <a href="lwg-defects.html#253">253</a>, 
which has been given a new proposed resolution, were
moved to DR status.  Added new issues <a href="lwg-defects.html#383">383</a>-<a href="lwg-defects.html#389">389</a>.  
(Issues <a href="lwg-defects.html#387">387</a>-<a href="lwg-defects.html#389">389</a> were discussed
at the meeting.)  Made progress on issues <a href="lwg-defects.html#225">225</a>, <a href="lwg-defects.html#226">226</a>, 
<a href="lwg-defects.html#229">229</a>: <a href="lwg-defects.html#225">225</a> and <a href="lwg-defects.html#229">229</a> have been moved to 
Ready status, and the only remaining concerns with <a href="lwg-defects.html#226">226</a> involve wording.
</li>
<li>R23: 
Pre-Santa Cruz mailing.  Added new issues <a href="lwg-closed.html#367">367</a>-<a href="lwg-closed.html#382">382</a>.
Moved issues in the TC to TC status.
</li>
<li>R22: 
Post-Cura&ccedil;ao mailing.  Added new issues <a href="lwg-defects.html#362">362</a>-<a href="lwg-closed.html#366">366</a>.
</li>
<li>R21: 
Pre-Cura&ccedil;ao mailing.  Added new issues <a href="lwg-closed.html#351">351</a>-<a href="lwg-closed.html#361">361</a>.
</li>
<li>R20: 
Post-Redmond mailing; reflects actions taken in Redmond.  Added
new issues <a href="lwg-defects.html#336">336</a>-<a href="lwg-closed.html#350">350</a>, of which issues 
<a href="lwg-defects.html#347">347</a>-<a href="lwg-closed.html#350">350</a> were added since Redmond, hence
not discussed at the meeting.  

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

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

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

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

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

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

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

  <p><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#TC1">TC1</a>),
  or are closed without action other than a Record of Response
  (<a href="lwg-active.html#Resolved">Resolved</a> ). The intent of this LWG process is that
  only issues which are truly defects in the Standard move to the
  formal ISO DR status.
  </p>


<h2>Active Issues</h2>
<hr>
<h3><a name="1169"></a>1169. <tt>num_get</tt> not fully compatible with <tt>strto*</tt></h3>
<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Cosmin Truta <b>Opened:</b> 2009-07-04 <b>Last modified:</b> 2011-09-06</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#Review">Review</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><i>[
2011 Bloomington
]</i></p>


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



<p><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#Review">Review</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-07-17 <b>Last modified:</b> 2011-09-06</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#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>
<p>
When I look at the <tt>unordered_*</tt> constructors, I think the complexity is poorly
described and does not follow the style of the rest of the standard.
</p>

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

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

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



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


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

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


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

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


<p>Move to deferred</p>

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


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



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

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

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

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

<tr>
<td><tt>X(i, j, n, hf, eq)</tt><br/>
<tt>X a(i, j, n, hf, eq)</tt>
</td>
<td><tt>X</tt></td>
<td>&hellip;<br/>
<i>Effects</i>: Constructs an empty container with at least <tt>n</tt><br/>
buckets, using <tt>hf</tt> as the hash function and <tt>eq</tt> as the key<br/>
equality predicate, and inserts elements from <tt>[i, j)</tt> into it.
</td>
<td>Average case <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#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2009-09-20 <b>Last modified:</b> 2011-09-06</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#Ready">Ready</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><i>[
2011 Bloomington
]</i></p>


<p>
Further discussion persuades us this issue is Ready (and so moved).
We may need a further issue clarifying the notion of key <i>value</i>
vs. key <i>object</i>, as object identity appears to be important
to this wording.
</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="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#Open">Open</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2011-09-06</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-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><i>[
<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>
]</i></p>


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


<p>
It appears the key problem is the phrasing of the bitmask requirements.  Jeremiah supplies updated wording.
</p>

<p>
Pete Becker has also provided an alternative resolution.
</p>

<p>
Ammend 17.5.2.1.3 [bitmask.types]:
</p>
<p>
Change the list of values for "enum bit mask" in p2 from
</p>
<p>
<tt><i>V0</i> = 1 &lt;&lt; 0, <i>V1</i> = 1 &lt;&lt; 1, <i>V2</i> = 1 &lt;&lt; 2, <i>V3</i> = 1 &lt;&lt; 3, ...</tt>.
</p>
<p>
to
</p>
<p>
<tt><i>V0</i> = 0, <i>V1</i> = 1 &lt;&lt; 0, <i>V2</i> = 1 &lt;&lt; 1, <i>V3</i> = 1 &lt;&lt; 2,  ...</tt>.
</p>
<p>
Here, the names <i>C0</i>, <i>C1</i>, etc. represent <i>bitmask elements</i> for this particular
bitmask type. All such <ins>non-zero</ins> elements have distinct values such that, for any pair
<i>Ci</i> and <i>Cj</i> <ins>where <i>i</i> != <i>j</i></ins>, <del><i>Ci &amp; Ci</i> is nonzero
and</del> <i>Ci &amp; Cj</i> is zero.
</p>
<p>
Change bullet 3 of paragraph 4:
</p>
<p>
<del>The</del><ins>A non-zero</ins> value Y is set in the object X if the expression X &amp; Y is nonzero.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Ammend 17.5.2.1.3 [bitmask.types] p3:
</p>
<p>
Here, the names <i>C0</i>, <i>C1</i>, etc. represent <i>bitmask elements</i> for this particular
bitmask type. All such elements have distinct<ins>, non-zero</ins> values such that, for any pair
<i>Ci</i> and <i>Cj</i> <ins>where <i>i</i> != <i>j</i>,</ins> <i>Ci &amp; Ci</i> is nonzero
and <i>Ci &amp; Cj</i> is zero. <ins>Additionally, the value 0 is used to represent an
<i>empty bitmask</i>, in which no bitmask elements are set.</ins>
</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).
<ins>The constants of that type, except for <tt>match_default</tt> and <tt>format_default</tt>, are bitmask
elements. The <tt>match_default</tt> and <tt>format_default</tt> constants are empty bitmasks.</ins> 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.
</p></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-09-06</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><i>[
2011 Bloomington
]</i></p>

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



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

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





<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="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], X [unord.map.modifiers], X [unord.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-09-06</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/>
Daniel's Proposed resolution (not current):
</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><i>[
2011 Bloomington
]</i></p>


<p>
The effects of these inserts can be concisely stated in terms of emplace().
Also, the correct term is "EmplaceConstructible", not "constructible".
</p>
<p>
New wording by Pablo, eliminating duplicate requirements already implied by the effects clause.  Move to Review.
</p>



<p><b>Proposed resolution:</b></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>
<del>1 <em>Requires</em>: <tt>P</tt> shall be convertible to <tt>value_type</tt>.</del>
<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>: The first form is equivalent to
<tt>return emplace(std::forward&lt;P&gt;(x))</tt>.
The second form is equivalent to
<tt>return emplace_hint(position, std::forward&lt;P&gt;(x))</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>
<del>1 <em>Requires</em>: <tt>P</tt> shall be convertible to <tt>value_type</tt>.</del>
<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>: The first form is equivalent to
<tt>return emplace(std::forward&lt;P&gt;(x))</tt>.
The second form is equivalent to
<tt>return emplace_hint(position, std::forward&lt;P&gt;(x))</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.5.4.4 [unord.map.modifers] around p. 1 as indicated:
<blockquote><pre>
template &lt;class P&gt;
pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);
</pre>
<blockquote>
<del>1 <em>Requires</em>: <tt>value_type</tt> is constructible from <tt>std::forward&lt;P&gt;(obj)</tt>.</del>
<p/>
2 <em>Effects</em>:
<ins>equivalent to <tt>return emplace(std::forward&lt;P&gt;(obj))</tt>.</ins>
<del>Inserts obj 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(obj)</tt>.</del>
<p/>
<del>3 <em>Returns</em>: The bool component of the returned pair object indicates whether the insertion took place
and the iterator component points to the element with key equivalent to the key of <tt>value_type(obj)</tt>.</del>
<p/>
<del>4 <em>Complexity</em>: Average case O(1), worst case O(size()).</del>
<p/>
<del>5</del><ins>3</ins> <em>Remarks</em>: This signature shall not participate in overload resolution unless <tt>P</tt> is implicitly convertible
to <tt>value_type</tt>.
<p/>
</blockquote>
<pre>template &lt;class P&gt;
iterator insert(const_iterator hint, P&amp;&amp; obj);
</pre>
<blockquote>
<del>6 <em>Requires</em>: <tt>value_type</tt> is constructible from <tt>std::forward&lt;P&gt;(obj)</tt>.</del>
<p/>
<del>7</del><em>?</em> <em>Effects</em>:
<ins>equivalent to <tt>return emplace_hint(hint, std::forward&lt;P&gt;(obj))</tt>.</ins>
<del>Inserts obj 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(obj)</tt>. The iterator hint is a hint pointing to where the
search should start.</del>
<p/>
<del>8 <em>Returns</em>: An iterator that points to the element with key equivalent to the key of <tt>value_type(obj)</tt>.</del>
<p/>
<del>9 <em>Complexity</em>: Average case O(1), worst case O(size()).</del>
<p/>
<del>10</del><em>?</em> <em>Remarks</em>: This signature shall not participate in overload resolution unless <tt>P</tt> is implicitly convertible
to <tt>value_type</tt>.
</blockquote></blockquote>
</li>
<li>Change 23.5.5.3 [unord.multimap.modifers] around p. 1 as indicated:
<blockquote><pre>
template &lt;class P&gt;
iterator insert(P&amp;&amp; obj);
</pre>
<blockquote>
<del>1 <em>Requires</em>: <tt>value_type</tt> is constructible from <tt>std::forward&lt;P&gt;(obj)</tt>.</del>
<p/>
2 <em>Effects</em>:
<ins>equivalent to <tt>return emplace(std::forward&lt;P&gt;(obj))</tt>.</ins>
<del>Inserts obj converted to <tt>value_type</tt>.</del>
<p/>
<del>3 <em>Returns</em>: An iterator that points to the element with key equivalent to the key of <tt>value_type(obj)</tt>.</del>
<p/>
<del>4 <em>Complexity</em>: Average case O(1), worst case O(size()).</del>
<p/>
<del>5</del><ins>3</ins> <em>Remarks</em>: This signature shall not participate in overload resolution unless P is implicitly convertible
to <tt>value_type</tt>.
</blockquote>
<pre>
template &lt;class P&gt;
iterator insert(const_iterator hint, P&amp;&amp; obj);
</pre>
<blockquote>
<del>6 <em>Requires</em>: <tt>value_type</tt> is constructible from <tt>std::forward&lt;P&gt;(obj)</tt>.</del>
<p/>
<del>7</del><em>?</em> <em>Effects</em>:
<ins>equivalent to <tt>return emplace_hint(hint, std::forward&lt;P&gt;(obj))</tt>.</ins>
<del>Inserts obj converted to <tt>value_type</tt>. The iterator hint is a hint pointing to where the search
should start.</del>
<p/>
<del>8 <em>Returns</em>: An iterator that points to the element with key equivalent to the key of <tt>value_type</tt>(obj).</del>
<p/>
<del>9 <em>Complexity</em>: Average case O(1), worst case O(size()).</del>
<p/>
<del>10</del><ins><em>?</em></ins> <em>Remarks</em>: This signature shall not participate in overload resolution unless P is implicitly convertible
to value_type.
</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-09-06</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#Ready">Ready</a>
 <b>Submitter:</b> Sean Hunt <b>Opened:</b> 2010-07-19 <b>Last modified:</b> 2011-09-06</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#Ready">Ready</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><i>[2011-05-13 Jonathan Wakely comments and provides proposed wording]</i></p>


<p>
The requirements are that <tt>is_bind_expression&lt;T&gt;::value</tt> is true when <tt>T</tt>
is a type returned from <tt>bind</tt>, false for any other type, except when
there's a specialization involving a user-defined type (N.B. 17.6.4.2.1 [namespace.std] 
means we don't need to say e.g. <tt>is_bind_expression&lt;string&gt;</tt> is false.)
<p/>
The obvious way to meet the requirements is for the primary template
to derive from <tt>integral_constant&lt;bool, false&gt;</tt> and for implementations
to provide specializations for the unspecified types returned from
<tt>bind</tt>.  User-defined specializations can do whatever they like, as long
as <tt>is_bind_expression::value</tt> is sane. There's no reason to forbid
users from defining <tt>is_bind_expression&lt;<i>user_defined_type</i>&gt;::value=false</tt>
if that's what they want to do.
<p/>
Similar reasoning applies to <tt>is_placeholder</tt>, but a further issue is
that 20.8.9.1.1 [func.bind.isbind] contains wording for <tt>is_placeholder</tt> but
contains no definition of it and the sub-clause name only refers to
<tt>is_bind_expression</tt>. The wording below proposes splitting paragraphs 3
and 4 of 20.8.9.1.1 [func.bind.isbind] into a new sub-clause covering
<tt>is_placeholder</tt>.
<p/>
If the template specializations added by the proposed wording are too
vague then they could be preceded by "for exposition only" comments
</p>

<p><i>[2011-05-18 Daniel comments and provides some refinements to the P&#47;R]</i></p>


<p>
Both <tt>bind</tt>-related type traits should take advantage of the
UnaryTypeTrait requirements. Additionally, the updated wording does not
imply that the implementation provides several specializations. Wording was 
used similar to the specification of the <tt>uses_allocator</tt> type trait 
(which unfortunately is not expressed in terms of BinaryTypeTrait requirements).
</p>

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

<p>
Move to Ready
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>Change 20.8.9.1.1 [func.bind.isbind] to:</p>

<blockquote><pre>
namespace std {
  template&lt;class T&gt; struct is_bind_expression<ins>; <i>// see below</i></ins>
    <del>: integral_constant&lt;bool, <i>see below</i>&gt; { };</del>
}
</pre><blockquote><p>
-1- <tt>is_bind_expression</tt> can be used to detect function objects generated by <tt>bind</tt>. <tt>bind</tt> 
uses <tt>is_bind_expression</tt> to detect subexpressions. <del>Users may specialize this template to indicate 
that a type should be treated as a subexpression in a <tt>bind</tt> call.</del>
<p/>
-2- <del>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></del><ins>Instantiations of the <tt>is_bind_expression</tt> template
shall meet the UnaryTypeTrait requirements ([meta.rqmts]). The implementation shall provide a definition
that has a BaseCharacteristic of <tt>true_type</tt> if <tt>T</tt> is a type returned from <tt>bind</tt>, otherwise 
it shall have a BaseCharacteristic of <tt>false_type</tt>. A program may specialize this template for a user-defined 
type <tt>T</tt> to have a BaseCharacteristic of <tt>true_type</tt> to indicate that <tt>T</tt> should be treated 
as a subexpression in a <tt>bind</tt> call.</ins>.
<p/>
<del>-3- <tt>is_placeholder</tt> can be used to detect the standard placeholders <tt>_1</tt>, <tt>_2</tt>, and so on. 
<tt>bind</tt> uses <tt>is_placeholder</tt> to detect placeholders. Users may specialize this template to indicate 
a placeholder type.</del>
<p/>
<del>-4- If <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, <tt>is_placeholder&lt;T&gt;</tt> shall be 
publicly derived from <tt>integral_constant&lt;int, J&gt;</tt>, otherwise from <tt>integral_constant&lt;int, 0&gt;</tt>.</del>
</p></blockquote></blockquote>
</li>
<li><p>Insert a new sub-clause immediately following sub-clause 20.8.9.1.1 [func.bind.isbind], the suggested
sub-clause tag is [func.bind.isplace]:
</p>
<h3><ins>20.8.9.1.?  Class template <tt>is_placeholder</tt>  [func.bind.isplace]</ins></h3> 
<blockquote><pre>
<ins>namespace std {
  template&lt;class T&gt; struct is_placeholder; <i>// see below</i>
}</ins>
</pre><blockquote><p>
<ins>-?- <tt>is_placeholder</tt> can be used to detect the standard placeholders <tt>_1</tt>, <tt>_2</tt>, and so on. 
<tt>bind</tt> uses <tt>is_placeholder</tt> to detect placeholders.</ins>
<p/>
<ins>-?- Instantiations of the <tt>is_placeholder</tt> template shall meet the UnaryTypeTrait requirements ([meta.rqmts]). 
The implementation shall provide a definition that has a BaseCharacteristic of <tt>integral_constant&lt;int, J&gt;</tt> 
if <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, otherwise it shall have a BaseCharacteristic of 
<tt>integral_constant&lt;int, 0&gt;</tt>. A program may specialize this template for a user-defined type <tt>T</tt> 
to have a BaseCharacteristic of <tt>integral_constant&lt;int, <i>N</i>&gt;</tt> with <tt><i>N</i> &gt; 0</tt> 
to indicate that <tt>T</tt> should be treated as a placeholder type.</ins>
</p></blockquote></blockquote>
</li>
</ol>





<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#Review">Review</a>
 <b>Submitter:</b> James Kanze <b>Opened:</b> 2010-07-23 <b>Last modified:</b> 2011-09-06</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#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>
<p>
What should the following code output? 
</p>

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

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]&#47;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]&#47;5: 
</p>

<blockquote>
<p>
[&hellip;] 
</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><i>[2011-06-24 Daniel comments and provides wording]</i></p>


<p>
The same problem applies to the output provided by <tt>const char*</tt> and similar
character sequences as of 27.7.3.6.4 [ostream.inserters.character] p. 5. and even for
single character output (!) as described in 27.7.3.6.4 [ostream.inserters.character] p. 1,
just consider the character value '-' where '-' is the sign character. In this case
Table 91 &mdash; "Fill padding" requires to pad after the sign, i.e. the output
for the program
</p>
<blockquote><pre>
#include &lt;iostream&gt;
#include &lt;iomanip&gt;

int main() 
{ 
   char c = '-'; 
   std::cout.fill('*'); 
   std::cout.setf(std::ios::internal, std::ios::adjustfield); 
   std::cout &lt;&lt; std::setw(2) &lt;&lt; c &lt;&lt; std::endl; 
} 
</pre></blockquote>

<p>
According to the current wording this program should output "<tt>-*</tt>", but
all tested implementations output "<tt>*-</tt>" instead.

<p/>
I suggest to replace the reference to 22.4.2.2.2 [facet.num.put.virtuals] in all three places. 
It is not very complicated to describe the padding rules for simple character sequences "inline". 
A similar approach is used as for the <tt>money_put</tt> functions.
</p>

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


<p>
Move to Review, the resolution seems correct but it would be nice if some factoring of the common words were proposed.
</p>



<p><b>Proposed resolution:</b></p>
<p>
The new wording refers to the FDIS numbering.
</p>
<ol>
<li><p>Change 21.4.8.9 [string.io]&#47;5 as indicated:</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>
-5- <i>Effects</i>: Behaves as a formatted output function ([ostream.formatted.reqmts]). After constructing a sentry object,
if this object returns <tt>true</tt> when converted to a value of type <tt>bool</tt>, determines padding as <del>described
in [facet.num.put.virtuals],</del><ins>follows: A <tt>charT</tt> character sequence is produced, initially consisting of 
the elements defined by the range <tt>[str.begin(), str.end())</tt>. If <tt>str.size()</tt> is less than <tt>os.width()</tt>, 
then enough copies of <tt>os.fill()</tt> are added to this sequence as necessary to pad to a width of <tt>os.width()</tt> 
characters. If <tt>(os.flags() &amp; ios_base::adjustfield) == ios_base::left</tt> is <tt>true</tt>, the fill characters 
are placed after the character sequence; otherwise, they are placed before the character sequence. T</ins><del>t</del>hen 
inserts the resulting sequence of characters <tt>seq</tt> 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>
</li>

<li><p>Change 27.7.3.6.4 [ostream.inserters.character]&#47;1 as indicated (An additional editorial
fix is suggested for the first prototype declaration):</p>
<blockquote><pre>
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp; out,
                                          charT c<del>}</del><ins>)</ins>;
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp; out,
                                          char c);
<i>// specialization</i>
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                         char c);
<i>// signed and unsigned</i>
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                         signed char c);
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                         unsigned char c);
</pre><blockquote><p>
-1- <i>Effects</i>: Behaves like a formatted inserter (as described in [ostream.formatted.reqmts]) of <tt>out</tt>. 
After a sentry object is constructed it inserts characters. In case <tt>c</tt> has type <tt>char</tt> and the 
character type of the stream is not <tt>char</tt>, then the character to be inserted is <tt>out.widen(c)</tt>; 
otherwise the character is <tt>c</tt>. Padding is determined as <del>described in [facet.num.put.virtuals]</del><ins>follows: 
A character sequence is produced, initially consisting of the insertion character. If <tt>out.width()</tt> is greater
than one, then enough copies of <tt>out.fill()</tt> are added to this sequence as necessary to pad to a width of 
<tt>out.width()</tt> characters. If <tt>(out.flags() &amp; ios_base::adjustfield) == ios_base::left</tt> is <tt>true</tt>, 
the fill characters are placed after the insertion character; otherwise, they are placed before the insertion 
character</ins>. <del><tt>width(0)</tt> is called.</del> The insertion character and any required padding are 
inserted into <tt>out</tt><ins>; then calls <tt>os.width(0)</tt></ins>.
</p></blockquote></blockquote>
</li>

<li><p>Change 27.7.3.6.4 [ostream.inserters.character]&#47;5 as indicated:</p>
<blockquote><pre>
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp; out,
                                          const charT* s);
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp; out,
                                          const char* s);
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                         const char* s);
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                         const signed char* s);
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                         const unsigned char* s);
</pre><blockquote><p>
[&hellip;]
<p/>
-5- Padding is determined as <del>described in [facet.num.put.virtuals]. The <tt>n</tt> characters starting at <tt>s</tt> 
are widened using <tt>out.widen</tt> ([basic.ios.members])</del><ins>follows: A character sequence is produced, initially 
consisting of the elements defined by the <tt>n</tt> characters starting at <tt>s</tt> widened using 
<tt>out.widen</tt> ([basic.ios.members]). If <tt>n</tt> is less than <tt>out.width()</tt>, then enough copies of 
<tt>out.fill()</tt> are added to this sequence as necessary to pad to a width of <tt>out.width()</tt> characters. 
If <tt>(out.flags() &amp; ios_base::adjustfield) == ios_base::left</tt> is <tt>true</tt>, the fill characters are 
placed after the character sequence; otherwise, they are placed before the character sequence</ins>. The 
widened characters and any required padding are inserted into <tt>out</tt>. Calls <tt>width(0)</tt>.
</p></blockquote></blockquote>
</li>
</ol>






<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-09-06</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><i>[
2011 Bloomington
]</i></p>


<p>
Consensus that this issue will be resolved by <a href="lwg-active.html#2005">2005</a>, but held open until that issue is resolved.
</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#Ready">Ready</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2010-11-12 <b>Last modified:</b> 2011-09-06</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</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><i>[
2011 Bloomington
]</i></p>


<p>
General surprise this was not already in 'Ready' status, and so moved.
</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="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#Ready">Ready</a>
 <b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2010-11-08 <b>Last modified:</b> 2011-09-06</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#Ready">Ready</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><i>[Bloomington, 2011]</i></p>

<p>
Move to Ready
</p>



<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 other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
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="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-09-06</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><i>[2011-05-06: Jonathan Wakely comments and provides suggested wording]</i></p>


<p>
DR <a href="lwg-defects.html#2019">2019</a> added <tt>isblank</tt> support to <tt>&lt;locale&gt;</tt> which simplifies the
definition of <tt>regex_traits::isctype</tt> by removing the special case for the "blank" class.
<p/>
My suggestion for 2018 is to add a new table replacing the lists of
recognized names in the Remarks clause of <tt>regex_traits::lookup_classname</tt>. 
I then refer to that table in the Returns clause of <tt>regex_traits::isctype</tt> 
to expand on the "in an unspecified manner" wording which is too vague. The conversion 
can now be described using the "is set" term defined by 17.5.2.1.3 [bitmask.types] and
the new table to convey the intented relationship between e.g.
[[:digit:]] and <tt>ctype_base::digit</tt>, which is not actually stated in the
FDIS.
<p/>
The effects of <tt>isctype</tt> can then most easily be described in code,
given an "exposition only" function prototype to do the not-quite-so-unspecified conversion 
from <tt>char_class_type</tt> to <tt>ctype_base::mask</tt>.
<p/>
The core of LWG 2018 is the "bitwise or'ed" wording which gives the
wrong result, always evaluating to true for all values of <tt>f</tt>. That is
replaced by the condition <tt>(f&amp;x) == x</tt> where <tt>x</tt> is the result of calling
<tt>lookup_classname</tt> with "w".  I believe that's necessary, because the
"w" class could be implemented by an internal "underscore" class i.e.
<tt>x = _Alnum|_Underscore</tt> in which case <tt>(f&amp;x) != 0</tt> would give the wrong
result when <tt>f==_Alnum</tt>.
<p/>
The proposed resolution also makes use of <tt>ctype::widen</tt> which addresses
the problem that the current wording only talks about "w" and '_' which assumes 
<tt>charT</tt> is char.  There's still room for improvement here:
the regex grammar in 28.13 [re.grammar] says that the class names in the
table should always be recognized, implying that e.g. U"digit" should
be recognized by <tt>regex_traits&lt;char32_t&gt;</tt>, but the specification of
<tt>regex_traits::lookup_classname</tt> doesn't cover that, only mentioning
<tt>char</tt> and <tt>wchar_t</tt>.  Maybe the table should not distinguish narrow and
wide strings, but should just have one column and add wording to say
that <tt>regex_traits</tt> widens the name as if by using <tt>use_facet&lt;ctype&lt;charT&gt;&gt;::widen()</tt>.
<p/>
Another possible improvement would be to allow additional
implementation-defined extensions in <tt>isctype</tt>. An implementation is
allowed to support additional class names in <tt>lookup_classname</tt>, e.g.
[[:octdigit:]] for [0-7] or [[:bindigit:]] for [01], but the current
definition of isctype provides no way to use them unless <tt>ctype_base::mask</tt> 
also supports them.
</p>

<p><i>[2011-05-10: Alberto and Daniel perform minor fixes in the P&#47;R]</i></p>


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


<p>
Consensus that this looks to be a correct solution, and the presentation as a table is a big improvement.
</p>

<p>
Concern that the middle section wording is a little muddled and confusing, Stefanus volunteered to reword.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>Modify 28.7 [re.traits] p. 10 as indicated:</p>
<blockquote><pre>
template &lt;class ForwardIterator&gt;
  char_class_type lookup_classname(
    ForwardIterator first, ForwardIterator last, bool icase = false) const;
</pre><blockquote><p>
-9- <i>Returns</i>: an unspecified value that represents the character classification named by the character
sequence designated by the iterator range [<tt>first</tt>,<tt>last</tt>). If the parameter <tt>icase</tt> is true then the
returned mask identifies the character classification without regard to the case of the characters being
matched, otherwise it does honor the case of the characters being matched.(footnote 335) The value returned shall
be independent of the case of the characters in the character sequence. If the name is not recognized
then returns a value that compares equal to 0.
<p/>
-10- <i>Remarks</i>: For <tt>regex_traits&lt;char&gt;</tt>, at least the <del>names "d", "w", "s", "alnum", "alpha", "blank",
"cntrl", "digit", "graph", "lower", "print", "punct", "space", "upper" and "xdigit"</del><ins>narrow character
names in Table X</ins> shall be recognized. For <tt>regex_traits&lt;wchar_t&gt;</tt>, at least the <del>names L"d", L"w", 
L"s", L"alnum", L"alpha", L"blank", L"cntrl", L"digit", L"graph", L"lower", L"print", L"punct", L"space", L"upper" and 
L"xdigit"</del><ins>wide character names in Table X</ins> shall be recognized.
</p></blockquote></blockquote>
</li>

<li><p>Modify 28.7 [re.traits] p. 12 as indicated:</p>
<blockquote><pre>
bool isctype(charT c, char_class_type f) const;
</pre><blockquote><p>
-11- <i>Effects</i>: Determines if the character <tt>c</tt> is a member of the character classification represented by <tt>f</tt>.
<p/>
-12- <i>Returns</i>: Converts <tt>f</tt> into a value <tt>m</tt> of type <tt>std::ctype_base::mask</tt> in an unspecified manner, <del>and
returns true if <tt>use_facet&lt;ctype&lt;charT&gt; &gt;(getloc()).is(m, c)</tt> is true. Otherwise returns true
if <tt>f</tt> bitwise or'ed with the result of calling <tt>lookup_classname</tt> with an iterator pair that designates
the character sequence "w" is not equal to <tt>0</tt> and <tt>c == '_'</tt>, or if <tt>f</tt> bitwise or'ed with the result of
calling <tt>lookup_classname</tt> with an iterator pair that designates the character sequence "blank" is not
equal to <tt>0</tt> and <tt>c</tt> is one of an implementation-defined subset of the characters for which 
<tt>isspace(c, getloc())</tt> returns true, otherwise returns false.</del><ins>except that when <tt>f</tt> represents 
membership of a character class named in Table X, the corresponding <tt>ctype_base::mask</tt> value shall be set in <tt>m</tt>. 
Given the function prototype</ins>
</p><blockquote><pre>
<ins>template&lt;class C&gt;
   ctype_base::mask convert(typename regex_traits&lt;C&gt;::char_class_type);</ins>
</pre></blockquote>
<p><ins>the result is determined as if by</ins>
</p><blockquote><pre><ins>
ctype_base::mask m = convert&lt;charT&gt;(f);
const ctype&lt;charT&gt;&amp; ct = use_facet&lt;ctype&lt;charT&gt; &gt;(getloc());
if (ct.is(m, c))
  return true;
charT w[1] = { ct.widen('w') };
char_class_type x = lookup_classname(w, w+1);
if ((f&amp;x) == x &amp;&amp; c == ct.widen('_'))
  return true;
return false;
</ins></pre></blockquote>
<p><ins>[<i>Example</i>:</ins>
</p><blockquote><pre><ins>
regex_traits&lt;char&gt; t;
string d("d");
string u("upper");
regex_traits&lt;char&gt;::char_class_type f;
f = t.lookup_classname(d.begin(), d.end());
f |= t.lookup_classname(u.begin(), u.end());
ctype_base::mask m = convert&lt;char&gt;(f); // m == ctype_base::digit|ctype_base::upper
</ins></pre></blockquote>
<p><ins>&mdash; <i>end example</i>]</ins></p>
<p><ins>[<i>Example</i>:</ins>
</p><blockquote><pre><ins>
regex_traits&lt;char&gt; t;
string w("w");
regex_traits&lt;char&gt;::char_class_type f;
f = t.lookup_classname(w.begin(), w.end());
t.isctype('A', f); // returns true
t.isctype('_', f); // returns true
t.isctype(' ', f); // returns false
</ins></pre></blockquote>
<p><ins>&mdash; <i>end example</i>]</ins>
</p></blockquote></blockquote>
</li>

<li><p>At the end of [re.traits] add a new Table X &mdash; Character class names and corresponding ctype masks:</p>

<blockquote>
<table border="1">
<caption>Table X &mdash; Character class names and corresponding ctype masks</caption>

<tr>
<th>Narrow character name</th>
<th>Wide character name</th>
<th>Corresponding <tt>ctype_base::mask</tt> value</th>
</tr>
 
<tr>
<td><tt>"alnum"</tt></td>
<td><tt>L"alnum"</tt></td>
<td><tt>ctype_base::alnum</tt></td>
</tr>

<tr>
<td><tt>"alpha"</tt></td>
<td><tt>L"alpha"</tt></td>
<td><tt>ctype_base::alpha</tt></td>
</tr>

<tr>
<td><tt>"blank"</tt></td>
<td><tt>L"blank"</tt></td>
<td><tt>ctype_base::blank</tt></td>
</tr>

<tr>
<td><tt>"cntrl"</tt></td>
<td><tt>L"cntrl"</tt></td>
<td><tt>ctype_base::cntrl</tt></td>
</tr>

<tr>
<td><tt>"digit"</tt></td>
<td><tt>L"digit"</tt></td>
<td><tt>ctype_base::digit</tt></td>
</tr>

<tr>
<td><tt>"d"</tt></td>
<td><tt>L"d"</tt></td>
<td><tt>ctype_base::digit</tt></td>
</tr>

<tr>
<td><tt>"graph"</tt></td>
<td><tt>L"graph"</tt></td>
<td><tt>ctype_base::graph</tt></td>
</tr>

<tr>
<td><tt>"lower"</tt></td>
<td><tt>L"lower"</tt></td>
<td><tt>ctype_base::lower</tt></td>
</tr>

<tr>
<td><tt>"print"</tt></td>
<td><tt>L"print"</tt></td>
<td><tt>ctype_base::print</tt></td>
</tr>

<tr>
<td><tt>"punct"</tt></td>
<td><tt>L"punct"</tt></td>
<td><tt>ctype_base::punct</tt></td>
</tr>

<tr>
<td><tt>"space"</tt></td>
<td><tt>L"space"</tt></td>
<td><tt>ctype_base::space</tt></td>
</tr>

<tr>
<td><tt>"s"</tt></td>
<td><tt>L"s"</tt></td>
<td><tt>ctype_base::space</tt></td>
</tr>

<tr>
<td><tt>"upper"</tt></td>
<td><tt>L"upper"</tt></td>
<td><tt>ctype_base::upper</tt></td>
</tr>

<tr>
<td><tt>"w"</tt></td>
<td><tt>L"w"</tt></td>
<td><tt>ctype_base::alnum</tt></td>
</tr>

<tr>
<td><tt>"xdigit"</tt></td>
<td><tt>L"xdigit"</tt></td>
<td><tt>ctype_base::xdigit</tt></td>
</tr>

</table>
</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#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2010-12-07 <b>Last modified:</b> 2011-09-06</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#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Issue <a href="lwg-defects.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-defects.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-defects.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><i>[2011-06-13: Daniel comments and refines the proposed wording changes]</i></p>


<p>The feedback obtained following message c++std-lib-30745  and follow-ups point to the intention, that 
the implied provision of lvalues due to named variables in <tt>async</tt> should be provided as rvalues to support
move-only types, but the functor type should be forwarded as lvalue in <tt>bind</tt>.
<p/>
If <tt>bind</tt> were newly invented, the value strategy could be improved, because now we have a preference of
<i>ref</i> <tt>&amp;</tt> qualified function call operator overloads. But such a change seems to be too late now.
User-code that needs to bind a callable object with an <i>ref</i> <tt>&amp;&amp;</tt> qualified function call
operator (or conversion function to function pointer) needs to use a corresponding wrapper similar to <tt>reference_wrapper</tt>
that forwards the reference as rvalue-reference instead.
<p/>
The wording has been adapted to honor these observations and to fit to FDIS numbering as well.
</p>

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

<p>
Move to Ready
</p>



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

<blockquote><pre>
template&lt;class F, class... BoundArgs&gt;
  <i>unspecified</i> bind(F&amp;&amp; f, BoundArgs&amp;&amp;... bound_args);
</pre><blockquote><p>
-2- <i>Requires</i>: <tt>is_constructible&lt;FD, F&gt;::value</tt> shall be true. For each <tt>Ti</tt> in <tt>BoundArgs</tt>, 
<tt>is_constructible&lt;TiD, Ti&gt;::value</tt> shall be true. <tt><i>INVOKE</i>(fd, w1, w2, ..., wN)</tt> (20.8.2) shall 
be a valid expression for some values <tt>w1</tt>, <tt>w2</tt>, ..., <tt>wN</tt>, where <tt>N == sizeof...(bound_args)</tt>.
<p/>
-3- <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, <ins>std::forward&lt;V1&gt;(</ins>v1<ins>)</ins>, 
<ins>std::forward&lt;V2&gt;(</ins>v2<ins>)</ins>, ..., <ins>std::forward&lt;VN&gt;(</ins>vN<ins>)</ins>, 
result_of&lt;FD <i>cv</i> <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</tt>, 
<tt>v2</tt>, ..., <tt>vN</tt> are determined as specified below. [&hellip;]
</p></blockquote></blockquote>

</li>

<li>
<p>Change 20.8.9.1.2 [func.bind.bind] p. 7 as indicated:</p>

<blockquote><pre>
template&lt;class R, class F, class... BoundArgs&gt;
   <i>unspecified</i> bind(F&amp;&amp; f, BoundArgs&amp;&amp;... bound_args);
</pre><blockquote><p>
-6- <i>Requires</i>: <tt>is_constructible&lt;FD, F&gt;::value</tt> shall be true. For each <tt>Ti</tt> in <tt>BoundArgs</tt>, 
<tt>is_constructible&lt;TiD, Ti&gt;::value</tt> shall be true. <tt><i>INVOKE</i>(fd, w1, w2, ..., wN)</tt> shall be a valid 
expression for some values <tt>w1</tt>, <tt>w2</tt>, ..., <tt>wN</tt>, where <tt>N == sizeof...(bound_args)</tt>.
<p/>
-7- <i>Returns</i>: A forwarding call wrapper <tt>g</tt> with a nested type <tt>result_type</tt> defined as a synonym for
<tt>R</tt>. The effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt>INVOKE(fd, <ins>std::forward&lt;V1&gt;(</ins>v1<ins>)</ins>, 
<ins>std::forward&lt;V2&gt;(</ins>v2<ins>)</ins>, ..., <ins>std::forward&lt;VN&gt;(</ins>vN<ins>)</ins>, R)</tt>, where 
the values and types of the bound arguments <tt>v1</tt>, <tt>v2</tt>, ..., <tt>vN</tt> are determined as specified below. [&hellip;]
</p></blockquote></blockquote>

</li>

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

<blockquote><p>
-10- The values of the <i>bound arguments</i> <tt>v1</tt>, <tt>v2</tt>, ..., <tt>vN</tt> and their corresponding types <tt>V1</tt>, 
<tt>V2</tt>, ..., <tt>VN</tt> depend on the types <tt>TiD</tt> derived from the call to bind and the <i>cv</i>-qualifiers 
<i>cv</i> of the call wrapper <tt>g</tt> as follows:</p>
<ul>
<li>if <tt>TiD</tt> is <tt>reference_wrapper&lt;T&gt;</tt>, the argument is <tt>tid.get()</tt> and its type <tt>Vi</tt> 
is <tt>T&amp;</tt>;</li>
<li>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 <i>cv</i> <ins>&amp;</ins> (Uj<ins>&amp;&amp;</ins>...)&gt;::type<ins>&amp;&amp;</ins></tt>;</li>
<li>if the value <tt>j</tt> of <tt>is_placeholder&lt;TiD&gt;::value</tt> is not zero, the argument is 
<tt>std::forward&lt;Uj&gt;(uj)</tt> and its type <tt>Vi</tt> is <tt>Uj&amp;&amp;</tt>;</li>
<li>otherwise, the value is <tt>tid</tt> and its type <tt>Vi</tt> is <tt>TiD <i>cv</i> &amp;</tt>.</li>
</ul>
</blockquote>

</li>

<li>
<p>
This resolution assumes that the wording of 30.6.8 [futures.async] is intended to provide rvalues
as arguments of <tt>INVOKE</tt>.
</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</ins>(<ins>typename decay&lt;</ins>Args<ins>&gt;::type</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</ins>(<ins>typename decay&lt;</ins>Args<ins>&gt;::type</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] as indicated: (Remark: There is also a tiny editorial correction 
in p. 4 that completes one <tt>::</tt> scope specifier)
</p>

<blockquote><p>
-3- <i>Effects</i>: [&hellip;]
</p>
<ul>
<li>[&hellip;]</li>
<li>if <tt>policy &amp; launch::deferred</tt> is non-zero &mdash; Stores <tt><i>DECAY_COPY</i>(std::forward&lt;F&gt;(f))</tt> 
and <tt><i>DECAY_COPY</i>(std::forward&lt;Args&gt;(args))...</tt> in the shared state. These copies of <tt>f</tt> and 
<tt>args</tt> constitute a <i>deferred function</i>. Invocation of the deferred function evaluates 
<tt><i>INVOKE</i>(<ins>std::move(</ins>g<ins>)</ins>, <ins>std::move(</ins>xyz<ins>)</ins>)</tt>
where <tt>g</tt> is the stored value of <tt><i>DECAY_COPY</i>(std::forward&lt;F&gt;(f))</tt> and <tt>xyz</tt> is the 
stored copy of <tt><i>DECAY_COPY</i>(std::forward&lt;Args&gt;(args))...</tt>. The shared state is not made ready 
until the function has completed. The first call to a non-timed waiting function (30.6.4) on an asynchronous
return object referring to this shared state shall invoke the deferred function in the thread that
called the waiting function. Once evaluation of <tt><i>INVOKE</i>(<ins>std::move(</ins>g<ins>)</ins>, 
<ins>std::move(</ins>xyz<ins>)</ins>)</tt> begins, the function is no longer considered deferred. [ <i>Note</i>: If 
this policy is specified together with other policies, such as when using a <tt>policy</tt> value of 
<tt>launch::async | launch::deferred</tt>, implementations should defer invocation or the selection of 
the policy when no more concurrency can be effectively exploited. &mdash; <i>end note</i> ]</li>
</ul>
</blockquote>

<blockquote><p>
-4- <i>Returns</i>: an object of type 
<tt>future&lt;typename result_of&lt;<ins>typename decay&lt;</ins>F<ins>&gt;::type</ins>(<ins>typename decay&lt;</ins>Args<ins>&gt;::type</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="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-09-06</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="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#Ready">Ready</a>
 <b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2011-02-20 <b>Last modified:</b> 2011-09-06</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#Ready">Ready</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><i>[2011-06-12: Daniel comments and provides wording]</i></p>

<p>According to my understanding of the mental model of vector (and to some parts for deque) the 
some requirements are missing in the standard as response to above questions:</p>
<ol>
<li>The preconditions of <tt>shrink_to_fit</tt> for both <tt>std::vector</tt> and <tt>std::deque</tt>
should impose the <tt>MoveInsertable</tt> requirements. The reason for this is, that these containers
can host move-only types. For a container type <tt>X</tt> the C++03 idiom <tt>X(*this).swap(*this)</tt>
imposes the <tt>CopyInsertable</tt> requirements which would make the function call ill-formed,
which looks like an unacceptable restriction to me. Assuming the committee decides to support the
move-only case, further wording has to be added for the situation where such a move-only type could
throw an exception, because this can leave the object in an unspecified state. This seems consistent
with the requirements of <tt>reserve</tt>, which seems like a very similar function to me (for
<tt>vector</tt>). And this brings us smoothly to the following bullet:
</li>

<li><p>I agree that we are currently missing to specify the preconditions of the <tt>reserve</tt> function.
My interpretation of the mental model of this function is that it should work for move-only types, which
seems to be supported by the wording used in 23.3.6.3 [vector.capacity] p2:
</p>
<blockquote><p>
[&hellip;] If an exception is thrown other than by the move constructor of a non-CopyInsertable type, 
there are no effects.
</p></blockquote>
<p>
Given this statement, the appropriate requirement is <tt>MoveInsertable</tt> into the <tt>vector</tt>.
</p>
</li>

<li>I agree that <tt>vector::resize(size_type)</tt> misses to list the <tt>DefaultConstructible</tt>
requirements.
</li>

<li>Unfortunately the current specification in terms of <tt>erase</tt> implies the <tt>MoveAssignable</tt>
requirements. I don't think that this implication is intended. This function requires "append" and 
"pop-back" effects, respectively, where the former can be realized in terms of <tt>MoveInsertable</tt> 
requirements. The same fix in regard to using <tt>pop_back</tt> instead of <tt>erase</tt> is necessary 
for the two argument overload of <tt>resize</tt> as well (no <tt>MoveAssignable</tt> is required).
</li>

<li>The <tt>CopyInsertable</tt> requirement is incorrect and should be <tt>MoveInsertable</tt> instead.</li>
</ol>

<p>In addition to above mentioned items, the proposed resolution adds a linear complexity bound for 
<tt>shrink_to_fit</tt> and attempts to resolve the related issue <a href="lwg-active.html#2066">2066</a>.</p>

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


<p>
Move to Ready.
</p>

<p>
Note for editor: we do not normally refer to 'linear <i>time</i>' for complexity requirements, but there
is agreement that any clean-up of such wording is editorial.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>Edit 23.3.3.3 [deque.capacity] as indicated [Remark: The suggested change of p4 is
not redundant, because <tt>CopyInsertable</tt> is not necessarily a refinement of <tt>MoveInsertable</tt>
in contrast to the fact that <tt>CopyConstructible</tt> is a refinement of <tt>MoveConstructible</tt>]:</p>

<blockquote><pre>
void resize(size_type sz);
</pre><blockquote><p>
-1- <i>Effects</i>: If <tt>sz &lt;= size()</tt>, equivalent to <del><tt>erase(begin() + sz, 
end());</tt></del><ins>calling <tt>pop_back()</tt> <tt>size() - sz</tt> times</ins>. If 
<tt>size() &lt; sz</tt>, appends <tt>sz - size()</tt> value-initialized elements to the sequence.
<p/>
-2- Requires: <tt>T</tt> shall be <ins><tt>MoveInsertable</tt> into <tt>*this</tt> and</ins> <tt>DefaultConstructible</tt>.
</p></blockquote></blockquote>

<blockquote><pre>
void resize(size_type sz, const T&amp; c);
</pre><blockquote><p>
-3- <i>Effects</i>: <ins>If <tt>sz &lt;= size()</tt>, equivalent to calling <tt>pop_back()</tt> 
<tt>size() - sz</tt> times. If <tt>size() &lt; sz</tt>, appends <tt>sz - size()</tt> copies of <tt>c</tt> 
to the sequence.</ins>
</p><blockquote><pre>
<del>if (sz &gt; size())
  insert(end(), sz-size(), c);
else if (sz &lt; size())
  erase(begin()+sz, end());
else
  ; <i>// do nothing</i></del>
</pre></blockquote>
<p>
-4- <i>Requires</i>: <tt>T</tt> shall be <ins><tt>MoveInsertable</tt> into <tt>*this</tt> and</ins> 
<tt>CopyInsertable</tt> into <tt>*this</tt>.
</p></blockquote></blockquote>

<blockquote><pre>
void shrink_to_fit();
</pre><blockquote><p>
<ins>-?- <i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.</ins>
<p/>
<ins>-?- <i>Complexity</i>: Takes at most linear time in the size of the sequence.</ins>
<p/>
-5- <i>Remarks</i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce memory use <ins>but does
not change the size of the sequence</ins>. [ <i>Note</i>: The request is non-binding to allow latitude 
for implementation-specific optimizations. &mdash; <i>end note</i> ]
</p></blockquote></blockquote>
</li>

<li><p>Edit 23.3.6.3 [vector.capacity] as indicated including edits that also resolve <a href="lwg-active.html#2066">2066</a> 
[Remark: The combined listing of <tt>MoveInsertable</tt> and <tt>CopyInsertable</tt> before p12 is not redundant, 
because <tt>CopyInsertable</tt> is not necessarily a refinement of <tt>MoveInsertable</tt> in contrast to the 
fact that <tt>CopyConstructible</tt> is a refinement of <tt>MoveConstructible</tt>]:</p>

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

<blockquote><pre>
void reserve(size_type n);
</pre><blockquote><p>
<ins>-?- <i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.</ins>
<p/>
-2- <i>Effects</i>: A directive that informs a vector of a planned change in size, so that it can manage the storage
allocation accordingly. After <tt>reserve()</tt>, <tt>capacity()</tt> is greater or equal to the argument of reserve if
reallocation happens; and equal to the previous value of <tt>capacity()</tt> otherwise. Reallocation happens
at this point if and only if the current capacity is less than the argument of <tt>reserve()</tt>. If an exception
is thrown other than by the move constructor of a non-<tt>CopyInsertable</tt> type, there are no effects.
<p/>
-3- <i>Complexity</i>: It does not change the size of the sequence and takes at most linear time in the size of
the sequence.
<p/>
-4- <i>Throws</i>: <tt>length_error</tt> if <tt>n &gt; max_size()</tt>.[footnote 266]
<p/>
-5- <i>Remarks</i>: Reallocation invalidates all the references, pointers, and iterators referring to the elements
in the sequence. It is guaranteed that no reallocation takes place during insertions that happen after
a call to <tt>reserve()</tt> until the time when an insertion would make the size of the vector greater than
the value of <tt>capacity()</tt>.
</p></blockquote></blockquote>

<blockquote><pre>
void shrink_to_fit();
</pre><blockquote><p>
<ins>-?- <i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.</ins>
<p/>
<ins>-?- <i>Complexity</i>: Takes at most linear time in the size of the sequence.</ins>
<p/>
-6- <i>Remarks</i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to <tt>size()</tt>. 
[ <i>Note</i>: The request is non-binding to allow latitude for implementation-specific optimizations. &mdash; <i>end note</i> ]
<ins>If an exception is thrown other than by the move constructor of a non-<tt>CopyInsertable</tt> <tt>T</tt> there 
are no effects.</ins>
</p></blockquote></blockquote>

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

<blockquote><pre>
void resize(size_type sz);
</pre><blockquote><p>
-9- <i>Effects</i>: If <tt>sz &lt;= size()</tt>, equivalent to <del><tt>erase(begin() + sz, end());</tt></del><ins>calling 
<tt>pop_back()</tt> <tt>size() - sz</tt> times</ins>. 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><del>Copy</del><ins>Move</ins>Insertable</tt> into <tt>*this</tt> 
<ins>and <tt>DefaultConstructible</tt></ins>.
<p/>
<ins>-??- <i>Remarks</i>: If an exception is thrown other than by the move constructor of a non-<tt>CopyInsertable</tt> 
<tt>T</tt> there are no effects.</ins>
</p></blockquote></blockquote>

<blockquote><pre>
void resize(size_type sz, const T&amp; c);
</pre><blockquote><p>
-11- <i>Effects</i>: <ins>If <tt>sz &lt;= size()</tt>, equivalent to calling <tt>pop_back()</tt> 
<tt>size() - sz</tt> times. If <tt>size() &lt; sz</tt>, appends <tt>sz - size()</tt> copies of <tt>c</tt> 
to the sequence.</ins>
</p><blockquote><pre>
<del>if (sz &gt; size())
  insert(end(), sz-size(), c);
else if (sz &lt; size())
  erase(begin()+sz, end());
else
  ; <i>// do nothing</i></del>
</pre></blockquote><p>
<ins>-??- <i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt> and 
<tt>CopyInsertable</tt> into <tt>*this</tt>.</ins>
<p/>
-12- <i><del>Requires</del><ins>Remarks</ins></i>: If an exception is thrown other than by the move constructor of a 
non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.
</p></blockquote></blockquote>

</li>

</ol>





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

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


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

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


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

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


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

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

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


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



<p><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&#47;note<br/>pre-&#47;post-condition</th>
</tr>

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

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

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

<li><p>Modify the column contents of Table 107 &mdash; &quot;Input iterator requirements&quot;, 
24.2.3 [input.iterators], as indicated:</p>

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

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

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

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

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

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

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

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

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

<li>
<p>Modify the column contents of Table 108 &mdash; &quot;Output iterator requirements&quot;, 
24.2.4 [output.iterators], as indicated:</p>

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

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

<tr>
<td><tt>*r = o</tt></td>
<td>result is not used</td>
<td><tt>&nbsp;</tt></td>
<td><ins>pre: <tt>r</tt> is dereferenceable.</ins><br/>
<del><i>Remark</i>: After this operation<br/>
<tt>r</tt> is not required to be<br/>
dereferenceable.</del><br/>
post: <tt>r</tt> is incrementable.
</td>
</tr>

<tr>
<td><tt>++r</tt></td>
<td><tt>X&amp;</tt></td>
<td><tt>&nbsp;</tt></td>
<td><ins>pre: <tt>r</tt> is incrementable.</ins><br/>
<tt>&amp;r == &amp;++r</tt>.<br/>
<del><i>Remark</i>: After this operation<br/>
<tt>r</tt> is not required to be<br/>
dereferenceable.</del><br/>
post: <tt>r</tt> is <ins>dereferenceable<br/>
or <tt>r</tt> is past-the-end</ins><del>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><del><i>Remark</i>: After this operation<br/>
<tt>r</tt> is not required to be<br/>
dereferenceable.<br/>
post: <tt>r</tt> is incrementable.</del>
</td>
</tr>

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

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

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

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

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

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

</li>

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

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

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

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

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

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





<hr>
<h3><a name="2038"></a>2038. Missing definition for <tt>incrementable</tt> iterator</h3>
<p><b>Section:</b> 24.2.4 [output.iterators] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2011-02-27 <b>Last modified:</b> 2011-09-06</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]&#47;11 (<tt>do_get</tt>) 
there is a requirement that a pointer "shall be dereferenceable". In those specific cases 
it is not defined.
</p>

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


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

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


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



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





<hr>
<h3><a name="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-09-06</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="2044"></a>2044. No definition of "Stable" for copy algorithms</h3>
<p><b>Section:</b> 17.6.5.7 [algorithm.stable] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2011-03-24 <b>Last modified:</b> 2011-09-06</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
17.6.5.7 [algorithm.stable] specified the meaning of "stable" when applied to 
the different types of algorithms. The second bullet says:
</p>
<blockquote><p>
&mdash; For the <i>remove</i> algorithms the relative order of the elements that are not removed is preserved.
</p></blockquote>

<p>
There is no description of what "stable" means for copy algorithms, even though the term is 
applied to <tt>copy_if</tt> (and perhaps others now or in the future). Thus, <tt>copy_if</tt> 
is using the term without a precise definition.
</p>

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

<p>
Move to Ready
</p>



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

<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>In 17.6.5.7 [algorithm.stable] p. 1 change as indicated:</p>

<blockquote><p>
When the requirements for an algorithm state that it is stable without further elaboration, it means:
</p>
<ul>
<li>For the <i>sort</i> algorithms the relative order of equivalent elements is preserved.</li>
<li>For the <i>remove</i> <ins>and <i>copy</i></ins> algorithms the relative order of the elements that are 
not removed is preserved.</li>
<li>For the <i>merge</i> algorithms, for equivalent elements in the original two ranges, the elements from the
first range precede the elements from the second range.</li>
</ul>
</blockquote>

</li>

</ol>






<hr>
<h3><a name="2045"></a>2045. <tt>forward_list::merge</tt> and <tt>forward_list::splice_after</tt> with unequal allocators</h3>
<p><b>Section:</b> 23.3.4.6 [forwardlist.ops] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2011-03-24 <b>Last modified:</b> 2011-09-06</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#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
See also: <a href="lwg-defects.html#1215">1215</a>
</p>

<p>
<tt>list::merge</tt> and <tt>list::splice</tt> have the requirement that the two lists being merged or 
spliced must use the same allocator. Otherwise, moving list nodes from one container to the other would 
corrupt the data structure. The same requirement is needed for <tt>forward_list::merge</tt> and 
<tt>forward_list::splice_after</tt>.
</p>

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


<p>
Move to Ready.
</p>



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

<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>In 23.3.4.6 [forwardlist.ops] p. 1 change as indicated:</p>

<blockquote><pre>
void splice_after(const_iterator position, forward_list&lt;T,Allocator&gt;&amp; x);
void splice_after(const_iterator position, forward_list&lt;T,Allocator&gt;&amp;&amp; x);
</pre><p>
1 - <i>Requires</i>: <tt>position</tt> is <tt>before_begin()</tt> or is a dereferenceable 
iterator in the range [<tt>begin()</tt>,<tt>end()</tt>). <ins><tt>get_allocator() == x.get_allocator()</tt>.</ins> 
<tt>&amp;x != this</tt>.
</p></blockquote>

</li>

<li><p>In 23.3.4.6 [forwardlist.ops] p. 5 change as indicated:</p>

<blockquote><pre>
void splice_after(const_iterator position, forward_list&lt;T,Allocator&gt;&amp; x, const_iterator i);
void splice_after(const_iterator position, forward_list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
</pre><p>
5 - <i>Requires</i>: <tt>position</tt> is <tt>before_begin()</tt> or is a dereferenceable 
iterator in the range [<tt>begin()</tt>,<tt>end()</tt>). The iterator following <tt>i</tt> is a 
dereferenceable iterator in <tt>x</tt>. <ins><tt>get_allocator() == x.get_allocator()</tt>.</ins>
</p></blockquote>

</li>

<li><p>In 23.3.4.6 [forwardlist.ops] p. 9 change as indicated:</p>

<blockquote><pre>
void splice_after(const_iterator position, forward_list&lt;T,Allocator&gt;&amp; x, 
                  const_iterator first, const_iterator last);
void splice_after(const_iterator position, forward_list&lt;T,Allocator&gt;&amp;&amp; x, 
                  const_iterator first, const_iterator last);
</pre><p>
9 - <i>Requires</i>: <tt>position</tt> is <tt>before_begin()</tt> or is a dereferenceable 
iterator in the range [<tt>begin()</tt>,<tt>end()</tt>). (<tt>first</tt>,<tt>last</tt>) is a valid range 
in <tt>x</tt>, and all iterators in the range (<tt>first</tt>,<tt>last</tt>) are dereferenceable.
<tt>position</tt> is not an iterator in the range (<tt>first</tt>,<tt>last</tt>). 
<ins><tt>get_allocator() == x.get_allocator()</tt>.</ins>
</p></blockquote>

</li>

<li><p>In 23.3.4.6 [forwardlist.ops] p. 18 change as indicated:</p>

<blockquote><pre>
void merge(forward_list&lt;T,Allocator&gt;&amp; x);
void merge(forward_list&lt;T,Allocator&gt;&amp;&amp; x);
template &lt;class Compare&gt; void merge(forward_list&lt;T,Allocator&gt;&amp; x, Compare comp);
template &lt;class Compare&gt; void merge(forward_list&lt;T,Allocator&gt;&amp;&amp; x, Compare comp);
</pre><p>
18 - <i>Requires</i>: <tt>comp</tt> defines a strict weak ordering ([alg.sorting]), and <tt>*this</tt> 
and <tt>x</tt> are both sorted according to this ordering. <ins><tt>get_allocator() == x.get_allocator()</tt>.</ins>
</p></blockquote>

</li>

</ol>






<hr>
<h3><a name="2047"></a>2047. Incorrect "mixed" move-assignment semantics of <tt>unique_ptr</tt></h3>
<p><b>Section:</b> 20.7.1.2.3 [unique.ptr.single.asgn] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-04-16 <b>Last modified:</b> 2011-09-06</p>
<p><b>View all other</b> <a href="lwg-index.html#unique.ptr.single.asgn">issues</a> in [unique.ptr.single.asgn].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>The semantics described in 20.7.1.2.3 [unique.ptr.single.asgn] p. 6</p>
<blockquote><p>
<i>Effects</i>: Transfers ownership from <tt>u</tt> to <tt>*this</tt> as if [&hellip;] followed 
by an assignment from <tt>std::forward&lt;D&gt;(u.get_deleter())</tt>.
</p></blockquote>
<p>
contradicts to the pre-conditions described in p. 4:
</p>
<blockquote><p>
<i>Requires</i>: If E is not a reference type, assignment of the deleter from an rvalue of type <tt>E</tt> shall be
well-formed and shall not throw an exception. Otherwise, <tt>E</tt> is a reference type and assignment of the
deleter from an lvalue of type <tt>E</tt> shall be well-formed and shall not throw an exception.
</p></blockquote>
<p>
Either the pre-conditions are incorrect or the semantics should be an assignment from
<tt>std::forward&lt;<span style="color:red;font-weight:bolder">E</span>&gt;(u.get_deleter())</tt>, instead.
</p>
<p>It turns out that this contradiction is due to an incorrect transcription from the proposed
resolution of <a href="lwg-defects.html#983">983</a> to the finally accepted proposal 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">n3073</a> (see
bullet 12) as confirmed by Howard Hinnant, thus the type argument provided to <tt>std::forward</tt>
must be fixed as indicated.
</p>

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

<p>
Move to Ready
</p>



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

<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Edit 20.7.1.2.3 [unique.ptr.single.asgn] p. 6 as indicated:</p>

<blockquote><pre>
template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u) noexcept;
</pre><blockquote><p>
4 - <i>Requires</i>: If <tt>E</tt> is not a reference type, assignment of the deleter from an rvalue 
of type <tt>E</tt> shall be well-formed and shall not throw an exception. Otherwise, <tt>E</tt> is a 
reference type and assignment of the deleter from an lvalue of type <tt>E</tt> shall be well-formed and 
shall not throw an exception.
<p/>
5 - <i>Remarks</i>: This operator shall not participate in overload resolution unless:</p>
<ul>
<li><tt>unique_ptr&lt;U, E&gt;::pointer</tt> is implicitly convertible to <tt>pointer</tt> and</li>
<li><tt>U</tt> is not an array type.</li>
</ul>
<p>
6 - <i>Effects</i>: Transfers ownership from <tt>u</tt> to <tt>*this</tt> as if by calling 
<tt>reset(u.release())</tt> followed by an assignment from <tt>std::forward&lt;<del>D</del><ins>E</ins>&gt;(u.get_deleter())</tt>.
<p/>
7 - <i>Returns</i>: <tt>*this</tt>.
</p>
</blockquote>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="2048"></a>2048. Unnecessary <tt>mem_fn</tt> overloads</h3>
<p><b>Section:</b> 20.8 [function.objects], 20.8.10 [func.memfn] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-04-18 <b>Last modified:</b> 2011-09-06</p>
<p><b>View all other</b> <a href="lwg-index.html#function.objects">issues</a> in [function.objects].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>mem_fn</tt> overloads for member functions are redundant and misleading
and should be removed from the post-C++11 WP.
<p/>
I believe the history of the overloads is as follows:
<p/>
In TR1 and in C++0x prior to the N2798 draft, <tt>mem_fn</tt> was specified by
a single signature:
</p>
<blockquote><pre>
template&lt;class R, class T&gt; <i>unspecified</i> mem_fn(R T::* pm);
</pre></blockquote>
<p>
and was accompanied by the remark "Implementations may implement <tt>mem_fn</tt> 
as a set of overloaded function templates." This remark predates variadic templates 
and was presumably to allow implementations to provide overloads for a limited 
number of function parameters, to meet the implementation-defined limit on numbers of
template parameters.
<p/>
N2770 "Concepts for the C++0x Standard Library: Utilities" added
separate overloads for pointers to member functions, apparently so
that function parameters would require the <tt>CopyConstructible</tt> concept
(those overloads first appeared in N2322.) The overloads failed to
account for varargs member functions (i.e. those declared with an
ellipsis in the parameter-declaration-clause) e.g.
</p>
<blockquote><pre>
struct S {
 int f(int, ...);
};
</pre></blockquote>
<p>
Syntactically such a function would be handled by the original
<tt>mem_fn(R T::* pm)</tt> signature, the only minor drawback being that there
would be no <tt>CopyConstructible</tt> requirement on the parameter list. (Core
DR 547 clarifies that partial specializations can be written to match
cv-qualified and ref-qualified functions to support the case where <tt>R T::*</tt> 
matches a pointer to member function type.)
<p/>
LWG issue <a href="lwg-defects.html#920">920</a> pointed out that additional overloads were missing for
member functions with ref-qualifiers. These were not strictly
necessary, because such functions are covered by the <tt>mem_fn(R T::* pm)</tt> signature.
<p/>
Concepts were removed from the draft and N3000 restored the original
single signature and accompanying remark.
<p/>
LWG <a href="lwg-closed.html#1230">1230</a> was opened to strike the remark again and to add an overload
for member functions (this overload was unnecessary for syntactic reasons and 
insufficient as it didn't handle member functions with cv-qualifiers and&#47;or 
ref-qualifiers.)
<p/>
<a href="lwg-defects.html#920">920</a> (and <a href="lwg-closed.html#1230">1230</a>) were resolved by restoring a full set of
(non-concept-enabled) overloads for member functions with cv-qualifiers and ref-qualifiers,
but as in the concept-enabled draft there were no overloads for member functions with 
an ellipsis in the parameter-declaration-clause. This is what is present in the FDIS.
<p/>
Following the thread beginning with message c++std-lib-30675, it is my
understanding that all the <tt>mem_fn</tt> overloads for member functions are
unnecessary and were only ever added to allow concept requirements.
I'm not aware of any reason implementations cannot implement <tt>mem_fn</tt> as
a single function template. Without concepts the overloads are
redundant, and the absence of overloads for varargs functions can be
interpreted to imply that varargs functions are not intended to work
with <tt>mem_fn</tt>. Clarifying the intent by adding overloads for varargs
functions would expand the list of 12 redundant overloads to 24, it
would be much simpler to remove the 12 redundant overloads entirely.
</p>

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

<p>
Move to Review.
</p>

<p>
The issue and resolution appear to be correct, but there is some concern that the wording of INVOKE may be different depending on whether you pass a pointer-to-member-data or pointer-to-member-function.  That might make the current wording necessary after all, and then we might need to add the missing elipsis overloads.
</p>

<p>
There was some concern that the Remark confirming implementors had freedom to implement this as a set of overloaded functions may need to be restored if we delete the specification for these overloads.
</p>



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

<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Change the <tt>&lt;functional&gt;</tt> synopsis 20.8 [function.objects] p. 2 as follows:</p>

<blockquote><pre>
namespace std {
  [&hellip;]
  // <i>[func.memfn], member function adaptors:</i>
  template&lt;class R, class T&gt; <i>unspecified</i> mem_fn(R T::*);
<del>  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...));
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) const);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) volatile);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) &amp;);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) const &amp;);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) volatile &amp;);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile &amp;);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) &amp;&amp;);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) const &amp;&amp;);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) volatile &amp;&amp;);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile &amp;&amp;);</del>

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

<li><p>Change 20.8.10 [func.memfn] as follows:</p>

<blockquote><pre>
template&lt;class R, class T&gt; <i>unspecified</i> mem_fn(R T::*);
<del>template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...));
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) const);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) volatile);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) &amp;);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) const &amp;);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) volatile &amp;);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile &amp;);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) &amp;&amp;);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) const &amp;&amp;);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) volatile &amp;&amp;);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile &amp;&amp;);</del>
</pre></blockquote>
</li>

</ol>






<hr>
<h3><a name="2049"></a>2049. <tt>is_destructible</tt> is underspecified</h3>
<p><b>Section:</b> 20.9.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-04-18 <b>Last modified:</b> 2011-09-06</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>
<p>The conditions for the type trait <tt>is_destructible</tt> to be true
are described in Table 49 &mdash; Type property predicates:</p>
<blockquote><p>
For a complete type <tt>T</tt> and given<br/>
<tt>template &lt;class U&gt;
struct test { U u; };</tt>,<br/>
<tt>test&lt;T&gt;::~test()</tt> is not deleted.
</p></blockquote>

<p>This specification does not say what the result would be for function
types or for abstract types:</p>
<ol>
<li>For an abstract type <tt>X</tt> the instantiation <tt>test&lt;X&gt;</tt>
is already ill-formed, so we cannot say anything about whether the destructor
would be deleted or not.</li>
<li>In regard to function types, there exists a special rule in the core language, 14.3.1 [temp.arg.type] p. 3,
which excludes member functions to be declared via the type of the template parameter:
<blockquote><p>
If a declaration acquires a function type through a type dependent on a <i>template-parameter</i>
and this causes a declaration that does not use the syntactic form of a function declarator 
to have function type, the program is ill-formed. 
<p/>
[ <i>Example</i>:</p>
<blockquote><pre>
template&lt;class T&gt; struct A {
  static T t;
};
typedef int function();
A&lt;function&gt; a; // ill-formed: would declare A&lt;function&gt;::t
               // as a static member function
</pre></blockquote>
<p>
&mdash; <i>end example</i> ]
</p></blockquote>
which has the same consequence as for abstract types, namely that the corresponding
instantiation of <tt>test</tt> is already ill-formed and we cannot say anything
about the destructor.
</li>
</ol>
<p>To solve this problem, I suggest to specify function types as trivially and nothrowing
destructible, because above mentioned rule is very special for templates. For non-templates,
a typedef can be used to introduce a member as member function as clarified in 8.3.5 [dcl.fct]
p. 10.</p>
<p>For abstract types, two different suggestions have been brought to my attention:
Either declare them as unconditionally non-destructible or check whether the expression
</p>
<blockquote><pre>
std::declval&lt;T&amp;&gt;().~T()
</pre></blockquote>
<p>is well-formed in an unevaluated context. The first solution is very easy to specify,
but the second version has the advantage for providing more information to user-code. This 
information could be quite useful, if generic code is supposed to invoke the destructor
of a reference to a base class indirectly via a delete expression, as suggested by
Howard Hinnant:</p>
<blockquote><pre>
template &lt;class T&gt;
my_pointer&lt;T&gt;::~my_pointer() noexcept(is_nothrow_destructible&lt;T&gt;::value)
{
   delete ptr_;
}
</pre></blockquote>
<p>Additional to the <tt>is_destructible</tt> traits, its derived forms <tt>is_trivially_destructible</tt>
and <tt>is_nothrow_destructible</tt> are similarly affected, because their wording refers to "the indicated
destructor" and probably need to be adapted as well.</p>

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


<p>
After discussion about to to handle the exceptional cases of reference types, function types (available by defererencing a function pointer)
and <tt>void</tt> types, Howard supplied proposed wording.
</p>


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

<p>
Update 20.9.4.3 [meta.unary.prop], table 49:
</p>

<table border="1">
<tr>
<td><tt>template &lt;class T>
struct is_destructible;</tt></td>
<td>
<del>For a complete type <tt>T</tt> and given <tt>template &lt;class U> struct test { U u; };</tt>, <tt>test&lt;T>:: ̃test()</tt> is not deleted.
</del>
<br/>
<ins>
For object types, if the expression: <tt>std::declval&lt;T&amp;>().~T()</tt> is well-formed in an unevaluated context then
<tt>is_destructible&lt;T>::value</tt> is <tt>true</tt>, otherwise it is <tt>false</tt>.
<br/>
For <tt>void</tt> types, <tt>is_destructible&lt;T>::value</tt> is <tt>false</tt>.
<br/>
For reference types, <tt>is_destructible&lt;T>::value</tt> is <tt>true</tt>.
<br/>
For function types, <tt>is_destructible&lt;T>::value</tt> is <tt>false</tt>.
</ins>
</td>
<td><tt>T</tt> shall be a complete type, (possibly cv-qualified) <tt>void</tt>, or an array of unknown bound.</td>
</tr>
</table>






<hr>
<h3><a name="2050"></a>2050. Unordered associative containers do not use <tt>allocator_traits</tt> to define member types</h3>
<p><b>Section:</b> 23.5 [unord] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tom Zieberman <b>Opened:</b> 2011-04-29 <b>Last modified:</b> 2011-09-06</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#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>The unordered associative containers define their member types <tt>reference</tt>, 
<tt>const_reference</tt>, <tt>pointer</tt>, <tt>const_pointer</tt> in terms of 
their template parameter <tt>Allocator</tt> (via <tt>allocator_type</tt> typedef). As 
a consequence, only the allocator types, that provide sufficient typedefs, are usable 
as allocators for unordered associative containers, while other containers do not have 
this deficiency. In addition to that, the definitions of said typedefs are different 
from ones used in the other containers. This is counterintuitive and introduces a certain 
level of confusion. These issues can be fixed by defining <tt>pointer</tt> and 
<tt>const_pointer</tt> typedefs in terms of <tt>allocator_traits&lt;Allocator&gt;</tt> 
and by defining <tt>reference</tt> and <tt>const_reference</tt> in terms of 
<tt>value_type</tt> as is done in the other containers.
</p>

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


<p>
Move to Ready.
</p>



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

<p>This wording is relative to the FDIS.</p>

<ul>
<li><p>Change 23.5.4.1 [unord.map.overview] paragraph 3 as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class Key,
            class T,
            class Hash = hash&lt;Key&gt;,
            class Pred = std::equal_to&lt;Key&gt;,
            class Allocator = std::allocator&lt;std::pair&lt;const Key, T&gt; &gt; &gt;
  class unordered_map
  {
  public:
    <i>// types</i>
    typedef Key key_type;
    typedef std::pair&lt;const Key, T&gt; value_type;
    typedef T mapped_type;
    typedef Hash hasher;
    typedef Pred key_equal;
    typedef Allocator allocator_type;
    typedef typename <del>allocator_type</del><ins>allocator_traits&lt;Allocator&gt;</ins>::pointer pointer;
    typedef typename <del>allocator_type</del><ins>allocator_traits&lt;Allocator&gt;</ins>::const_pointer const_pointer;
    typedef <del>typename allocator_type::reference</del><ins>value_type&amp;</ins> reference;
    typedef <del>typename allocator_type::const_reference</del><ins>const value_type&amp;</ins> const_reference;
    typedef <i>implementation-defined</i> size_type;
    typedef <i>implementation-defined</i> difference_type;

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

<li><p>Change 23.5.5.1 [unord.multimap.overview] paragraph 3 as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class Key,
            class T,
            class Hash = hash&lt;Key&gt;,
            class Pred = std::equal_to&lt;Key&gt;,
            class Allocator = std::allocator&lt;std::pair&lt;const Key, T&gt; &gt; &gt;
  class unordered_multimap
  {
  public:
    <i>// types</i>
    typedef Key key_type;
    typedef std::pair&lt;const Key, T&gt; value_type;
    typedef T mapped_type;
    typedef Hash hasher;
    typedef Pred key_equal;
    typedef Allocator allocator_type;
    typedef typename <del>allocator_type</del><ins>allocator_traits&lt;Allocator&gt;</ins>::pointer pointer;
    typedef typename <del>allocator_type</del><ins>allocator_traits&lt;Allocator&gt;</ins>::const_pointer const_pointer;
    typedef <del>typename allocator_type::reference</del><ins>value_type&amp;</ins> reference;
    typedef <del>typename allocator_type::const_reference</del><ins>const value_type&amp;</ins> const_reference;
    typedef <i>implementation-defined</i> size_type;
    typedef <i>implementation-defined</i> difference_type;

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

<li><p>Change 23.5.6.1 [unord.set.overview] paragraph 3 as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class Key,
            class Hash = hash&lt;Key&gt;,
            class Pred = std::equal_to&lt;Key&gt;,
            class Allocator = std::allocator&lt;Key&gt; &gt;
  class unordered_set
  {
  public:
    <i>// types</i>
    typedef Key key_type;
    typedef Key value_type;
    typedef Hash hasher;
    typedef Pred key_equal;
    typedef Allocator allocator_type;
    typedef typename <del>allocator_type</del><ins>allocator_traits&lt;Allocator&gt;</ins>::pointer pointer;
    typedef typename <del>allocator_type</del><ins>allocator_traits&lt;Allocator&gt;</ins>::const_pointer const_pointer;
    typedef <del>typename allocator_type::reference</del><ins>value_type&amp;</ins> reference;
    typedef <del>typename allocator_type::const_reference</del><ins>const value_type&amp;</ins> const_reference;
    typedef <i>implementation-defined</i> size_type;
    typedef <i>implementation-defined</i> difference_type;

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

<li><p>Change 23.5.7.1 [unord.multiset.overview] paragraph 3 as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class Key,
            class Hash = hash&lt;Key&gt;,
            class Pred = std::equal_to&lt;Key&gt;,
            class Allocator = std::allocator&lt;Key&gt; &gt;
  class unordered_multiset
  {
  public:
    <i>// types</i>
    typedef Key key_type;
    typedef Key value_type;
    typedef Hash hasher;
    typedef Pred key_equal;
    typedef Allocator allocator_type;
    typedef typename <del>allocator_type</del><ins>allocator_traits&lt;Allocator&gt;</ins>::pointer pointer;
    typedef typename <del>allocator_type</del><ins>allocator_traits&lt;Allocator&gt;</ins>::const_pointer const_pointer;
    typedef <del>typename allocator_type::reference</del><ins>value_type&amp;</ins> reference;
    typedef <del>typename allocator_type::const_reference</del><ins>const value_type&amp;</ins> const_reference;
    typedef <i>implementation-defined</i> size_type;
    typedef <i>implementation-defined</i> difference_type;

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

</ul>






<hr>
<h3><a name="2052"></a>2052. Mixup between <tt>mapped_type</tt> and <tt>value_type</tt> for associative containers</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Marc Glisse <b>Opened:</b> 2011-05-04 <b>Last modified:</b> 2011-09-06</p>
<p><b>View other</b> <a href="lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
(this is basically reopening the first part of issue <a href="lwg-closed.html#2006">2006</a>, as discussed in the thread 
starting at c++std-lib-30698 )
<p/>
Section 23.2.4 [associative.reqmts]
<p/>
In Table 102, several uses of <tt>T</tt> (which means <tt>mapped_type</tt> here) should
be <tt>value_type</tt> instead. This is almost editorial. For instance:
</p>
<blockquote><pre>
a_uniq.emplace(args)
</pre><p>
<i>Requires</i>: <tt>T</tt> shall be <tt>EmplaceConstructible</tt> into <tt>X</tt> from args.
<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 pair is true if and only if the insertion takes place, and the iterator component 
of the pair points to the element with key equivalent to the key of <tt>t</tt>.
</p></blockquote>

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


<p>
Not even an exhaustive list of problem locations. No reason to doubt issue.
</p>
<p>
Pablo agrees to provide wording.
</p>



<p><b>Proposed resolution:</b></p>
<p>
In section  [associative.reqmnts] table 102 and 23.2.5 [unord.req], table 103, make the following text replacements:
</p>

<table border="1">
<tr> <td>Original text, in FDIS</td>                   <td>Replacement text</td> </tr>
<tr> <td><tt>T</tt> is CopyInsertable</td>             <td><tt>value_type</tt> is CopyInsertable</td> </tr>
<tr> <td><tt>T</tt> shall be CopyInsertable</td>       <td><tt>value_type</tt> shall be CopyInsertable</td> </tr>
<tr> <td><tt>T</tt> shall be MoveInsertable</td>       <td><tt>value_type</tt> shall be MoveInsertable</td> </tr>
<tr> <td><tt>T</tt> shall be EmplaceConstructible</td> <td><tt>value_type</tt> shall be EmplaceConstructible</td> </tr>
<tr> <td><tt>T</tt> object</td>                        <td><tt>value_type</tt> object</td> </tr>
</table>

<p><i>[
<b>Notes to the editor</b>: The above are carefully selected phrases that can be used for global
search-and-replace within the specified sections without accidentally making changes to correct uses <tt>T</tt>.
]</i></p>






<hr>
<h3><a name="2053"></a>2053. Errors in <tt>regex</tt> bitmask types</h3>
<p><b>Section:</b> 28.5 [re.const] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-05-09 <b>Last modified:</b> 2011-09-06</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
When <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3110.html">N3110</a> 
was applied to the WP some redundant "static" keywords were added and one form of initializer 
which isn't valid for enumeration types was replaced with another form of invalid initializer.
</p>

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


<p>
Move to Ready.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>Change 28.5.1 [re.synopt] as indicated:</p>
<blockquote><pre>
namespace std {
  namespace regex_constants {
    typedef <i>T1</i> syntax_option_type;
    <del>static </del>constexpr syntax_option_type icase = <i>unspecified</i> ;
    <del>static </del>constexpr syntax_option_type nosubs = <i>unspecified</i> ;
    <del>static </del>constexpr syntax_option_type optimize = <i>unspecified</i> ;
    <del>static </del>constexpr syntax_option_type collate = <i>unspecified</i> ;
    <del>static </del>constexpr syntax_option_type ECMAScript = <i>unspecified</i> ;
    <del>static </del>constexpr syntax_option_type basic = <i>unspecified</i> ;
    <del>static </del>constexpr syntax_option_type extended = <i>unspecified</i> ;
    <del>static </del>constexpr syntax_option_type awk = <i>unspecified</i> ;
    <del>static </del>constexpr syntax_option_type grep = <i>unspecified</i> ;
    <del>static </del>constexpr syntax_option_type egrep = <i>unspecified</i> ;
  }
}
</pre></blockquote>
</li>

<li><p>Change 28.5.2 [re.matchflag] as indicated:</p>
<blockquote><pre>
namespace std {
  namespace regex_constants {
    typedef <i>T2</i> match_flag_type;
    <del>static </del>constexpr match_flag_type match_default<del> = 0</del><ins>{};</ins>
    <del>static </del>constexpr match_flag_type match_not_bol = <i>unspecified</i> ;
    <del>static </del>constexpr match_flag_type match_not_eol = <i>unspecified</i> ;
    <del>static </del>constexpr match_flag_type match_not_bow = <i>unspecified</i> ;
    <del>static </del>constexpr match_flag_type match_not_eow = <i>unspecified</i> ;
    <del>static </del>constexpr match_flag_type match_any = <i>unspecified</i> ;
    <del>static </del>constexpr match_flag_type match_not_null = <i>unspecified</i> ;
    <del>static </del>constexpr match_flag_type match_continuous = <i>unspecified</i> ;
    <del>static </del>constexpr match_flag_type match_prev_avail = <i>unspecified</i> ;
    <del>static </del>constexpr match_flag_type format_default<del> = 0</del><ins>{}</ins>;
    <del>static </del>constexpr match_flag_type format_sed = <i>unspecified</i> ;
    <del>static </del>constexpr match_flag_type format_no_copy = <i>unspecified</i> ;
    <del>static </del>constexpr match_flag_type format_first_only = <i>unspecified</i> ;
  }
}
</pre></blockquote>
</li>

<li><p>Change 28.5.3 [re.err] as indicated:</p>
<blockquote><pre>
namespace std {
  namespace regex_constants {
    typedef <i>T3</i> error_type;
    <del>static </del>constexpr error_type error_collate = <i>unspecified</i> ;
    <del>static </del>constexpr error_type error_ctype = <i>unspecified</i> ;
    <del>static </del>constexpr error_type error_escape = <i>unspecified</i> ;
    <del>static </del>constexpr error_type error_backref = <i>unspecified</i> ;
    <del>static </del>constexpr error_type error_brack = <i>unspecified</i> ;
    <del>static </del>constexpr error_type error_paren = <i>unspecified</i> ;
    <del>static </del>constexpr error_type error_brace = <i>unspecified</i> ;
    <del>static </del>constexpr error_type error_badbrace = <i>unspecified</i> ;
    <del>static </del>constexpr error_type error_range = <i>unspecified</i> ;
    <del>static </del>constexpr error_type error_space = <i>unspecified</i> ;
    <del>static </del>constexpr error_type error_badrepeat = <i>unspecified</i> ;
    <del>static </del>constexpr error_type error_complexity = <i>unspecified</i> ;
    <del>static </del>constexpr error_type error_stack = <i>unspecified</i> ;
  }
}
</pre></blockquote>
</li>
</ol>





<hr>
<h3><a name="2054"></a>2054. <tt>time_point</tt> constructors need to be <tt>constexpr</tt></h3>
<p><b>Section:</b> 20.11.6 [time.point] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2011-05-13 <b>Last modified:</b> 2011-09-06</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 20.11.6 [time.point], <tt>time_point::min()</tt> and <tt>time_point::max()</tt> 
are listed as <tt>constexpr</tt>. However, <tt>time_point</tt> has no <tt>constexpr</tt> constructors, 
so is not a literal type, and so these functions cannot be <tt>constexpr</tt> without adding a 
<tt>constexpr</tt> constructor for implementation purposes.
<p/>
Proposed resolution: Add <tt>constexpr</tt> to the constructors of <tt>time_point</tt>. The effects of
the constructor template basically imply that the member function <tt>time_since_epoch()</tt> is
intended to be <tt>constexpr</tt> as well.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>Alter the class template definition in 20.11.6 [time.point] as follows:</p>
<blockquote><pre>
template &lt;class Clock, class Duration = typename Clock::duration&gt;
class time_point {
  [&hellip;]
public:
  <i>// 20.11.6.1, construct:</i>
  <ins>constexpr</ins> time_point(); <i>// has value epoch</i>
  <ins>constexpr</ins> explicit time_point(const duration&amp; d); <i>// same as time_point() + d</i>
  template &lt;class Duration2&gt;
    <ins>constexpr</ins> time_point(const time_point&lt;clock, Duration2&gt;&amp; t);

  <i>// 20.11.6.2, observer:</i>
  <ins>constexpr</ins> duration time_since_epoch() const;
  [&hellip;]
};
</pre></blockquote>
</li>

<li><p>Alter the declarations in 20.11.6.1 [time.point.cons]:</p>
<blockquote><pre>
<ins>constexpr</ins> time_point();
</pre><blockquote><p>
-1- <i>Effects</i>: Constructs an object of type <tt>time_point</tt>, initializing <tt>d_</tt> with <tt>duration::zero()</tt>. Such a
<tt>time_point</tt> object represents the epoch.
</p></blockquote></blockquote>
<blockquote><pre>
<ins>constexpr explicit</ins> time_point(const duration&amp; d);
</pre><blockquote><p>
-2- <i>Effects</i>: Constructs an object of type <tt>time_point</tt>, initializing <tt>d_</tt> with <tt>d</tt>. Such a 
<tt>time_point</tt> object represents the epoch <tt>+ d</tt>.
</p></blockquote></blockquote>
<blockquote><pre>
template &lt;class Duration2&gt;
  <ins>constexpr</ins> time_point(const time_point&lt;clock, Duration2&gt;&amp; t);
</pre><blockquote><p>
-3- <i>Remarks</i>: This constructor shall not participate in overload resolution unless <tt>Duration2</tt> is implicitly
convertible to <tt>duration</tt>.
<p/>
-4- <i>Effects</i>: Constructs an object of type <tt>time_point</tt>, initializing <tt>d_</tt> with <tt>t.time_since_epoch()</tt>.
</p></blockquote></blockquote>
</li>

<li><p>Alter the declaration in 20.11.6.2 [time.point.observer]:</p>
<blockquote><pre>
<ins>constexpr</ins> duration time_since_epoch() const;
</pre><blockquote><p>
-1- <i>Returns</i>: d_.
</p></blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="2056"></a>2056. <tt>future_errc</tt> enums start with value 0 (invalid value for <tt>broken_promise</tt>)</h3>
<p><b>Section:</b> 30.6.1 [futures.overview] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2011-05-18 <b>Last modified:</b> 2011-09-06</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 30.6.1 [futures.overview] <tt>enum class future_errc</tt> is defined as follows:
</p><blockquote><pre>
enum class future_errc {
  broken_promise,
  future_already_retrieved,
  promise_already_satisfied,
  no_state
};
</pre></blockquote><p>
With this declaration <tt>broken_promise</tt> has value 0, which means that
for a <tt>future_error f</tt> with this code
</p><blockquote><pre>
f.code().operator bool()
</pre></blockquote><p>
yields false, which makes no sense. 0 has to be reserved for "no error".
So, the enums defined here have to start with 1.
<p/>
Howard, Anthony, and Jonathan have no objections.
</p>
<p>[Discussion in Bloomington 2011-08-16]
</p>
<p>
Previous resolution:
</p>
<blockquote class="note">
<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>In 30.6.1 [futures.overview], header <tt>&lt;future&gt;</tt> synopsis, fix 
the declaration of <tt>future_errc</tt> as follows:</p>
<blockquote><pre>
namespace std {
  enum class future_errc {
    <del>broken_promise,</del>
    future_already_retrieved<ins> = 1</ins>,
    promise_already_satisfied,
    no_state<ins>,
    broken_promise</ins>
  };
  [&hellip;]
}
</pre></blockquote>
</li>
</ol>
</blockquote>
<p>
Is this resolution overspecified? These seem to be all implementation-defined. How do users add new values and not conflict with established error codes?
</p><p>
PJP proxy says: over-specified. boo.
</p><p>
Other error codes: look for is_error_code_enum specializations. Only one exists <tt>io_errc</tt>
</p><p>
Peter: I don't see any other parts of the standard that specify error codes where we have to do something similar.
</p><p>
Suggest that for every place where we add an error code, the following:
</p>
<ol>
   <li> no zero values
   </li><li> all implementation defined values, so future_already_retrieved = implementation_defined
   </li><li> values are distinct
</li></ol>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>
<p>In 30.6.1 [futures.overview], header <tt>&lt;future&gt;</tt> synopsis, fix 
the declaration of <tt>future_errc</tt> as follows:</p>

<blockquote><pre>
namespace std {
  enum class future_errc {
    broken_promise<ins> = <var>implementation defined</var></ins>,
    future_already_retrieved<ins> = <var>implementation defined</var></ins>,
    promise_already_satisfied<ins> = <var>implementation defined</var></ins>,
    no_state<ins> = <var>implementation defined</var></ins>
  };
  [&hellip;]
}
</pre></blockquote>
<p>In 30.6.1 [futures.overview], header <tt>&lt;future&gt;</tt> synopsis, add a paragraph after paragraph 2 as follows:</p>

<ins>The enum values of <tt>future_errc</tt> are distinct and not zero.</ins>




<hr>
<h3><a name="2057"></a>2057. <tt>time_point + duration</tt> semantics should be made <tt>constexpr</tt> conforming</h3>
<p><b>Section:</b> 20.11.6.5 [time.point.nonmember] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-05-21 <b>Last modified:</b> 2011-09-06</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It has been observed by LWG <a href="lwg-active.html#2054">2054</a> that the specification of some <tt>time_point</tt> member functions
already imply that <tt>time_point</tt> needs to be a literal type and suggests to specify the constructors
and the member function <tt>time_since_epoch()</tt> as <tt>constexpr</tt> functions at the
minimum necessary. Adding further <tt>constexpr</tt> specifier to other operations should
clearly be allowed and should probably be done as well. But to allow for further <tt>constexpr</tt> 
functions in the future requires that their semantics is compatible to operations allowed in <tt>constexpr</tt> 
functions. This is already fine for all operations, except this binary plus operator:
</p>
<blockquote><pre>
template &lt;class Clock, class Duration1, class Rep2, class Period2&gt;
time_point&lt;Clock, typename common_type&lt;Duration1, duration&lt;Rep2, Period2&gt;&gt;::type&gt;
operator+(const time_point&lt;Clock, Duration1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
</pre><blockquote><p>
-1- <i>Returns</i>: <tt>CT(lhs) += rhs</tt>, where <tt>CT</tt> is the type of the return value.
</p></blockquote></blockquote>
<p>
for similar reasons as those mentioned in <a href="lwg-defects.html#2020">2020</a>. The semantics should be fixed to allow
for making them <tt>constexpr</tt>. This issue should also be considered as a placeholder for a request
to make the remaining <tt>time_point</tt> operations similarly <tt>constexpr</tt> as had been done for 
<tt>duration</tt>.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>In 20.11.6.5 [time.point.nonmember], p.1 change the <i>Returns</i> element semantics as indicated:</p>
<blockquote><pre>
template &lt;class Clock, class Duration1, class Rep2, class Period2&gt;
time_point&lt;Clock, typename common_type&lt;Duration1, duration&lt;Rep2, Period2&gt;&gt;::type&gt;
operator+(const time_point&lt;Clock, Duration1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
</pre><blockquote><p>
-1- <i>Returns</i>: <tt><del>CT(lhs) += rhs</del><ins>CT(lhs.time_since_epoch() + rhs)</ins></tt>, where <tt>CT</tt> 
is the type of the return value.
</p></blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="2058"></a>2058. <tt>valarray</tt> and <tt>begin&#47;end</tt></h3>
<p><b>Section:</b> 26.6 [numarray] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2011-05-17 <b>Last modified:</b> 2011-09-06</p>
<p><b>View all other</b> <a href="lwg-index.html#numarray">issues</a> in [numarray].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It was just brought to my attention that the pair of functions
<tt>begin&#47;end</tt> were added to <tt>valarray</tt> component.
Those additions strike me as counter to the long standing agreement
that <tt>valarray&lt;T&gt;</tt> is not yet another container. Valarray values
are in general supposed to be treated as a whole, and as such
has a loose specification allowing expression template techniques.
<p/>
The addition of these functions sound to me as making it much harder
(or close to impossible) to effectively use expression templates
as implementation techniques, for no clear benefits.
<p/>
My recommendation would be to drop <tt>begin&#47;end</tt> - or at least for the
<tt>const valarray&lt;T&gt;&amp;</tt> version. I strongly believe those 
are defects.
</p>
<p><i>[This issue was discussed on the library reflector starting from c++std-lib-30761.
Some of the key conclusions of this discussion were:]</i></p>

<ol>
<li>The <tt>begin&#47;end</tt> members were added to allow <tt>valarray</tt> to participate
in the new range-based for-loop by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2930.html">n2930</a>
and not to make them container-like.</li>
<li>It is currently underspecified when the iterator values returned from
<tt>begin&#47;end</tt> become invalidated. To fix this, these invalidation rules need at
least to reflect the invalidation rules of the references returned by the
<tt>operator[]</tt> overloads of <tt>valarray</tt> (26.6.2.4 [valarray.access]).
</li>
<li>A further problem is that the requirements expressed in 26.6.1 [valarray.syn] p.3-5
enforce an implementation to provide further overloads of <tt>begin&#47;end</tt>, if the
replacement type technique is used (which was clearly part of the design of <tt>valarray</tt>).
Providing such additional overloads would also lead to life-time problems in examples like 
<tt>begin(x + y)</tt> where <tt>x</tt> and <tt>y</tt> are expressions involving <tt>valarray</tt> 
objects. To fix this, the <tt>begin&#47;end</tt> overloads could be explicitly excluded from the 
general statements of 26.6.1 [valarray.syn] p.3-5. This would make it unspecified
whether the expression <tt>begin(x + y)</tt> would be well-formed, portable code would
need to write this as <tt>begin(std::valarray&lt;T&gt;(x + y))</tt>.</li>
</ol>

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


<p>
The intent of these overloads is entirely to support the new for syntax, and not to create
new containers.
</p>

<p>
Stefanus provides suggested wording.
</p>



<p><b>Proposed resolution:</b></p>
<p>
In 26.6.1 [valarray.syn]/4, make the following <ins>insertion</ins>:
</p>

<p>
4 Implementations introducing such replacement types shall provide additional functions and operators as
follows:
</p>
<p>
— for every function taking a <tt>const valarray&lt;T>&amp;</tt> <ins>other than <tt>begin</tt> and <tt>end</tt>
(26.6.10 [valarray.range])</ins>, identical functions taking the replacement types shall be added;
</p>
<p>
— for every function taking two <tt>const valarray&lt;T>&amp;</tt> arguments, identical functions taking every combination
of <tt>const valarray&lt;T>&amp;</tt> and replacement types shall be added.
</p>

<p>
In 26.6.10 [valarray.range], make the following <ins>insertion</ins>:
</p>
<p> 
1 In the <tt>begin</tt> and <tt>end</tt> function templates that follow, <i>unspecified</i>1 is a type that meets
the requirements of a mutable random access iterator (24.2.7) whose <tt>value_type</tt> is the template parameter
<tt>T</tt> and whose <tt>reference</tt> type is <tt>T&amp;</tt>. <i>unspecified</i>2 is a type that meets the
requirements of a constant random access iterator (24.2.7) whose <tt>value_type</tt> is the template parameter
<tt>T</tt> and whose <tt>reference</tt> type is <tt>const T&amp;</tt>.
</p>
<p><ins>
2 The iterators  returned by <tt>begin</tt> and <tt>end</tt> for an array are guaranteed to be valid until the
member function <tt>resize(size_t, T)</tt> (26.6.2.8 [valarray.members]) is called for that array or until
the lifetime of that array ends, whichever happens first.
</ins></p>





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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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





<hr>
<h3><a name="2061"></a>2061. <tt>make_move_iterator</tt> and arrays</h3>
<p><b>Section:</b> 24.3 [iterator.synopsis], 24.5.3 [move.iterators] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Marc Glisse <b>Opened:</b> 2011-05-28 <b>Last modified:</b> 2011-09-06</p>
<p><b>View all other</b> <a href="lwg-index.html#iterator.synopsis">issues</a> in [iterator.synopsis].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The standard library always passes template iterators by value and never by reference, 
which has the nice effect that an array decays to a pointer. There is one exception: 
<tt>make_move_iterator</tt>.
</p>
<blockquote><pre>
#include &lt;iterator&gt;
int main(){
  int a[]={1,2,3,4};
  std::make_move_iterator(a+4);
  std::make_move_iterator(a); // fails here
}
</pre></blockquote>

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


<p>
Move to Ready.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>Modify the header <tt>&lt;iterator&gt;</tt> synopsis in 24.3 [iterator.synopsis]:</p>
<blockquote><pre>
namespace std {
  [&hellip;]
  template &lt;class Iterator&gt;
  move_iterator&lt;Iterator&gt; make_move_iterator(<del>const Iterator&amp;</del><ins>Iterator</ins> i);

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

<li><p>Modify the class template <tt>move_iterator</tt> synopsis in 24.5.3.1 [move.iterator]:</p>
<blockquote><pre>
namespace std {
  [&hellip;]
  template &lt;class Iterator&gt;
  move_iterator&lt;Iterator&gt; make_move_iterator(<del>const Iterator&amp;</del><ins>Iterator</ins> i);
}
</pre></blockquote>
</li>

<li><p>Modify 24.5.3.3.14 [move.iter.nonmember]:</p>
<blockquote><pre>
template &lt;class Iterator&gt;
move_iterator&lt;Iterator&gt; make_move_iterator(<del>const Iterator&amp;</del><ins>Iterator</ins> i);
</pre><blockquote><p>
-3- <i>Returns</i>: <tt>move_iterator&lt;Iterator&gt;(i)</tt>.
</p></blockquote></blockquote>
</li>
</ol>





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

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

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

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

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

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

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

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

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

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

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

</ol>



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





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

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


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

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


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

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

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

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

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

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

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

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

</li>
</ol>


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





<hr>
<h3><a name="2064"></a>2064. More <tt>noexcept</tt> issues in <tt>basic_string</tt></h3>
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2011-05-29 <b>Last modified:</b> 2011-09-06</p>
<p><b>View other</b> <a href="lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
<p><b>View all other</b> <a href="lwg-index.html#basic.string">issues</a> in [basic.string].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The following inconsistencies regarding <tt>noexcept</tt> for <tt>basic_string</tt> are noted.
<p/>
Member swap is not marked <tt>noexcept</tt>:
</p><blockquote><pre>
void swap(basic_string&amp; str);
</pre></blockquote><p>
But the global swap is marked <tt>noexcept</tt>:
</p><blockquote><pre>
template&lt;class charT, class traits, class Allocator&gt;
void swap(basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
          basic_string&lt;charT,traits,Allocator&gt;&amp; rhs) <span style="color:#C80000;font-weight:bolder">noexcept</span>;
</pre></blockquote><p>
But only in the definition, not in the synopsis.
<p/>
All comparison operators are marked <tt>noexcept</tt> in their definitions, but not in the synopsis.
<p/>
The compare function that takes a pointer:
</p><blockquote><pre>
int compare(const charT *s) const;
</pre></blockquote><p>
is not marked <tt>noexcept</tt>. But some of the comparison functions which are marked <tt>noexcept</tt> 
(only in their definition) are specified to call the throwing compare operator:
</p><blockquote><pre>
template&lt;class charT, class traits, class Allocator&gt;
bool operator==(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
                const charT* rhs) <span style="color:#C80000;font-weight:bolder">noexcept</span>;
</pre><blockquote><p>
<i>Returns</i>: <tt>lhs.compare(rhs) == 0</tt>.
</p></blockquote></blockquote>
<p>
All functions with a narrow contract should not be declared as <tt>noexcept</tt> according to
the guidelines presented in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf">n3279</a>.
Among these narrow contract functions are the <tt>swap</tt> functions (23.2.1 [container.requirements.general] p. 8) 
and functions with non-<tt>NULL</tt> <tt>const charT*</tt> parameters.
</p>
<p><i>[2011-06-08 Daniel provides wording]</i></p>


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

<p>
Move to Ready
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS. Both move-assignment operator and the moving <tt>assign</tt>
function are not touched by this issue, because they are handled separately by issue <a href="lwg-active.html#2063">2063</a>.</p>
<ol>
<li><p>Modify the header <tt>&lt;string&gt;</tt> synopsis in 21.3 [string.classes] as 
indicated (Rationale: Adding <tt>noexcept</tt> to these specific overloads is in sync with
applying the same rule to specific overloads of the member functions <tt>find</tt>, <tt>compare</tt>, etc.
This approach deviates from that taken in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf">n3279</a>,
but seems more consistent given similar application for comparable member functions):</p>

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

namespace std {

  [&hellip;]
  template&lt;class charT, class traits, class Allocator&gt;
    bool operator==(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
                    const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs) <ins>noexcept</ins>;
  [&hellip;]
  template&lt;class charT, class traits, class Allocator&gt;
    bool operator!=(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
                    const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs) <ins>noexcept</ins>;
  [&hellip;]

  template&lt;class charT, class traits, class Allocator&gt;
    bool operator&lt;(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
                   const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs) <ins>noexcept</ins>;
  [&hellip;]
  template&lt;class charT, class traits, class Allocator&gt;
    bool operator&gt;(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
                   const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs) <ins>noexcept</ins>;
  [&hellip;]

  template&lt;class charT, class traits, class Allocator&gt;
    bool operator&lt;=(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
                    const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs) <ins>noexcept</ins>;
  [&hellip;]
  template&lt;class charT, class traits, class Allocator&gt;
    bool operator&gt;=(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
                    const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs) <ins>noexcept</ins>;
  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Modify the class template <tt>basic_string</tt> synopsis in 21.4 [basic.string] as 
indicated (Remark 1: The <tt>noexcept</tt> at the move-constructor is fine, because even for a
small-object optimization there is no problem here, because <tt>basic_string::value_type</tt>
is required to be a non-array POD as of 21.1 [strings.general] p1, Remark 2: This
proposal removes the <tt>noexcept</tt> at single character overloads of <tt>find</tt>, <tt>rfind</tt>,
etc. because they are defined in terms of potentially allocating functions. It seems like
an additional issue to me to change the semantics in terms of non-allocating functions and
adding <tt>noexcept</tt> instead):</p>

<blockquote><pre>
namespace std {
  template&lt;class charT, class traits = char_traits&lt;charT&gt;,
    class Allocator = allocator&lt;charT&gt; &gt;
  class basic_string {
  public:
    [&hellip;]
    <i>// [string.ops], string operations:</i>
    [&hellip;]
    size_type find (charT c, size_type pos = 0) const <del>noexcept</del>;
    [&hellip;]
    size_type rfind(charT c, size_type pos = npos) const <del>noexcept</del>;
    [&hellip;]
    size_type find_first_of(charT c, size_type pos = 0) const <del>noexcept</del>;
    [&hellip;]
    size_type find_last_of (charT c, size_type pos = npos) const <del>noexcept</del>;
    [&hellip;]
    size_type find_first_not_of(charT c, size_type pos = 0) const <del>noexcept</del>;
    [&hellip;]
    size_type find_last_not_of (charT c, size_type pos = npos) const <del>noexcept</del>;
    [&hellip;]
  };
}
</pre></blockquote>

</li>

<li><p>Modify 21.4.7.2 [string::find] before p5 and before p7 as indicated:</p>

<blockquote><pre>
size_type find(const charT* s, size_type pos = 0) const <del>noexcept</del>;
[&hellip;]
size_type find(charT c, size_type pos = 0) const <del>noexcept</del>;
</pre><blockquote><p>
-7- <i>Returns</i>: <tt>find(basic_string&lt;charT,traits,Allocator&gt;(1,c), pos)</tt>.
</p></blockquote></blockquote>

</li>

<li><p>Modify 21.4.7.3 [string::rfind] before p7 as indicated:</p>

<blockquote><pre>
size_type rfind(charT c, size_type pos = npos) const <del>noexcept</del>;
</pre><blockquote><p>
-7- <i>Returns</i>: <tt>rfind(basic_string&lt;charT,traits,Allocator&gt;(1,c),pos)</tt>.
</p></blockquote></blockquote>

</li>

<li><p>Modify 21.4.7.4 [string::find.first.of] before p7 as indicated:</p>

<blockquote><pre>
size_type find_first_of(charT c, size_type pos = 0) const <del>noexcept</del>;
</pre><blockquote><p>
-7- <i>Returns</i>: <tt>find_first_of(basic_string&lt;charT,traits,Allocator&gt;(1,c), pos)</tt>.
</p></blockquote></blockquote>

</li>

<li><p>Modify 21.4.7.5 [string::find.last.of] before p7 as indicated:</p>

<blockquote><pre>
size_type find_last_of(charT c, size_type pos = npos) const <del>noexcept</del>;
</pre><blockquote><p>
-7- <i>Returns</i>: <tt>find_last_of(basic_string&lt;charT,traits,Allocator&gt;(1,c),pos)</tt>.
</p></blockquote></blockquote>

</li>

<li><p>Modify 21.4.7.6 [string::find.first.not.of] before p7 as indicated:</p>

<blockquote><pre>
size_type find_first_not_of(charT c, size_type pos = 0) const <del>noexcept</del>;
</pre><blockquote><p>
-7- <i>Returns</i>: <tt>find_first_not_of(basic_string(1, c), pos)</tt>.
</p></blockquote></blockquote>

</li>

<li><p>Modify 21.4.7.7 [string::find.last.not.of] before p7 as indicated:</p>

<blockquote><pre>
size_type find_last_not_of(charT c, size_type pos = npos) const <del>noexcept</del>;
</pre><blockquote><p>
-7- <i>Returns</i>: <tt>find_last_not_of(basic_string(1, c), pos)</tt>.
</p></blockquote></blockquote>

</li>

<li><p>Modify 21.4.8.2 [string::operator==] before p2+p3 as indicated:</p>

<blockquote><pre>
template&lt;class charT, class traits, class Allocator&gt;
bool operator==(const charT* lhs,
                const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs) <del>noexcept</del>;

[&hellip;]
				
template&lt;class charT, class traits, class Allocator&gt;
bool operator==(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
                const charT* rhs) <del>noexcept</del>;
</pre></blockquote>

</li>

<li><p>Modify 21.4.8.3 [string::op!=] before p2+p3 as indicated:</p>

<blockquote><pre>
template&lt;class charT, class traits, class Allocator&gt;
bool operator!=(const charT* lhs,
                const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs) <del>noexcept</del>;

[&hellip;]
				
template&lt;class charT, class traits, class Allocator&gt;
bool operator!=(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
                const charT* rhs) <del>noexcept</del>;
</pre></blockquote>

</li>

<li><p>Modify 21.4.8.4 [string::op&lt;] before p2+p3 as indicated:</p>

<blockquote><pre>
template&lt;class charT, class traits, class Allocator&gt;
bool operator&lt;(const charT* lhs,
               const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs) <del>noexcept</del>;

[&hellip;]
				
template&lt;class charT, class traits, class Allocator&gt;
bool operator&lt;(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
               const charT* rhs) <del>noexcept</del>;
</pre></blockquote>

</li>

<li><p>Modify 21.4.8.5 [string::op&gt;] before p2+p3 as indicated:</p>

<blockquote><pre>
template&lt;class charT, class traits, class Allocator&gt;
bool operator&gt;(const charT* lhs,
               const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs) <del>noexcept</del>;

[&hellip;]
				
template&lt;class charT, class traits, class Allocator&gt;
bool operator&gt;(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
               const charT* rhs) <del>noexcept</del>;
</pre></blockquote>

</li>

<li><p>Modify 21.4.8.6 [string::op&lt;=] before p2+p3 as indicated:</p>

<blockquote><pre>
template&lt;class charT, class traits, class Allocator&gt;
bool operator&lt;=(const charT* lhs,
                const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs) <del>noexcept</del>;

[&hellip;]
				
template&lt;class charT, class traits, class Allocator&gt;
bool operator&lt;=(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
                const charT* rhs) <del>noexcept</del>;
</pre></blockquote>

</li>

<li><p>Modify 21.4.8.7 [string::op&gt;=] before p2+p3 as indicated:</p>

<blockquote><pre>
template&lt;class charT, class traits, class Allocator&gt;
bool operator&gt;=(const charT* lhs,
                const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs) <del>noexcept</del>;

[&hellip;]
				
template&lt;class charT, class traits, class Allocator&gt;
bool operator&gt;=(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
                const charT* rhs) <del>noexcept</del>;
</pre></blockquote>

</li>

<li><p>Modify 21.4.8.8 [string.special] as indicated (Remark: The change of
the semantics guarantees as of 17.5.1.4 [structure.specifications] p4 that 
the "Throws: Nothing" element of member swap is implied):</p>

<blockquote><pre>
template&lt;class charT, class traits, class Allocator&gt;
  void swap(basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
    basic_string&lt;charT,traits,Allocator&gt;&amp; rhs) <del>noexcept</del>;
</pre><blockquote><p>
-1- Effects: <ins>Equivalent to</ins> <tt>lhs.swap(rhs);</tt>
</p></blockquote></blockquote>

</li>
</ol>





<hr>
<h3><a name="2065"></a>2065. Minimal allocator interface</h3>
<p><b>Section:</b> 17.6.3.5 [allocator.requirements] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-06-06 <b>Last modified:</b> 2011-09-06</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The example in 17.6.3.5 [allocator.requirements] says <tt>SimpleAllocator</tt> satisfies
the requirements of Table 28 &mdash; Allocator requirements, but it doesn't support comparison 
for equality&#47;inequality.
</p>

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

<p>
Move to Ready
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>Modify the example in 17.6.3.5 [allocator.requirements] p5 as indicated:</p>
<blockquote><p>
-5- [&hellip;]
<p/>
[ <i>Example</i>: the following is an allocator class template supporting the minimal interface 
that satisfies the requirements of Table 28:
</p><blockquote><pre>
template &lt;class Tp&gt;
struct SimpleAllocator {
  typedef Tp value_type;
  SimpleAllocator(<i>ctor args</i>);
  template &lt;class T&gt; SimpleAllocator(const SimpleAllocator&lt;T&gt;&amp; other);
  Tp *allocate(std::size_t n);
  void deallocate(Tp *p, std::size_t n);
};

<ins>template &lt;class T, class U&gt;
bool operator==(const SimpleAllocator&lt;T&gt;&amp;, const SimpleAllocator&lt;U&gt;&amp;);
template &lt;class T, class U&gt;
bool operator!=(const SimpleAllocator&lt;T&gt;&amp;, const SimpleAllocator&lt;U&gt;&amp;);</ins>
</pre></blockquote><p>
&mdash; <i>end example</i> ]
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="2066"></a>2066. Missing specification of <tt>vector::resize(size_type)</tt></h3>
<p><b>Section:</b> 23.3.6.3 [vector.capacity] <b>Status:</b> <a href="lwg-active.html#Resolved">Tentatively Resolved</a>
 <b>Submitter:</b> Rani Sharoni <b>Opened:</b> 2011-03-29 <b>Last modified:</b> 2011-09-06</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>Discussion:</b></p>
<p>
In C++1x (N3090) there are two version of <tt>vector::resize</tt> &mdash; 23.3.6.3 [vector.capacity]:
</p>
<blockquote><pre>
void resize(size_type sz);
void resize(size_type sz, const T&amp; c);
</pre></blockquote>
<p>
The text in 23.3.6.3 [vector.capacity]&#47;12 only mentions "no effects on throw" for the
two args version of resize:
</p><blockquote><p>
<i>Requires</i>: If an exception is thrown other than by the move constructor
of a non-<tt>CopyConstructible</tt> <tt>T</tt> there are no effects.
</p></blockquote><p>
This seems like unintentional oversight since <tt>resize(size)</tt> is
semantically the same as <tt>resize(size, T())</tt>.
Additionally, the C++03 standard only specify single version of resize
with default for the second argument - 23.2.4:
</p>
<blockquote><pre>
void resize(size_type sz, T c = T());
</pre></blockquote>
<p>
Therefore not requiring same guarantees for both version of resize is
in fact a regression.
</p>

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


<p>The proposed resolution for issue <a href="lwg-active.html#2033">2033</a> should solve this issue as well.</p>

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


<p>
This issue will be resolved by issue <a href="lwg-active.html#2033">2033</a>, and closed when this issue is applied. 
</p>



<p><b>Proposed resolution:</b></p>
<p>Apply the proposed resolution of issue <a href="lwg-active.html#2033">2033</a></p>





<hr>
<h3><a name="2067"></a>2067. <tt>packaged_task</tt> should have deleted copy c'tor with const parameter</h3>
<p><b>Section:</b> 30.6.9 [futures.task] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-06-16 <b>Last modified:</b> 2011-09-06</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#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Class template <tt>packaged_task</tt> is a move-only type with the following form of the
deleted copy operations:
</p>
<blockquote><pre>
packaged_task(packaged_task&amp;) = delete;
packaged_task&amp; operator=(packaged_task&amp;) = delete;
</pre></blockquote>
<p>
Note that the argument types are non-const. This does not look like a typo to me,
this form seems to exist from the very first proposing paper on 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2276.html">N2276</a>.
Using either of form of the copy-constructor did not make much difference before the 
introduction of defaulted special member functions, but it makes now an observable 
difference. This was brought to my attention by a question on a German C++ newsgroup 
where the question was raised why the following code does not compile on a recent
gcc:
</p>
<blockquote><pre>
#include &lt;utility&gt;
#include &lt;future&gt;
#include &lt;iostream&gt;
#include &lt;thread&gt;

int main(){
  std::packaged_task&lt;void()&gt; someTask([]{ std::cout &lt;&lt; std::this_thread::get_id() &lt;&lt; std::endl; });
  std::thread someThread(std::move(someTask)); // <span style="color:#C80000">Error here</span>
  // Remainder omitted
}
</pre></blockquote>
<p>
It turned out that the error was produced by the instantiation of some return type
of <tt>std::bind</tt> which used a defaulted copy-constructor, which leads to a
const declaration conflict with [class.copy] p8.
<p/>
Some aspects of this problem are possibly core-language related, but I consider it
more than a service to programmers, if the library would declare the usual form of
the copy operations (i.e. those with const first parameter type) as deleted for
<tt>packaged_task</tt> to prevent such problems.
<p/>
A similar problem exists for class template <tt>basic_ostream</tt> in 27.7.3.1 [ostream]:
</p>
<blockquote><pre>
namespace std {
  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
  class basic_ostream : virtual public basic_ios&lt;charT,traits&gt; {
    [&hellip;]

    // 27.7.3.3 Assign/swap
    basic_ostream&amp; operator=(basic_ostream&amp; rhs) = delete;
    basic_ostream&amp; operator=(const basic_ostream&amp;&amp; rhs);
    void swap(basic_ostream&amp; rhs);
};
</pre></blockquote>
<p>
albeit this could be considered as an editorial swap of copy and move
assignment operator, I suggest to fix this as part of this issue as well.
</p>

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


<p>
Move to Ready.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>Modify the class template <tt>basic_ostream</tt> synopsis in 27.7.3.1 [ostream]
as indicated (Note: The prototype signature of the move assignment operator in 27.7.3.3 [ostream.assign]
is fine):</p>

<blockquote><pre>
namespace std {
  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
  class basic_ostream : virtual public basic_ios&lt;charT,traits&gt; {
    [&hellip;]

    // 27.7.3.3 Assign/swap
    basic_ostream&amp; operator=(<ins>const</ins> basic_ostream&amp; rhs) = delete;
    basic_ostream&amp; operator=(<del>const</del> basic_ostream&amp;&amp; rhs);
    void swap(basic_ostream&amp; rhs);
};
</pre></blockquote>
</li>

<li><p>Modify the class template <tt>packaged_task</tt> synopsis in 30.6.9 [futures.task] p2
as indicated:</p>

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

  template&lt;class R, class... ArgTypes&gt;
  class packaged_task&lt;R(ArgTypes...)&gt; {
  public:
    [&hellip;]
  
    <i>// no copy</i>
    packaged_task(<ins>const</ins> packaged_task&amp;) = delete;
    packaged_task&amp; operator=(<ins>const</ins> packaged_task&amp;) = delete;
    
    [&hellip;]
  };
  [&hellip;]
}
</pre></blockquote>
</li>
</ol>





<hr>
<h3><a name="2069"></a>2069. Inconsistent exception spec for <tt>basic_string</tt> move constructor</h3>
<p><b>Section:</b> 21.4.2 [string.cons] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2011-07-01 <b>Last modified:</b> 2011-09-06</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Sub-clause 21.4.2 [string.cons] contains these constructors in paragraphs 2 and 3:
</p>
<blockquote><pre>
basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
basic_string(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; str) noexcept;
</pre><blockquote>
<p>
[&hellip;]
<p/>
-3- <i>Throws</i>: The second form throws nothing if the allocator's move constructor throws nothing.
</p></blockquote></blockquote>
<p>
How can it <i>ever</i> throw anything if it is marked <tt>noexcept</tt>?
</p>
<p><i>[2011-07-11: Daniel comments and suggests wording changes]</i></p>

<p>
Further, according to paragraph 18 of the same sub-clause:
</p>
<blockquote><pre>
basic_string(const basic_string&amp; str, const Allocator&amp; alloc);
basic_string(basic_string&amp;&amp; str, const Allocator&amp; alloc);
</pre><blockquote>
<p>
[&hellip;]
<p/>
-18- <i>Throws</i>: The second form throws nothing if <tt>alloc == str.get_allocator()</tt> 
unless the copy constructor for <tt>Allocator</tt> throws.
</p>
</blockquote></blockquote>
<p>
The constraint &quot;unless the copy constructor for <tt>Allocator</tt> throws&quot;
is redundant, because according to Table 28 &mdash; Allocator requirements, the expressions
</p>
<blockquote><pre>
X a1(a);
X a(b);
</pre></blockquote>
<p>
impose the requirement: &quot;Shall not exit via an exception&quot;.
</p>

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


<p>
Move to Ready.
</p>



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

<ol>
<li><p>Change 21.4.2 [string.cons] p3 as indicated (This move constructor has a wide
contract and is therefore safely marked as <tt>noexcept</tt>):</p>

<blockquote><pre>
basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
basic_string(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; str) noexcept;
</pre><blockquote>
<p>
-2- <i>Effects</i>: Constructs an object of class <tt>basic_string</tt> as indicated in Table 64. 
In the second form, <tt>str</tt> is left in a valid state with an unspecified value.
<p/>
<del>-3- <i>Throws</i>: The second form throws nothing if the allocator's move constructor throws nothing.</del>
</p>
</blockquote></blockquote>
</li>

<li><p>Change 21.4.2 [string.cons] p18 as indicated (This move-like constructor may throw,
if the allocators don't compare equal, but not because of a potentially throwing allocator
copy constructor, only because the allocation attempt may fail and throw an exception):</p>

<blockquote><pre>
basic_string(const basic_string&amp; str, const Allocator&amp; alloc);
basic_string(basic_string&amp;&amp; str, const Allocator&amp; alloc);
</pre><blockquote>
<p>
[&hellip;]
<p/>
-18- <i>Throws</i>: The second form throws nothing if <tt>alloc == str.get_allocator()</tt> 
<del>unless the copy constructor for <tt>Allocator</tt> throws</del>.
</p>
</blockquote></blockquote>
</li>

</ol>






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

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

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

<p><strong>Daniel's (old) proposed resolution</strong></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li>Change the following paragraphs of 20.7.2.2.6 [util.smartptr.shared.create] as indicated (The suggested
removal of the last sentence of p1 is not strictly required to resolve this issue, but is still recommended,
because it does not say anything new but may give the impression that it says something new):</li>

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

</ol>



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

<ol>
<li>Change the following paragraphs of 20.7.2.2.6 [util.smartptr.shared.create] as indicated (The suggested
removal of the last sentence of p1 is not strictly required to resolve this issue, but is still recommended,
because it does not say anything new but may give the impression that it says something new):</li>

<blockquote><pre>
template&lt;class T, class... Args&gt; shared_ptr&lt;T&gt; make_shared(Args&amp;&amp;... args);
<del>template&lt;class T, class A, class... Args&gt;

  shared_ptr&lt;T&gt; allocate_shared(const A&amp; a, Args&amp;&amp;... args);</del>
</pre></blockquote>
<p>
-1- <i>Requires</i>: The expression 
<tt>::new (pv) T(std::forward&lt;Args&gt;(args)...)</tt>, where <tt>pv</tt> 

has type <tt>void*</tt> and points to storage suitable to hold an object of type <tt>T</tt>, shall be well 
formed. <del><tt>A</tt> shall be an allocator ([allocator.requirements]). 
The copy constructor and destructor of  <tt>A</tt> shall not throw exceptions.</del>
<p/>
-2- <i>Effects</i>: Allocates memory suitable for an object of type <tt>T</tt> and constructs an object in 
that memory via the placement new expression 

<tt>::new (pv) T(std::forward&lt;Args&gt;(args)...)</tt>. <del>The template <tt>allocate_shared</tt> uses a copy 
of <tt>a</tt> to allocate memory.</del>
If an exception is thrown, the function<del>s have</del><ins> has</ins> no effect.

<p/>
-3- <i>Returns</i>: A <tt>shared_ptr</tt> instance that stores and owns the address of the newly constructed 
object of type <tt>T</tt>.
<p/>
-4- <i>Postconditions</i>: <tt>get() != 0 &amp;&amp; use_count() == 1</tt>

<p/>
-5- <i>Throws</i>: <tt>bad_alloc</tt>, or an exception thrown from 
<del><tt>A::allocate</tt> or from</del> the constructor of 
<tt>T</tt>>.
<p/>
-6- <i>Remarks</i>: Implementations are encouraged, but not required, to perform no more than one memory
allocation. [ <i>Note</i>: <del>This</del><ins>Such an implementation</ins>

provides efficiency equivalent to an intrusive smart pointer. &mdash; <i>end note</i> ]
<p/>
-7- [ <i>Note</i>: <del>These functions</del><ins>This function</ins> will typically allocate more memory than <tt>sizeof(T)</tt> to allow for internal
bookkeeping structures such as the reference counts. &mdash; <i>end note</i> ]

</p>
<li>Add the following <ins>new paragraph</ins>:</li>
<blockquote><pre>
template&lt;class T, class A, class... Args&gt;
  shared_ptr&lt;T&gt; allocate_shared(const A&amp; a, Args&amp;&amp;... args);

</pre></blockquote>
<p>
-1- <i>Requires</i>: The expression 
<tt>allocator_traits&lt;A&gt;::construct(a, pt, std::forward&lt;Args&gt;(args)...)</tt>, shall be well formed,
where <tt>pt</tt> has type <tt>T*</tt> and points to storage suitable to hold an object
of type <tt>T</tt>. <tt>A</tt> shall be an allocator ([allocator.requirements]). 

<p/>
-2- <i>Effects</i>: Allocates memory suitable for an object of type <tt>T</tt> and constructs an object in 
that memory. Using a suitably-rebound version <tt>A</tt>, <tt>A2</tt>,
allocates memory from a copy of <tt>a</tt> by calling
<tt>allocator_traits&lt;A2&gt;::allocate(a, 1)</tt>

 and constructs the object by calling 
<tt>allocator_traits&lt;A2&gt;::construct(a, pt,
std::forward&lt;Args&gt;(args)...)</tt>. If an exception is thrown, the
function has no effect.
<p/>
-3- <i>Returns</i>: A <tt>shared_ptr</tt> instance that stores and owns the address of the newly constructed 
object of type <tt>T</tt>.

<p/>
-4- <i>Postconditions</i>: <tt>get() != 0 &amp;&amp; use_count() == 1</tt>
<p/>
-5- <i>Throws</i>: nothing unless <tt>allocator_traits&lt;A&gt;::allocate</tt>
or <tt>allocator_traits&lt;A&gt;::construct</tt> throws an exception.

<p/>
-6- <i>Remarks</i>: Implementations are encouraged, but not required, to
perform no more than one memory allocation. 
[ <i>Note</i>: Such an implementation provides efficiency equivalent to an intrusive smart pointer. &mdash; <i>end note</i> ]
<p/>
-7- [ <i>Note</i>: These functions will typically allocate more memory than <tt>sizeof(T)</tt> to allow for internal
bookkeeping structures such as the reference counts. &mdash; <i>end note</i> ]

</p>

</ol>





</body>
</html>
