<!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">N3133=10-0123</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left">2010-08-25</td>
</tr>
<tr>
<td align="left">Project:</td>
<td align="left">Programming Language C++</td>
</tr>
<tr>
<td align="left">Reply to:</td>
<td align="left">Alisdair Meredith &lt;<a href="mailto:wg21@alisdairm.net">wg21@alisdairm.net</a>&gt;</td>
</tr>
</table>
<h1>C++ Standard Library Active Issues List (Revision R71)</h1>

  <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 ANSI
  (J16) 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 type="A">
<a name="submit_issue_A"></a><li>
Mail your issue to the author of this list.
</li>
<a name="submit_issue_B"></a><li>
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>
<a name="submit_issue_C"></a><li>
If the "From" on your email is not the name you wish to appear as issue submitter,
then specify issue submitter.
</li>
<a name="submit_issue_D"></a><li>
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>
<a name="submit_issue_E"></a><li>
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>
<a name="submit_issue_F"></a><li>
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>
<a name="submit_issue_G"></a><li>
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>
<a name="submit_issue_H"></a><li>
It is not necessary for you to specify open date or last modified date (the date
of your mail will be used).
</li>
<a name="submit_issue_I"></a><li>
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>
<a name="submit_issue_J"></a><li>
One issue per email is best.
</li>
<a name="submit_issue_K"></a><li>
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>D71: 
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-active.html#1335">1335</a>, <a href="lwg-active.html#1336">1336</a>, <a href="lwg-active.html#1337">1337</a>, <a href="lwg-active.html#1338">1338</a>, <a href="lwg-active.html#1339">1339</a>, <a href="lwg-active.html#1340">1340</a>, <a href="lwg-active.html#1341">1341</a>, <a href="lwg-active.html#1342">1342</a>, <a href="lwg-active.html#1343">1343</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-closed.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-active.html#951">951</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-active.html#868">868</a>.</li>
<li>Changed the following issues from New to Tentatively NAD: <a href="lwg-active.html#1190">1190</a>, <a href="lwg-active.html#1200">1200</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Future: <a href="lwg-active.html#1188">1188</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Future: <a href="lwg-active.html#1173">1173</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-active.html#1198">1198</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-active.html#1171">1171</a>, <a href="lwg-active.html#1191">1191</a>, <a href="lwg-active.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-closed.html#1321">1321</a>, <a href="lwg-closed.html#1329">1329</a>.</li>
<li>Added the following New issues: <a href="lwg-active.html#1319">1319</a>, <a href="lwg-active.html#1320">1320</a>, <a href="lwg-active.html#1322">1322</a>, <a href="lwg-active.html#1323">1323</a>, <a href="lwg-active.html#1324">1324</a>, <a href="lwg-active.html#1325">1325</a>, <a href="lwg-active.html#1326">1326</a>, <a href="lwg-active.html#1328">1328</a>, <a href="lwg-active.html#1330">1330</a>, <a href="lwg-active.html#1331">1331</a>, <a href="lwg-active.html#1332">1332</a>, <a href="lwg-active.html#1333">1333</a>, <a href="lwg-active.html#1334">1334</a>.</li>
<li>Added the following Open issues: <a href="lwg-active.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-closed.html#1185">1185</a>, <a href="lwg-closed.html#1210">1210</a>, <a href="lwg-closed.html#1212">1212</a>, <a href="lwg-closed.html#1225">1225</a>, <a href="lwg-closed.html#1244">1244</a>, <a href="lwg-closed.html#1266">1266</a>, <a href="lwg-closed.html#1269">1269</a>, <a href="lwg-closed.html#1272">1272</a>, <a href="lwg-closed.html#1275">1275</a>, <a href="lwg-closed.html#1291">1291</a>, <a href="lwg-closed.html#1305">1305</a>, <a href="lwg-closed.html#1307">1307</a>, <a href="lwg-closed.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-closed.html#594">594</a>, <a href="lwg-closed.html#625">625</a>, <a href="lwg-closed.html#742">742</a>, <a href="lwg-closed.html#834">834</a>, <a href="lwg-closed.html#915">915</a>, <a href="lwg-closed.html#1093">1093</a>, <a href="lwg-closed.html#1151">1151</a>, <a href="lwg-closed.html#1211">1211</a>, <a href="lwg-closed.html#1248">1248</a>.</li>
<li>Changed the following issues from Ready to NAD Editorial: <a href="lwg-closed.html#485">485</a>, <a href="lwg-closed.html#932">932</a>, <a href="lwg-closed.html#940">940</a>, <a href="lwg-closed.html#950">950</a>, <a href="lwg-closed.html#983">983</a>, <a href="lwg-closed.html#1100">1100</a>, <a href="lwg-closed.html#1135">1135</a>.</li>
<li>Changed the following issues from Tentatively NAD Editorial to NAD Editorial: <a href="lwg-closed.html#815">815</a>, <a href="lwg-closed.html#816">816</a>, <a href="lwg-closed.html#889">889</a>, <a href="lwg-closed.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-closed.html#1258">1258</a>, <a href="lwg-closed.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-closed.html#1090">1090</a>, <a href="lwg-closed.html#1226">1226</a>, <a href="lwg-closed.html#1273">1273</a>, <a href="lwg-closed.html#1274">1274</a>, <a href="lwg-closed.html#1293">1293</a>, <a href="lwg-closed.html#1300">1300</a>, <a href="lwg-closed.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-active.html#1234">1234</a>, <a href="lwg-active.html#1268">1268</a>.</li>
<li>Changed the following issues from Tentatively Ready to Open: <a href="lwg-active.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-active.html#1281">1281</a>.</li>
<li>Changed the following issues from Ready to Review: <a href="lwg-active.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-closed.html#1266">1266</a>, <a href="lwg-active.html#1268">1268</a>, <a href="lwg-closed.html#1269">1269</a>, <a href="lwg-closed.html#1272">1272</a>, <a href="lwg-closed.html#1275">1275</a>, <a href="lwg-defects.html#1278">1278</a>, <a href="lwg-active.html#1279">1279</a>, <a href="lwg-active.html#1281">1281</a>, <a href="lwg-active.html#1289">1289</a>, <a href="lwg-active.html#1290">1290</a>, <a href="lwg-closed.html#1291">1291</a>, <a href="lwg-active.html#1292">1292</a>, <a href="lwg-active.html#1294">1294</a>, <a href="lwg-active.html#1295">1295</a>, <a href="lwg-active.html#1297">1297</a>, <a href="lwg-closed.html#1302">1302</a>, <a href="lwg-closed.html#1305">1305</a>, <a href="lwg-closed.html#1307">1307</a>, <a href="lwg-closed.html#1308">1308</a>, <a href="lwg-active.html#1310">1310</a>, <a href="lwg-closed.html#1311">1311</a>, <a href="lwg-closed.html#1313">1313</a>, <a href="lwg-closed.html#1314">1314</a>, <a href="lwg-active.html#1316">1316</a>, <a href="lwg-closed.html#1317">1317</a>, <a href="lwg-active.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-closed.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-closed.html#1273">1273</a>, <a href="lwg-closed.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-closed.html#1293">1293</a>, <a href="lwg-defects.html#1298">1298</a>, <a href="lwg-defects.html#1299">1299</a>, <a href="lwg-closed.html#1300">1300</a>, <a href="lwg-defects.html#1303">1303</a>, <a href="lwg-closed.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-closed.html#1248">1248</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-active.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-closed.html#1258">1258</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="lwg-closed.html#815">815</a>, <a href="lwg-closed.html#1106">1106</a>.</li>
<li>Changed the following issues from Ready to Tentatively NAD Editorial: <a href="lwg-closed.html#816">816</a>, <a href="lwg-closed.html#889">889</a>.</li>
<li>Changed the following issues from NAD to Tentatively Ready: <a href="lwg-active.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-closed.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-closed.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-closed.html#1225">1225</a>, <a href="lwg-active.html#1234">1234</a>, <a href="lwg-active.html#1240">1240</a>, <a href="lwg-closed.html#1244">1244</a>, <a href="lwg-defects.html#1245">1245</a>, <a href="lwg-closed.html#1246">1246</a>, <a href="lwg-active.html#1249">1249</a>, <a href="lwg-defects.html#1250">1250</a>, <a href="lwg-closed.html#1251">1251</a>, <a href="lwg-active.html#1252">1252</a>, <a href="lwg-active.html#1253">1253</a>, <a href="lwg-defects.html#1254">1254</a>, <a href="lwg-defects.html#1255">1255</a>, <a href="lwg-defects.html#1256">1256</a>, <a href="lwg-defects.html#1257">1257</a>, <a href="lwg-closed.html#1258">1258</a>, <a href="lwg-closed.html#1259">1259</a>, <a href="lwg-active.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-closed.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-closed.html#1143">1143</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-closed.html#1116">1116</a>, <a href="lwg-closed.html#1117">1117</a>, <a href="lwg-closed.html#1122">1122</a>, <a href="lwg-closed.html#1129">1129</a>, <a href="lwg-closed.html#1145">1145</a>, <a href="lwg-closed.html#1146">1146</a>, <a href="lwg-closed.html#1147">1147</a>, <a href="lwg-closed.html#1155">1155</a>, <a href="lwg-closed.html#1166">1166</a>, <a href="lwg-closed.html#1172">1172</a>, <a href="lwg-closed.html#1174">1174</a>, <a href="lwg-closed.html#1179">1179</a>, <a href="lwg-defects.html#1195">1195</a>, <a href="lwg-closed.html#1196">1196</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#431">431</a>, <a href="lwg-closed.html#580">580</a>, <a href="lwg-closed.html#635">635</a>, <a href="lwg-closed.html#719">719</a>, <a href="lwg-closed.html#823">823</a>, <a href="lwg-closed.html#827">827</a>, <a href="lwg-closed.html#879">879</a>, <a href="lwg-closed.html#880">880</a>, <a href="lwg-closed.html#908">908</a>, <a href="lwg-closed.html#923">923</a>, <a href="lwg-closed.html#924">924</a>, <a href="lwg-closed.html#926">926</a>, <a href="lwg-closed.html#944">944</a>, <a href="lwg-closed.html#947">947</a>, <a href="lwg-closed.html#958">958</a>, <a href="lwg-closed.html#1046">1046</a>, <a href="lwg-closed.html#1048">1048</a>, <a href="lwg-closed.html#1054">1054</a>, <a href="lwg-closed.html#1055">1055</a>, <a href="lwg-closed.html#1075">1075</a>, <a href="lwg-closed.html#1088">1088</a>, <a href="lwg-closed.html#1160">1160</a>, <a href="lwg-closed.html#1161">1161</a>, <a href="lwg-closed.html#1162">1162</a>, <a href="lwg-closed.html#1163">1163</a>, <a href="lwg-closed.html#1165">1165</a>.</li>
<li>Changed the following issues from Review to NAD Editorial: <a href="lwg-closed.html#828">828</a>, <a href="lwg-closed.html#897">897</a>, <a href="lwg-closed.html#976">976</a>, <a href="lwg-closed.html#1043">1043</a>, <a href="lwg-closed.html#1047">1047</a>, <a href="lwg-closed.html#1049">1049</a>, <a href="lwg-closed.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-active.html#1118">1118</a>, <a href="lwg-closed.html#1119">1119</a>, <a href="lwg-closed.html#1151">1151</a>, <a href="lwg-closed.html#1153">1153</a>, <a href="lwg-closed.html#1156">1156</a>, <a href="lwg-active.html#1171">1171</a>, <a href="lwg-active.html#1173">1173</a>, <a href="lwg-active.html#1183">1183</a>, <a href="lwg-active.html#1191">1191</a>, <a href="lwg-closed.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-closed.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-closed.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-closed.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-closed.html#485">485</a>, <a href="lwg-defects.html#539">539</a>, <a href="lwg-closed.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-closed.html#932">932</a>, <a href="lwg-defects.html#939">939</a>, <a href="lwg-closed.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-active.html#868">868</a>, <a href="lwg-defects.html#871">871</a>, <a href="lwg-closed.html#889">889</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-closed.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-closed.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-closed.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-closed.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-defects.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-active.html#1188">1188</a>, <a href="lwg-defects.html#1189">1189</a>, <a href="lwg-active.html#1190">1190</a>, <a href="lwg-active.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-closed.html#1196">1196</a>, <a href="lwg-defects.html#1197">1197</a>, <a href="lwg-active.html#1198">1198</a>, <a href="lwg-defects.html#1199">1199</a>, <a href="lwg-active.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-active.html#1207">1207</a>, <a href="lwg-defects.html#1208">1208</a>, <a href="lwg-defects.html#1209">1209</a>, <a href="lwg-closed.html#1210">1210</a>, <a href="lwg-closed.html#1211">1211</a>, <a href="lwg-closed.html#1212">1212</a>, <a href="lwg-active.html#1213">1213</a>, <a href="lwg-active.html#1214">1214</a>, <a href="lwg-active.html#1215">1215</a>, <a href="lwg-defects.html#1216">1216</a>, <a href="lwg-closed.html#1217">1217</a>.</li>
<li>Changed the following issues from NAD to Open: <a href="lwg-defects.html#296">296</a>.</li>
<li>Changed the following issues from WP to Pending WP: <a href="lwg-defects.html#970">970</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-closed.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-closed.html#1145">1145</a>, <a href="lwg-closed.html#1146">1146</a>, <a href="lwg-closed.html#1147">1147</a>, <a href="lwg-closed.html#1148">1148</a>, <a href="lwg-closed.html#1150">1150</a>, <a href="lwg-closed.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-closed.html#1166">1166</a>, <a href="lwg-active.html#1169">1169</a>, <a href="lwg-defects.html#1170">1170</a>, <a href="lwg-active.html#1171">1171</a>, <a href="lwg-closed.html#1172">1172</a>, <a href="lwg-active.html#1173">1173</a>, <a href="lwg-closed.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-active.html#1181">1181</a>, <a href="lwg-defects.html#1182">1182</a>, <a href="lwg-active.html#1183">1183</a>, <a href="lwg-closed.html#1184">1184</a>, <a href="lwg-closed.html#1185">1185</a>, <a href="lwg-closed.html#1186">1186</a>.</li>
<li>Added the following Open issues: <a href="lwg-closed.html#1160">1160</a>, <a href="lwg-closed.html#1161">1161</a>, <a href="lwg-closed.html#1162">1162</a>, <a href="lwg-closed.html#1163">1163</a>, <a href="lwg-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.html#932">932</a>, <a href="lwg-closed.html#940">940</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-closed.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-closed.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-defects.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-active.html#868">868</a>, <a href="lwg-closed.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-closed.html#950">950</a>, <a href="lwg-closed.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-closed.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-closed.html#1116">1116</a>, <a href="lwg-closed.html#1117">1117</a>, <a href="lwg-active.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-closed.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-closed.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-closed.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-closed.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-closed.html#947">947</a>, <a href="lwg-active.html#951">951</a>, <a href="lwg-closed.html#953">953</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-closed.html#955">955</a>, <a href="lwg-active.html#956">956</a>, <a href="lwg-closed.html#977">977</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-active.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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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-defects.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-closed.html#825">825</a>, <a href="lwg-closed.html#830">830</a>, <a href="lwg-closed.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-closed.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-closed.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-closed.html#940">940</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-closed.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-closed.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-closed.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-closed.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-closed.html#983">983</a>, <a href="lwg-defects.html#984">984</a>, <a href="lwg-active.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-closed.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-closed.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-closed.html#1046">1046</a>, <a href="lwg-closed.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-closed.html#1055">1055</a>, <a href="lwg-closed.html#1064">1064</a>, <a href="lwg-closed.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-closed.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-closed.html#1043">1043</a>, <a href="lwg-defects.html#1044">1044</a>, <a href="lwg-defects.html#1045">1045</a>, <a href="lwg-closed.html#1047">1047</a>, <a href="lwg-closed.html#1049">1049</a>, <a href="lwg-closed.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-closed.html#874">874</a>, <a href="lwg-closed.html#875">875</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#732">732</a>, <a href="lwg-closed.html#793">793</a>, <a href="lwg-closed.html#794">794</a>, <a href="lwg-closed.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-closed.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-closed.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-closed.html#908">908</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-closed.html#923">923</a>, <a href="lwg-closed.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-closed.html#944">944</a>, <a href="lwg-closed.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-active.html#964">964</a>, <a href="lwg-active.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-closed.html#940">940</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-closed.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-closed.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-defects.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-closed.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-closed.html#944">944</a>, <a href="lwg-closed.html#945">945</a>, <a href="lwg-closed.html#946">946</a>, <a href="lwg-closed.html#947">947</a>, <a href="lwg-defects.html#948">948</a>, <a href="lwg-defects.html#949">949</a>, <a href="lwg-closed.html#950">950</a>, <a href="lwg-active.html#951">951</a>, <a href="lwg-closed.html#952">952</a>, <a href="lwg-closed.html#953">953</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-closed.html#955">955</a>, <a href="lwg-active.html#956">956</a>, <a href="lwg-defects.html#957">957</a>, <a href="lwg-closed.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-active.html#964">964</a>, <a href="lwg-defects.html#965">965</a>, <a href="lwg-active.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-closed.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-closed.html#923">923</a>, <a href="lwg-closed.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-closed.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-closed.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#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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.html#816">816</a>, <a href="lwg-defects.html#817">817</a>, <a href="lwg-defects.html#819">819</a>, <a href="lwg-closed.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-active.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-closed.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-closed.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-defects.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-closed.html#874">874</a>, <a href="lwg-closed.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-active.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-closed.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-closed.html#756">756</a>, <a href="lwg-closed.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-closed.html#794">794</a>, <a href="lwg-closed.html#815">815</a>, <a href="lwg-closed.html#825">825</a>, <a href="lwg-closed.html#830">830</a>, <a href="lwg-closed.html#833">833</a>, <a href="lwg-closed.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-closed.html#823">823</a>, <a href="lwg-closed.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-closed.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-closed.html#815">815</a>, <a href="lwg-closed.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-defects.html#822">822</a>, <a href="lwg-closed.html#823">823</a>, <a href="lwg-defects.html#824">824</a>, <a href="lwg-closed.html#825">825</a>, <a href="lwg-closed.html#826">826</a>, <a href="lwg-closed.html#827">827</a>, <a href="lwg-closed.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-closed.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-closed.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-closed.html#793">793</a>, <a href="lwg-closed.html#800">800</a>, <a href="lwg-active.html#801">801</a>, <a href="lwg-closed.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-active.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-closed.html#719">719</a>, <a href="lwg-defects.html#720">720</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-closed.html#732">732</a>, <a href="lwg-defects.html#734">734</a>, <a href="lwg-closed.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-closed.html#756">756</a>, <a href="lwg-closed.html#760">760</a>, <a href="lwg-defects.html#762">762</a>, <a href="lwg-closed.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-closed.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-closed.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-closed.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-closed.html#353">353</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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-active.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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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-active.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-closed.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-closed.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="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="DR">DR</a></b> - (Defect Report) - The full J16
  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 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 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 committee has voted to apply the Defect Report's Proposed
  Resolution to the working paper.</p>

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

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

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


<h2>Active Issues</h2>
<hr>
<h3><a name="579"></a>579. erase(iterator) for unordered containers should not return an iterator</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Joaqu&iacute;n M L&oacute;pez Mu&ntilde;oz <b>Opened:</b> 2006-06-13  <b>Last modified:</b> 2010-03-28</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
for full discussion.
</p>

<p><i>[
2009-12-11 Paolo opens:
]</i></p>


<blockquote>
I'm asking for DR 579 to be re-opened, basing on recent discussions on the
library reflector, see Message c++std-lib-26040 and replies.
</blockquote>

<p><i>[
2010-02-07 Paolo updates wording.
]</i></p>


<blockquote>
As pointed out by Chris in c++std-lib-26040, that an
<tt>erase(unordered_container, iterator)</tt> returning an <tt>iterator</tt> can
easily implemented in user code, if needed; that actually returning an
<tt>iterator</tt> costs nothing for the overload taking two <tt>iterator</tt>s,
thus that proposed change is only for consistency; that
<tt>forward_list::erase_after</tt> also returns <tt>void</tt> (for different
reasons, granted, but isn't that any "<tt>erase</tt>" function in the containers
uniformly returns an <tt>iterator</tt>); that, also in thread started by Chris'
message, Alberto pointed out that the proxy idea isn't a good one; that users
both of the GNU and Boost implementations are reporting serious performance
problems with the current version returning an <tt>iterator</tt>.
</blockquote>

<p><i>[
2010-02-07 Original wording saved here:
]</i></p>


<blockquote class="note">
<p>
Option 1:
</p>

<p>
The problem can be eliminated by omitting the requirement that <tt>a.erase(q)</tt> return an 
iterator. This is, however, in contrast with the equivalent requirements for other 
standard containers.
</p>

<p>
Option 2:
</p>

<p>
<tt>a.erase(q)</tt> can be made to compute the next iterator only when explicitly requested: 
the technique consists in returning a proxy object implicitly convertible to <tt>iterator</tt>, so 
that
</p>

<blockquote><pre>
iterator q1=a.erase(q);
</pre></blockquote>

<p>
works as expected, while
</p>

<blockquote><pre>
a.erase(q);
</pre></blockquote>

<p>
does not ever invoke the conversion-to-iterator operator, thus avoiding the associated 
computation. To allow this technique, some sections of TR1 along the line "return value 
is an iterator..." should be changed to "return value is an unspecified object implicitly 
convertible to an iterator..." Although this trick is expected to work transparently, it can 
have some collateral effects when the expression <tt>a.erase(q)</tt> is used inside generic 
code.
</p>

</blockquote>

<p><i>[
2010-02-09 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
]</i></p>


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


<blockquote>
<p>
There was no concensus for moving this to Ready.  However there was concensus
for moving this to NAD.
</p>

<p>
Rationale updated below.
</p>
</blockquote>

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


<blockquote>
Reopened and proposed wording updated by Beman.
</blockquote>

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


<blockquote>
Moved to Ready for Pittsburgh.
</blockquote>

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


<blockquote>
Reopened.  There is some discussion as to whether there is an acceptable
implementation of <tt>erase</tt> which returns <tt>iterator</tt>.  Need more
time to study it.
</blockquote>

<p><i>[
2010-03-27 Joaqu&iacute;n adds:
]</i></p>


<blockquote>
<p>
Signature of <tt>iterator erase(const_iterator)</tt> should be changed to <tt>void
erase(const_iterator)</tt>. If this is not viable an acceptable tradeoff
could be to make the return type of <tt>erase(const_iterator)</tt>
<i>implementation defined</i>.
</p>

<p>
The standard should allow implementations of unordered associative
containers using either singly or doubly linked lists.
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
proves that singly-linked lists implementations cannot provide the required
complexity for <tt>iterator erase(const_iterator)</tt>. Thus, some action is
needed to allow both implementations.
</p>

<p> 
Option 1: Changing the required complexity from O(1) to O(log n). This option
merely masks a design flaw. Users are forcefully penalized for what they don't
use (the returned iterator). Besides, they would have to learn about the
pathological (yet very real) situations where using <tt>erase</tt> can lead to
quadratic performance. Two out of these three objections remain even if some
alternative member function like <tt>void quick_erase(const_iterator)</tt> is
thrown in to the interface.
</p>

<p> 
Some objections have been expressed to changing return type of <tt>erase</tt> to
<tt>void</tt>, arguing that it would break current existing practice with
standard library implementations based on doubly-linked lists, where the problem
does not occur. However implementations based on drafts should not block the
resolution of a serious design issue, more so when the issue will hurt future
users of C++, as it's happening already.
</p>

<p> 
Option 2: Make <tt>erase</tt> return type <i>implementation defined</i>. There's
a possible tradeoff with the objectors above consisting in changing the
signature to <i>implementation defined</i> <tt>erase(iterator)</tt>, so that
returning an iterator is indeed a valid extension. To this it can be argued that
this would make implementantions returning an iterator look as somehow promoting
proprietary extensions: this in my opinion is not a valid argument since those
implementations are <em>already</em> extending the required interface by
providing bidirectional iterators (just forward iterators are required).
</p>
</blockquote>



<p><b>Rationale:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
was discussed in Portland and the consensus was that there appears to be
no need for either change proposed in the paper.  The consensus opinion
was that since the iterator could serve as its own proxy, there appears
to be no need for the change. In general, "converts to" is undesirable
because it interferes with template matching.
</p>

<p>
Post Toronto:  There does not at this time appear to be consensus with the Portland consensus. 
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
The Bellevue review of this issue reached consensus with the Portland
consensus, in contravention of the Toronto non-consensus. Common
implementations have the iterator readily available, and most common
uses depend on the iterator being returned.
</blockquote>

<p>****</p>

<p>
The rationale for the change in direction here is best summarized by Paolo's
2010-02-07 comment.
</p>

<p>
Pittsburgh:  Issue is wrong because we believe the standard is
consistent as written and the complexity is achievable.
</p>

<p>
Pittsburgh:  We want to enable both existing unordred container implementations.
</p>



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

<p><i>In 23.2.5 [unord.req], Table 98, change the following as indicated: </i>
</p>
<blockquote>
  <table border="1">
    <caption>Table 98 &mdash; Unordered associative container requirements (in 
    addition to container)</caption>
    <tr>
      <th>Expression</th>
      <th>Return type</th>
      <th>Assertion/note pre-/post-condition</th>
      <th>Complexity</th>
    </tr>
    <tr>
      <td><tt>a.erase(q)</tt></td>
      <td><tt>iterator</tt></td>
      <td>Erases the element pointed to by <tt>q</tt>. Return value is the 
      iterator immediately following <tt>q</tt> prior to the erasure.</td>
      <td>
      Average case <del><tt>O(1)</tt></del>
      <ins><tt>O(max(1, 1/a.load_factor())</tt></ins>,
      worst case <del><tt>O(a.size())</tt></del> <ins><tt>O(max(a.size(), a.bucket_count())</tt></ins>.</td>
    </tr>
    <tr>
      <td><tt>a.erase(q1, q2)</tt></td>
      <td><tt>iterator</tt></td>
      <td>Erases all elements in the range <tt>[q1, q2)</tt>. Return value is 
      the iterator immediately following the erased elements prior to the 
      erasure.</td>
      <td>Average case <del>linear in <tt>distance(q1, q2)</tt></del>
      <ins><tt>O(max(distance(q1,q2), 1/a.load_factor()))</tt></ins>,
      worst case <del><tt>O(a.size())</tt></del>
      <ins><tt>O(max(a.size(), a.bucket_count())</tt></ins>.</td>
    </tr>
    <tr>
      <td><ins><tt>a.quick_erase(q)</tt></ins></td>
      <td><ins><tt>void</tt></ins></td>
      <td><ins>Erases the element pointed to by <tt>q</tt>.</ins></td>
      <td><ins>Average case <tt>O(1)</tt>, worst case <tt>O(a.size())</tt>.</ins></td>
    </tr>
    <tr>
      <td><ins><tt>a.quick_erase(q1, q2)</tt></ins></td>
      <td><ins><tt>void</tt></ins></td>
      <td><ins>Erases all elements in the range <tt>[q1, q2)</tt>.</ins></td>
      <td><ins>Average case linear in <tt>distance(q1, q2)</tt>, worst case <tt>O(a.size())</tt>.</ins></td>
    </tr>
  </table>
</blockquote>
<p>Adjust the declarations accordingly in 23.5.1 [unord.map],  23.5.2 [unord.multimap], 
23.5.3 [unord.set], and 23.5.4 [unord.multiset]. </p>
<blockquote>
  <pre>iterator erase(const_iterator position);
<ins>void quick_erase(const_iterator position);</ins>  
...
iterator erase(const_iterator first, const_iterator last);
<ins>void quick_erase(const_iterator first, const_iterator last);</ins>
</pre>
</blockquote>








<hr>
<h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
<p><b>Section:</b> 20.4 [tuple] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-02-18  <b>Last modified:</b> 2010-08-25</p>
<p><b>View all other</b> <a href="lwg-index.html#tuple">issues</a> in [tuple].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Classes with trivial special member functions are inherently more
efficient than classes without such functions.  This efficiency is
particularly pronounced on modern ABIs that can pass small classes
in registers.  Examples include value classes such as complex numbers
and floating-point intervals.  Perhaps more important, though, are
classes that are simple collections, like <tt>pair</tt> and <tt>tuple</tt>.  When the
parameter types of these classes are trivial, the <tt>pair</tt>s and <tt>tuple</tt>s
themselves can be trivial, leading to substantial performance wins.
</p>
<p>
The current working draft make specification of trivial functions
(where possible) much easer through <tt>default</tt>ed and <tt>delete</tt>d functions.
As long as the semantics of defaulted and deleted functions match
the intended semantics, specification of defaulted and deleted
functions will yield more efficient programs.
</p>
<p>
There are at least two cases where specification of an explicitly
defaulted function may be desirable.
</p>
<p>
First, the <tt>std::pair</tt> template has a non-trivial default constructor,
which prevents static initialization of the pair even when the
types are statically initializable.  Changing the definition to
</p>

<blockquote><pre>
pair() = default;
</pre></blockquote>

<p>
would enable such initialization.  Unfortunately, the change is
not semantically neutral in that the current definition effectively
forces value initialization whereas the change would not value
initialize in some contexts.
</p>

<p>
** Does the committee confirm that forced value initialization
was the intent?  If not, does the committee wish to change the
behavior of <tt>std::pair</tt> in C++0x?
</p>
<p>
Second, the same default constructor issue applies to <tt>std::tuple</tt>.
Furthermore, the <tt>tuple</tt> copy constructor is current non-trivial,
which effectively prevents passing it in registers.  To enable
passing <tt>tuples</tt> in registers, the copy constructor should be
make explicitly <tt>default</tt>ed.  The new declarations are:
</p>

<blockquote><pre>
tuple() = default;
tuple(const tuple&amp;) = default;
</pre></blockquote>

<p>
This changes is not implementation neutral.  In particular, it
prevents implementations based on pointers to the parameter
types.  It does however, permit implementations using the
parameter types as bases.
</p>
<p>
** How does the committee wish to trade implementation
efficiency versus implementation flexibility?
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
General agreement; the first half of the issue is NAD.
</p>
<p>
Before voting on the second half, it was agreed that a "Strongly Favor"
vote meant support for trivial tuples (assuming usual requirements met),
even at the expense of other desired qualities. A "Weakly Favor" vote
meant support only if not at the expense of other desired qualities.
</p>
<p>
Concensus: Go forward, but not at expense of other desired qualities.
</p>
<p>
It was agreed to Alisdair should fold this work in with his other
pair/tuple action items, above, and that issue 801 should be "open", but
tabled until Alisdair's proposals are disposed of.
</p>
</blockquote>

<p><i>[
2009-05-27 Daniel adds:
]</i></p>


<blockquote>
This is partly solved by <a href="lwg-closed.html#1117">1117</a>.
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
Wait for dust to settle from fixing exception safety problem
with rvalue refs.
</blockquote>

<p><i>[
2009-07-20 Alisdair adds:
]</i></p>


<blockquote>
<p>
Basically, this issue is what should we do with the default constructor
for pairs and tuples of trivial types.  The motivation of the issue was
to force static initialization rather than dynamic initialization, and
was rejected in the case of pair as it would change the meaning of
existing programs.  The advice was "do the best we can" for tuple
without changing existing meaning.
</p>

<p>
Frankfurt seems to simply wait and see the resolution on no-throw move
constructors, which (I believe) is only tangentially related to this
issue, but as good as any to defer until Santa Cruz.
</p>

<p>
Looking again now, I think constant (static) initialization for pair can
be salvaged by making the default construct constexpr.  I have a
clarification from Core that this is intended to work, even if the
constructor is not trivial/constexpr, so long as no temporaries are
implied in the process (even if elided).
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Leave as open. Alisdair to provide wording.
</blockquote>

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


<blockquote>
<p>
We believe this may be NAD Editorial since both pair and tuple now have
constexpr default constructors, but we're not sure.
</p>
</blockquote>


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


<blockquote>
Daneil believes his pair/tuple paper will resolve this issue. <tt>constexpr</tt> will allow static initialization, and he is already changing the move and copy constructors to be defaulted.
</blockquote>



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





<hr>
<h3><a name="868"></a>868. default construction and value-initialization</h3>
<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-22  <b>Last modified:</b> 2010-08-25</p>
<p><b>View all other</b> <a href="lwg-index.html#containers">issues</a> in [containers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The term "default constructed" is often used in wording that predates
the introduction of the concept of value-initialization. In a few such
places the concept of value-initialization is more correct than the
current wording (for example when the type involved can be a built-in)
so a replacement is in order. Two of such places are already covered by
issue <a href="lwg-closed.html#867">867</a>. This issue deliberately addresses the hopefully
non-controversial changes in the attempt of being approved more quickly.
A few other occurrences (for example in <tt>std::tuple</tt>,
<tt>std::reverse_iterator</tt> and <tt>std::move_iterator</tt>) are left to separate
issues. For <tt>std::reverse_iterator</tt>, see also issue <a href="lwg-closed.html#408">408</a>. This issue is
related with issue <a href="lwg-defects.html#724">724</a>.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
The list provided in the proposed resolution is not complete. James
Dennett will review the library and provide a complete list and will
double-check the vocabulary.
</p>
<p>
This issue relates to Issue <a href="lwg-defects.html#886">886</a> tuple construction
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
The proposed resolution is incomplete.
</p>
<p>
Move to Tentatively NAD Future. Howard will contact Ganesh for wording.
If wording is forthcoming, Howard will move it back to Review.
</p>
</blockquote>

<p><i>[
2009-07-18 Ganesh updated the proposed wording.
]</i></p>


<blockquote>
<p>
Howard:  Moved back to Review.  Note that 20.2.1 [utility.arg.requirements]
refers to a section that is not in the current working paper, but does refer to
a section that we expect to reappear after the de-concepts merge.  This was a
point of confusion we did not recognize when we reviewed this issue in Frankfurt.
</p>
<p>
Howard:  Ganesh also includes a survey of places in the WP surveyed for changes
of this nature and purposefully <em>not</em> treated:
</p>

<blockquote>
<p>
Places where changes are <u>not</u> being
proposed
</p>
<p>
In the following paragraphs, we are not proposing changes because
it's not clear whether we actually prefer value-initialization over
default-initialization (now partially covered by <a href="lwg-defects.html#1012">1012</a>):
</p>
<ul>
    <li><p>20.9.10.2.1 [unique.ptr.single.ctor] para 3 e 7</p></li>
    <li><p>24.5.1.3.1 [reverse.iter.cons] para 1</p></li>
    <li><p>24.5.3.3.1 [move.iter.op.const] para 1</p></li>
</ul>
<p>In the following paragraphs, the expression "default
constructed" need not be changed, because the relevant type does
not depend on a template parameter and has a user-provided
constructor:</p>
<ul>
    <li><p> [func.referenceclosure.invoke] para 12, type:
    reference_closure</p></li>
    <li><p>30.3.1.2 [thread.thread.constr] para 30, type: thread</p></li>
    <li><p>30.3.1.5 [thread.thread.member] para 52, type: thread_id</p></li>
    <li><p>30.3.2 [thread.thread.this], para 1, type: thread_id</p></li>
</ul>
</blockquote>

</blockquote>

<p><i>[
2009-08-18 Daniel adds:
]</i></p>


<blockquote>
<p>
I have no objections against the currently suggested changes, but I
also cross-checked
with the list regarding intentionally excluded changes, and from this
I miss the discussion
of
</p>

<ol>
<li>
<p>
21.4.1 [string.require]/2:
</p>

<blockquote>
"[..] The <tt>Allocator</tt> object used shall be a copy of the <tt>Allocator></tt>
object passed to the <tt>basic_string</tt> object's
constructor or, if the constructor does not take an <tt>Allocator</tt>
argument, a copy of a default-constructed
<tt>Allocator</tt> object."
</blockquote>
</li>

<li>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>,
26.5.1.4 [rand.req.eng], Table 109, expression "<tt>T()</tt>":
</p>
<blockquote>
Pre-/post-condition: "Creates an engine with the same initial state as
all other default-constructed engines of type <tt>X</tt>."
</blockquote>

<p>
as well as in 26.5.5 [rand.predef]/1-9 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>), 26.5.7.1 [rand.util.seedseq]/3, 27.7.1.1.1 [istream.cons]/3, 27.7.2.2 [ostream.cons]/9 (<a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf"
>N2914</a>), 28.13 [re.grammar]/2, 30.3.1.4 [thread.thread.assign]/1 (<a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf"
>N2914</a>),
</p>
<p><i>[
Candidates for the "the expression "default constructed" need not be
changed" list
]</i></p>


<p>
I'm fine, if these would be added to the intentionally exclusion list,
but mentioning them makes it
easier for other potential reviewers to decide on the relevance or
not-relevance of them for this issue.
</p>
</li>

<li>
<p>
I suggest to remove the reference of  [func.referenceclosure.invoke]
in the "it's not clear" list, because
this component does no longer exist.
</p>
</li>

<li>
<p>
I also suggest to add a short comment that all paragraphs in the
resolution whether they refer to <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf"
>N2723</a> or to <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf"
>N2914</a> numbering, because e.g. "Change 23.3.2.1 [deque.cons] para 5" is an <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf"
>N2723</a> coordinate, while "Change 23.3.2.2 [deque.capacity] para 1" is an <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf"
>N2914</a> coordinate. Even better would be to use one default document
for the numbering (probably <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf"
>N2914</a>) and mention special cases (e.g. "Change 20.2.1 [utility.arg.requirements] para 2" as referring to <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf"
>N2723</a> numbering).
</p>
</li>
</ol>

</blockquote>

<p><i>[
2009-08-18 Alisdair adds:
]</i></p>


<blockquote>
<p>
I strongly believe the term "default constructed" should not appear in
the library clauses unless we very clearly define a meaning for it, and
I am not sure what that would be.
</p>

<p>
In those cases where we do not want to replace "default constructed"
with "vale initialized" we should be using "default initialized".  If we
have a term that could mean either, we reduce portability of programs.
</p>

<p>
I have not done an exhaustive review to clarify if that is a vendor
freedom we have reason to support (e.g. value-init in debug,
default-init in release) so I may yet be convinced that LWG has reason
to define this new term of art, but generally C++ initialization is
confusing enough without supporting further ill-defined terms.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>

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


<blockquote>
Moved to review in order to enable conflict resolution with <a href="lwg-defects.html#704">704</a>.
</blockquote>

<p><i>[
2010-03-26 Daniel harmonized the wording with the upcoming FCD.
]</i></p>



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


<blockquote>
Move to Ready.
</blockquote>




<p><b>Proposed resolution:</b></p>
<p>
Change 20.2.1 [utility.arg.requirements] para 2:
</p>

<blockquote>
2 In general, a default constructor is
not required. Certain container class member function signatures
specify <del>the default constructor</del><ins>T()</ins>
as a default argument. T() shall be a well-defined expression (8.5)
if one of those signatures is called using the default argument
(8.3.6).
</blockquote>

<p>
Change 23.3.2.1 [deque.cons] para 3:
</p>

<blockquote>
3 <i>Effects:</i> Constructs a deque with n
<del>default constructed</del><ins>value-initialized</ins>
elements. 
</blockquote>

<p>
Change 23.3.2.2 [deque.capacity] para 1:
</p>

<blockquote>
1 <i>Effects:</i> If sz &lt; size(), equivalent
to erase(begin() + sz, end());. If size() &lt; sz, appends sz -
size() <del>default
constructed</del><ins>value-initialized</ins>
elements to the sequence.
</blockquote>

<p>
Change 23.3.3.1 [forwardlist.cons] para 3:
</p>

<blockquote>
3 <i>Effects:</i> Constructs a forward_list object with n <del>default
constructed</del><ins>value-initialized</ins>
elements.
</blockquote>

<p>
Change 23.3.3.4 [forwardlist.modifiers] para 22:
</p>

<blockquote>
22 <i>Effects:</i> [...] For the first signature
the inserted elements are <del>default
constructed</del><ins>value-initialized</ins>,
and for the second signature they are copies of c.
</blockquote>

<p>
Change 23.3.4.1 [list.cons] para 3:
</p>

<blockquote>
3 <i>Effects:</i> Constructs a list with n <del>default
constructed</del><ins>value-initialized</ins>
elements. 
</blockquote>

<p>
Change 23.3.4.2 [list.capacity] para 1:
</p>

<blockquote>
1 <i>Effects:</i> If sz &lt; size(), equivalent
to list&lt;T&gt;::iterator it = begin(); advance(it, sz); erase(it,
end());. If size() &lt; sz, appends sz - size() <del>default
constructed</del><ins>value-initialized</ins>
elements to the sequence.
</blockquote>

<p>
Change 23.3.6.1 [vector.cons] para 3:
</p>

<blockquote>
3 <i>Effects:</i> Constructs a vector with n
<del>default constructed</del><ins>value-initialized</ins>
elements. 
</blockquote>

<p>
Change 23.3.6.2 [vector.capacity] para 9:
</p>

<blockquote>
9 <i>Effects:</i> If sz &lt; size(), equivalent
to erase(begin() + sz, end());. If size() &lt; sz, appends sz -
size() <del>default
constructed</del><ins>value-initialized</ins>
elements to the sequence.
</blockquote>






<hr>
<h3><a name="951"></a>951. Various threading bugs #1</h3>
<p><b>Section:</b> 20.10.2.1 [time.traits.is_fp] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2010-08-25</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Related to <a href="lwg-closed.html#953">953</a>.
</p>

<p>
20.10.2.1 [time.traits.is_fp] says that the type <tt>Rep</tt> "is
assumed to be ... a class emulating an integral type." What are the
requirements for such a type?
</p>
<p><i>[
2009-05-10 Howard adds:
]</i></p>


<blockquote>
<tt>IntegralLike</tt>.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
As with issue <a href="lwg-closed.html#953">953</a>,
we recommend this issue be addressed in the context of providing concepts for the entire <tt>thread</tt> header.
</p>
<p>
We look forward to proposed wording.
</p>
<p>
Move to Open.
</p>
</blockquote>

<p><i>[
2009-08-01 Howard adds:
]</i></p>


<blockquote>
<p>
I have surveyed all clauses of 20.10.2.2 [time.traits.duration_values],
20.10.2.3 [time.traits.specializations] and 20.10.3 [time.duration].
I can not find any clause which involves the use of a <tt>duration::rep</tt> type
where the requirements on the <tt>rep</tt> type are not clearly spelled out.
These requirements were carefully crafted to allow any arithmetic type, or
any user-defined type emulating an arithmetic type.
</p>

<p>
Indeed, <tt>treat_as_floating_point</tt>
becomes completely superfluous if <tt>duration::rep</tt> can never be a class type.
</p>

<p>
There will be some <tt>Rep</tt> types which will not meet the requirements of
<em>every</em> <tt>duration</tt> operation.  This is no different than the fact
that <tt>vector&lt;T&gt;</tt> can easily be used for types <tt>T</tt> which are
not <tt>DefaultConstructible</tt>, even though some members of <tt>vector&lt;T&gt;</tt>
require <tt>T</tt> to be <tt>DefaultConstructible</tt>.  This is why the requirements
on <tt>Rep</tt> are specified for each operation individually.
</p>

<p>
In 20.10.2.1 [time.traits.is_fp] p1:
</p>

<blockquote><pre>
template &lt;class Rep&gt; struct treat_as_floating_point 
  : is_floating_point&lt;Rep&gt; { };
</pre>

<blockquote>
The <tt>duration</tt> template uses the <tt>treat_as_floating_point</tt> trait to help
determine if a <tt>duration</tt> object can be converted to another <tt>duration</tt>
with a different tick period. If <tt>treat_as_floating_point&lt;Rep&gt;::value</tt> is
<tt>true</tt>, then <tt>Rep</tt> is a floating-point type and implicit conversions are
allowed among <tt>duration</tt>s. Otherwise, the implicit convertibility depends
on the tick periods of the <tt>duration</tt>s. If <tt>Rep</tt> is <u>a class type which
emulates a floating-point type</u>, the author of <tt>Rep</tt> can specialize
<tt>treat_as_floating_point</tt> so that <tt>duration</tt> will treat this <tt>Rep</tt> as if it
were a floating-point type. Otherwise <tt>Rep</tt> is assumed to be an integral
type or <u>a class emulating an integral type</u>.
</blockquote>
</blockquote>

<p>
The phrases "a class type which emulates a floating-point type" and
"a class emulating an integral type" are clarifying phrases which refer to
the summation of all the requirements on the <tt>Rep</tt> type specified in
detail elsewhere (and <em>should not</em> be repeated here).
</p>

<p>
This specification has been implemented, now multiple times, and the experience
has been favorable.  The current specification clearly specifies the requirements
at each point of use (though I'd be happy to fix any place I may have missed,
but none has been pointed out).
</p>

<p>
I am amenable to improved wording of this paragraph (and any others), but do not have any
suggestions for improved wording at this time.  I am <em>strongly</em> opposed to
changes which would significantly alter the semantics of the
specification under 20.10 [time] without firmly grounded and
documented rationale, example implementation, testing, and user
experience which relates a positive experience.
</p>

<p>
I recommend NAD unless someone wants to produce some clarifying wording.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Stefanus to provide wording to turn this into a note.
</blockquote>

<p><i>[
2010-02-11 Stefanus provided wording.
]</i></p>



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


<blockquote>
Move to Ready.
</blockquote>




<p><b>Proposed resolution:</b></p>
<p>
Change 20.10.2.1 [time.traits.is_fp]/1:
</p>

<blockquote>
1 The <tt>duration</tt> template uses the <tt>treat_as_floating_point</tt> trait
to help determine if a <tt>duration</tt> object can be converted to another
<tt>duration</tt> with a different tick period. If
<tt>treat_as_floating_point&lt;Rep&gt;::value</tt> is <tt>true</tt>, then
<del><tt>Rep</tt> is a floating-point type and</del> implicit conversions are allowed among
<tt>duration</tt>s. Otherwise, the implicit convertibility depends on the tick
periods of the <tt>duration</tt>s. <del>If <tt>Rep</tt> is a class type which
emulates a floating-point type, the author of <tt>Rep</tt> can specialize
<tt>treat_as_floating_point</tt> so that duration will treat this <tt>Rep</tt>
as if it were a floating-point type. Otherwise <tt>Rep</tt> is assumed to be an
integral type or a class emulating an integral type.</del>
<ins>[<i>Note:</i> The intention of this trait is to indicate whether a given
class behaves like a floating point type, and thus allows division of one value
by another with acceptable loss of precision. If
<tt>treat_as_floating_point&lt;Rep&gt;::value</tt> is <tt>false</tt>,
<tt>Rep</tt> will be treated as if it behaved like an integral type for the
purpose of these conversions. &mdash; <i>end note</i>]</ins>
</blockquote>






<hr>
<h3><a name="956"></a>956. Various threading bugs #6</h3>
<p><b>Section:</b> 20.10.1 [time.clock.req] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2010-03-28</p>
<p><b>View all other</b> <a href="lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.10.1 [time.clock.req] uses the word "native" in several places,
but doesn't define it. What is a "native <tt>duration</tt>"?
</p>

<p><i>[
2009-05-10 Howard adds:
]</i></p>


<blockquote>
The standard uses "native" in several places without defining it (e.g.
2.14.3 [lex.ccon]).  It is meant to mean "that which is defined
by the facility", or something along those lines.  In this case it refers
to the nested <tt>time_point</tt> and <tt>duration</tt> types of the clock.
Better wording is welcome.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
Move to Open pending proposed wording from Pete.
</blockquote>

<p><i>[
2009-10-23 Pete provides wording:
]</i></p>


<p><i>[
2009-11-18 Daniel adds:
]</i></p>


<blockquote>
<p>
I see that 30.4.2 [thread.timedmutex.requirements]/3 says:
</p>

<blockquote>
<i>Precondition:</i> If the tick <tt>period</tt> of <tt>rel_time</tt> is not
exactly convertible to the native tick <tt>period</tt>, the <tt>duration</tt>
shall be rounded up to the nearest native tick <tt>period</tt>.
</blockquote>

<p>
I would prefer to see that adapted as well. Following the same style as
the proposed resolution I come up with
</p>

<blockquote>
<i>Precondition:</i> If the tick <tt>period</tt> of <tt>rel_time</tt> is not
exactly convertible to the <del>native</del> tick <tt>period</tt> <ins>of the
execution environment</ins>, the <tt>duration</tt> shall be rounded up to the
nearest <del>native</del> tick <tt>period</tt> <ins>of the execution
environment</ins>.
</blockquote>

</blockquote>

<p><i>[
2010-03-28 Daniel synced wording with N3092
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Remove every occurrence of "native" in 20.10.1 [time.clock.req].
</p>

<p>
Add the following sentence at the end of 20.10.1 [time.clock.req]/1:
</p>

<blockquote>
A clock is a bundle consisting of a <del>native</del> <tt>duration</tt>, a
<del>native</del> <tt>time_point</tt>, and a function <tt>now()</tt> to get the
current <tt>time_point</tt>. The origin of the clock's <tt>time_point</tt> is
referred to as the clock's <i>epoch</i>. A clock shall meet the requirements in
Table 56. <ins>The <tt>duration</tt> and <tt>time_point</tt> types have the
natural size and resolution suggested by the architecture of the execution
environment.</ins>
</blockquote>





<hr>
<h3><a name="964"></a>964. Various threading bugs #14</h3>
<p><b>Section:</b> 30.5.2 [thread.condition.condvarany] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2010-03-15</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.condition.condvarany">issues</a> in [thread.condition.condvarany].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The requirements for the constructor for <tt>condition_variable</tt> has several
error conditions, but the requirements for the constructor for
<tt>condition_variable_any</tt> has none. Is this difference intentional?
</p>

<p><i>[
Summit:
]</i></p>


<blockquote>
Move to open, pass to Howard. If this is intentional, a note may be
helpful. If the error conditions are to be copied from
<tt>condition_variable</tt>, this depends on LWG <a href="lwg-defects.html#965">965</a>.
</blockquote>

<p><i>[
Post Summit Howard adds:
]</i></p>


<blockquote>
The original intention 
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2447.htm#ConditionVariablesWording">N2447</a>)
was to let the OS return whatever errors it was going to return, and for
those to be translated into exceptions, for both
<tt>condition_variable</tt> and <tt>condition_variable_any</tt>.  I have not
received any complaints about specific error conditions from vendors on
non-POSIX platforms, but such complaints would not surprise me if they surfaced.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Leave open. Benjamin to provide wording.
</blockquote>

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


<blockquote>
<p>
We don't have throw clauses for condition variables.
</p>
<p>
This issue may be dependent on LWG <a href="lwg-active.html#1268">1268</a>.
</p>
<p>
Leave open. Detlef will coordinate with Benjamin.
</p>
<p>
Consider mberging LWG 964, <a href="lwg-active.html#966">966</a>, and <a href="lwg-active.html#1268">1268</a> into a
single paper.
</p>
</blockquote>



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





<hr>
<h3><a name="966"></a>966. Various threading bugs #16</h3>
<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2010-03-15</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
30.5.1 [thread.condition.condvar]:
<tt>condition_variable::wait</tt> and
<tt>condition_variable::wait_until</tt> both have a postcondition that
<tt>lock</tt> is locked by the calling thread, and a throws clause that
requires throwing an exception if this postcondition cannot be achieved.
How can the implementation detect that this <tt>lock</tt> can never be
obtained?
</p>

<p><i>[
Summit:
]</i></p>


<blockquote>
Move to open. Requires wording. Agreed this is an issue, and the
specification should not require detecting deadlocks.
</blockquote>

<p><i>[
2009-08-01 Howard provides wording.
]</i></p>


<blockquote>
<p>
The proposed wording is inspired by the POSIX spec which says:
</p>

<blockquote>
<dl>
<dt>[EINVAL]</dt>
<dd>The value specified by cond or mutex is invalid.</dd>
<dt>[EPERM]</dt>
<dd>The mutex was not owned by the current thread at the time of the call.</dd>
</dl>
</blockquote>

<p>
I do not believe [EINVAL] is possible without memory corruption (which we don't
specify).  [EPERM] is possible if this thread doesn't own the mutex, which is
listed as a precondition.  "May" is used instead of "Shall" because not all
OS's are POSIX.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Leave open, Detlef to provide improved wording.
</blockquote>

<p><i>[
2009-10-23 Detlef Provided wording.
]</i></p>


<blockquote>
<p>
Detlef's wording put in Proposed resolution.  Original wording here:
</p>
<blockquote>
<p>
Change 30.5.1 [thread.condition.condvar] p12, p19 and
30.5.2 [thread.condition.condvarany] p10, p16:
</p>

<blockquote>
<i>Throws:</i> <ins>May throw</ins> <tt>std::system_error</tt> 
<ins>
if a precondition is not met.
</ins>
<del>when the effects or postcondition
cannot be achieved.</del>
</blockquote>
</blockquote>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Leave open, Detlef to provide improved wording.
</blockquote>

<p><i>[
2009-11-18 Anthony adds:
]</i></p>


<blockquote>
<p>
<tt>condition_variable::wait</tt> takes a <tt>unique_lock&lt;mutex&gt;</tt>. We
know whether or not a <tt>unique_lock</tt> owns a lock, through use of its
<tt>owns_lock()</tt> member.
</p>

<p>
I would like to propose the following resolution:
</p>

<blockquote>
<p>
Modify the first sentence of 30.5.1 [thread.condition.condvar] p9:
</p>

<blockquote><pre>
void wait(unique_lock&lt;mutex&gt;&amp; lock);
</pre>
<blockquote>
9 <i>Precondition:</i> <del><tt>lock</tt> is locked by the calling thread</del>
<ins><tt>lock.owns_lock()</tt> is <tt>true</tt></ins>, and either
<p>...</p>
</blockquote>
</blockquote>

<p>
Replace 30.5.1 [thread.condition.condvar] p11-13 with:
</p>

<blockquote><pre>
void wait(unique_lock&lt;mutex&gt;&amp; lock);
</pre>
<blockquote>
<p>...</p>
<p>
11 <i>Postcondition:</i> <del><tt>lock</tt> is locked by the calling
thread</del> <ins><tt>lock.owns_lock()</tt> is <tt>true</tt></ins>.
</p>

<p>
12 <i>Throws:</i> <tt>std::system_error</tt> <del>when the effects or
postcondition cannot be achieved</del> <ins>if the implementation detects that
the preconditions are not met or the effects cannot be achieved. Any exception
thrown by <tt>lock.lock()</tt> or <tt>lock.unlock()</tt></ins>.
</p>

<p>
13 <i>Error Conditions:</i> <ins>The error conditions are implementation
defined.</ins>
</p>

<ul>
<li><del>
equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
</del></li>
</ul>

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

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


<blockquote>
<p>
There are heavy conflicts with adopted papers.
</p>
<p>
This issue is dependent on LWG <a href="lwg-active.html#1268">1268</a>.
</p>
<p>
Leave open pending outstanding edits to the working draft. Detlef will provide
wording.
</p>
<p>
Possibly related to <a href="lwg-active.html#964">964</a>.
</p>

</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Replace 30.5.1 [thread.condition.condvar] p12, p19 and
30.5.2 [thread.condition.condvarany] p10, p16:
</p>

<blockquote>
<p><del>
<i>Throws:</i> <tt>std::system_error</tt> when the effects or
postcondition cannot be achieved.
</del></p>
<p><del>
Error conditions:
</del></p>
<ul>
<li><del>
equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
</del></li>
</ul>

<p><ins>
<i>Throws:</i> It is implementation-defined whether a <tt>std::system_error</tt>
with implementation-defined error condition is thrown if the
precondition is not met.
</ins></p>
</blockquote>






<hr>
<h3><a name="985"></a>985. Allowing throwing move</h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Rani Sharoni <b>Opened:</b> 2009-02-12  <b>Last modified:</b> 2010-03-28</p>
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<b>Introduction</b>
</p>

<p>This proposal is meant to resolve potential regression of the
<a href ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>
draft, see
next section, and to relax the requirements for containers of types with
throwing move constructors.</p>

<p>The basic problem is that some containers operations, like <tt>push_back</tt>,
have a strong exception safety
guarantee (i.e. no side effects upon exception) that are not achievable when
throwing move constructors are used since there is no way to guarantee revert
after partial move. For such operations the implementation can at most provide
the basic guarantee (i.e. valid but unpredictable) as it does with multi
copying operations (e.g. range insert).</p>

<p>For example, <tt>vector&lt;T&gt;::push_back()</tt> (where <tt>T</tt> has a move
constructor) might resize the <tt>vector</tt> and move the objects to the new underlying
buffer. If move constructor throws it might
not be possible to recover the throwing object or to move the old objects back to
the original buffer.</p>

<p>The current draft is explicit by disallowing throwing move
for some operations (e.g. <tt>vector&lt;&gt;::reserve</tt>) and not clear about other
operations mentioned in 23.2.1 [container.requirements.general]/10
(e.g. single element <tt>insert</tt>): it guarantees strong exception
safety without explicitly disallowing a throwing move constructor.
</p>

<p>
<b>Regression</b>
</p>

<p>This section only refers to cases in which the contained object
is by itself a standard container.</p>

<p>Move constructors of standard containers are allowed to throw and therefore
existing operations are broken, compared with C++03, due to move optimization.
(In fact existing implementations like Dinkumware are actually throwing).</p>

<p>For example, <tt>vector&lt; list&lt;int&gt; &gt;::reserve</tt> yields
undefined behavior since <tt>list&lt;int&gt;</tt>'s move constructor is allowed to throw.
On the other hand, the same operation has strong exception safety guarantee in
C++03.</p>

<p>There are few options to solve this regression:</p>

<ol>
<li>
Disallow throwing move and throwing default constructor
</li>

<li>
Disallow throwing move but disallowing usage after move
</li>

<li>
Special casing
</li>

<li>
Disallow throwing move and making it optional
</li>

</ol>

<p>Option 1 is suggested by proposal
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2815.html">N2815</a>
but it might not be applicable for existing implementations for which
containers default constructors are throwing.</p>

<p>Option 2 limits the usage significantly and it's error prone
by allowing zombie objects that are nothing but destructible (e.g. no <tt>clear()</tt>
is allowed after move). It also potentially complicates the implementation by
introducing special state.</p>

<p>Option 3 is possible, for example, using default
construction and <tt>swap</tt> instead of move for standard containers case. The
implementation is also free to provide special hidden operation for non
throwing move without forcing the user the cope with the limitation of option-2
when using the public move.</p>

<p>Option 4 impact the efficiency in all use cases due to rare throwing move.</p>

<p>The proposed wording will imply option 1 or 3 though option 2 is also
achievable using more wording. I personally oppose to option 2 that has impact
on usability.</p>

<p>
<b>Relaxation for user types</b>
</p>

<p>Disallowing throwing move constructors in general seems very restrictive
since, for example, common implementation of move will be default construction
+ <tt>swap</tt> so move will throw if the
default constructor will throw. This is currently the case with the Dinkumware
implementation of node based containers (e.g. <tt>std::list</tt>)
though this section doesn't refer to standard types.</p>

<p>For throwing move constructors it seem that the implementation should have
no problems to provide the basic guarantee instead of the strong one. It's
better to allow throwing move constructors with basic guarantee than to
disallow it silently (compile and run), via undefined behavior.</p>

<p>There might still be cases in which the relaxation will break existing generic
code that assumes the strong guarantee but it's broken either way given a
throwing move constructor since this is not a preserving optimization. </p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Bjarne comments (referring to his draft paper):
"I believe that my suggestion simply solves that.
Thus, we don't need a throwing move."
</p>
<p>
Move to Open and recommend it be deferred until after the next
Committee Draft is issued.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Should wait to get direction from Dave/Rani
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2983.html">N2983</a>).
</blockquote>

<p><i>[
2010-03-28 Daniel updated wording to sync with N3092.
]</i></p>


<blockquote>
<p>
The suggested change of 23.3.2.3 [deque.modifiers]/2 should be removed,
because the current wording does say more general things:
</p>

<blockquote>
2 <i>Remarks:</i> If an exception is thrown other than by the copy constructor,
move constructor, assignment operator, or move assignment operator of <tt>T</tt>
there are no effects. If an exception is thrown by the move constructor of a
non-CopyConstructible <tt>T</tt>, the effects are unspecified.
</blockquote>

<p>
The suggested change of 23.3.6.2 [vector.capacity]/2 should be removed,
because the current wording does say more general things:
</p>

<blockquote>
2 <i>Effects:</i> A directive that informs a <tt>vector</tt> 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
<tt>reserve</tt> 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>CopyConstructible</tt> type, there are no effects.
</blockquote>

</blockquote>



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

<p>
23.2.1 [container.requirements.general]  paragraph 11 add footnote:
</p>

<blockquote>
<p>
-11- Unless otherwise specified (see 23.1.4.1, 23.1.5.1, 23.2.2.3, and
23.2.6.4) all container types defined in this Clause meet the following
additional requirements:
</p>
<ul>
<li>...</li>
</ul>

<p>
<ins>[<i>Note</i>: for compatibility with C++
2003, when "no effect" is required, standard containers should not use the
value_type's throwing move constructor when the contained object is by itself a
standard container. -- <i>end note</i>]</ins>
</p>

</blockquote>

<p>23.2.5.1 [unord.req.except] change paragraph 2 to say: </p>

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

<p>
-4- For unordered associative containers, if an exception is
thrown from within a <tt>rehash()</tt> function other than by the container's hash
function or comparison function, the <tt>rehash()</tt> function has no effect
<ins>unless the exception is thrown by the contained
object move constructor</ins>.</p>

</blockquote>

<p>
23.3.2.3 [deque.modifiers] change paragraph 2 to say:
</p>

<blockquote>
-2- <i>Remarks:</i> If an exception is thrown other than by
the copy constructor<ins>, move constructor</ins>
or assignment operator of <tt>T</tt>
there are no effects.
<ins>If an exception is thrown by <tt>push_back()</tt> or <tt>emplace_back()</tt>
function, that function has no effects unless the exception is thrown by
the move constructor of <tt>T</tt>.</ins>
</blockquote>

<p>
23.3.6.2 [vector.capacity] paragraph 2 change to say:
</p>

<blockquote>
-2- <i>Effects:</i> A directive that informs a <tt>vector</tt>
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 <tt>reserve</tt>
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, there are no effects<ins>
unless the exception is thrown by the contained object move constructor</ins>.
</blockquote>

<p>
23.3.6.2 [vector.capacity] paragraph 12 change to say:
</p>

<blockquote>
-12- <i>Requires:</i> <del>If <tt>value_type</tt> has a move constructor,
that constructor shall not throw any exceptions.</del>
<ins>If an exception is thrown, there are no effects unless the exception is thrown by
the contained object move constructor.</ins>
</blockquote>

<p>
23.3.6.4 [vector.modifiers] change paragraph 1 to say:
</p>

<blockquote>
-1- <del><i>Requires:</i> If <tt>value_type</tt> has a move constructor,
that constructor shall not throw any exceptions.</del>
<ins><i>Remarks:</i> If an exception is thrown by <tt>push_back()</tt>
or <tt>emplace_back()</tt> function, that function has no effect unless the
exception is thrown by the move constructor of <tt>T</tt>.</ins>
</blockquote>






<hr>
<h3><a name="1118"></a>1118. tuple query APIs do not support cv-qualification</h3>
<p><b>Section:</b> 20.4.2.5 [tuple.helper] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2010-03-28</p>
<p><b>View all other</b> <a href="lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The APIs <tt>tuple_size</tt> and <tt>tuple_element</tt> do not support
cv-qualified <tt>tuple</tt>s, <tt>pair</tt>s or <tt>array</tt>s.
</p>
<p>
The most generic solution would be to supply partial specializations once
for each cv-type in the <tt>tuple</tt> header.  However, requiring this header for
cv-qualified <tt>pair</tt>s/<tt>array</tt>s seems unhelpful.  The BSI editorial
suggestion (UK-198/US-69,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2533.html">N2533</a>)
to merge <tt>tuple</tt> into <tt>&lt;utility&gt;</tt> would help with <tt>pair</tt>,
but not <tt>array</tt>.  That might be resolved by making a dependency between the
<tt>&lt;array&gt;</tt> header and <tt>&lt;utility&gt;</tt>, or simply recognising
the dependency be fulfilled in a Remark.
</p>

<p><i>[
2009-05-24 Daniel adds:
]</i></p>


<blockquote>
<p>
All <tt>tuple_size</tt> templates with a base class need to derive publicly, e.g.
</p>

<blockquote><pre>
template &lt;IdentityOf T&gt; class tuple_size&lt; const T &gt; :
   <ins>public</ins> tuple_size&lt;T&gt; {};
</pre></blockquote>

<p>
The same applies to the tuple_element class hierarchies.
</p>
<p>
What is actually meant with the comment
</p>
<blockquote>
this solution relies on 'metafunction forwarding' to inherit the
nested typename type
</blockquote>
<p>
?
</p>
<p>
I ask, because all base classes are currently unconstrained and their
instantiation is invalid in the constrained context of the <tt>tuple_element</tt> partial
template specializations.
</p>
</blockquote>

<p><i>[
2009-05-24 Alisdair adds:
]</i></p>


<blockquote>
<p>
I think a better solution might be to ask Pete editorially to change all
declarations of tupling APIs to use the struct specifier instead of class.
</p>
<p>
"metafunction forwarding" refers to the MPL metafunction protocol, where a
metafunction result is declared as a nested typedef with the name "type",
allowing metafunctions to be chained by means of inheritance.  It is a
neater syntax than repeatedly declaring a typedef, and inheritance syntax is
slightly nicer when it comes to additional typename keywords.
</p>
<p>
The constrained template with an unconstrained base is a good observation
though.
</p>
</blockquote>

<p><i>[
2009-10 post-Santa Cruz:
]</i></p>


<blockquote>
Move to Open, Alisdair to provide wording. Once wording is
provided, Howard will move to Review.
</blockquote>

<p><i>[
2010-03-28 Daniel deconceptified wording.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Add to 20.4.1 [tuple.general] p2 (Header <tt>&lt;tuple&gt;</tt> synopsis)
</p>

<blockquote><pre>
// 20.4.2.5, tuple helper classes:
template &lt;class T&gt; class tuple_size; // undefined
<ins>template &lt;class T&gt; class tuple_size&lt;const T&gt; : public tuple_size&lt;T&gt; {};</ins>
<ins>template &lt;class T&gt; class tuple_size&lt;volatile T&gt; : public tuple_size&lt;T&gt; {};</ins>
<ins>template &lt;class T&gt; class tuple_size&lt;const volatile T&gt; : public tuple_size&lt;T&gt; {};</ins>
template &lt;class... Types&gt; class tuple_size&lt;tuple&lt;Types...&gt; &gt;;

template &lt;size_t I, class T&gt; class tuple_element; // undefined
<ins>template &lt;size_t I, class T&gt; class tuple_element&lt;I, const T&gt;;</ins>
<ins>template &lt;size_t I, class T&gt; class tuple_element&lt;I, volatile T&gt;;</ins>
<ins>template &lt;size_t I, class T&gt; class tuple_element&lt;I, const volatile T&gt;;</ins>
template &lt;size_t I, class... Types&gt; class tuple_element&lt;I, tuple&lt;Types...&gt; &gt;;
</pre></blockquote>



<p>
Add to 20.4.2.5 [tuple.helper]
</p>

<blockquote><pre>
template &lt;class... Types&gt;
class tuple_size&lt;tuple&lt;Types...&gt; &gt;
  : public integral_constant&lt;size_t, sizeof...(Types)&gt; { };

template &lt;size_t I, class... Types&gt;
class tuple_element&lt;I, tuple&lt;Types...&gt; &gt; {
public:
  typedef TI type;
};

<ins>template &lt;size_t I, class T&gt;
  class tuple_element&lt;I, const T&gt; : public add_const&lt;tuple_element&lt;I, T&gt;&gt; {};</ins>
<ins>template &lt;size_t I, class T&gt;
  class tuple_element&lt;I, volatile T&gt; : public add_volatile&lt;tuple_element&lt;I, T&gt;&gt; {};</ins>
<ins>template &lt;size_t I, class T&gt;
  class tuple_element&lt;I, const volatile T&gt; : public add_cv&lt;tuple_element&lt;I, T&gt;&gt; {};</ins>
</pre></blockquote>







<hr>
<h3><a name="1169"></a>1169. <tt>num_get</tt> not fully compatible with <tt>strto*</tt></h3>
<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Cosmin Truta <b>Opened:</b> 2009-07-04  <b>Last modified:</b> 2010-08-25</p>
<p><b>View all other</b> <a href="lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As specified in the latest draft,
<a 
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>,
<code>num_get</code> is still not fully compatible with the following C
functions: <code>strtoul</code>, <code>strtoull</code>, 
<code>strtof</code> and
<code>strtod</code>.
</p>
<p>
In C, when conversion of a string to an unsigned integer type falls 
outside the
representable range, <code>strtoul</code> and <code>strtoull</code> return
<code>ULONG_MAX</code> and <code>ULLONG_MAX</code>, respectively, 
regardless
whether the input field represents a positive or a negative value.
On the other hand, the result of <code>num_get</code> conversion of 
negative
values to unsigned integer types is zero. This raises a compatibility 
issue.
</p>
<p>
Moreover, in C, when conversion of a string to a floating-point type falls
outside the representable range, <code>strtof</code>, <code>strtod</code> 
and
<code>strtold</code> return <code>&#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>
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.

Bill: There's a change here as to whether val is stored to in an error case.

Pablo: Don't think this changes whether val is stored to or not, but changes the value that is stored.

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.

Howard: Believes since C++03 we made a change to always store in overflow.

Everyone took some time to review the issue.

Pablo: C++98 definitely did not store any value during an error condition.

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.

Pablo: Yes, but given the "zero, if the conversion function fails to convert the entire field", we are requiring every error condition to store.

Bill: When did this happen?

Alisdair: One of the last two or three meetings.

Dietmar: To store a value in case of failure is a very bad idea.

Move to Open, needs more study.
</blockquote>



<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="1171"></a>1171. duration types should be literal</h3>
<p><b>Section:</b> 20.10.3 [time.duration] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-06  <b>Last modified:</b> 2010-08-25</p>
<p><b>View all other</b> <a href="lwg-index.html#time.duration">issues</a> in [time.duration].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>duration</tt> types in 20.10.3 [time.duration] are exactly the sort of type
that should be "literal types" in the new standard.  Likewise,
arithmetic operations on <tt>duration</tt>s should be declared <tt>constexpr</tt>.
</p>

<p><i>[
2009-09-21 Daniel adds:
]</i></p>


<blockquote>
An alternative (and possibly preferable solution for potentially
heap-allocating big_int representation types) would be to ask the core
language to allow references to <tt>const</tt> literal types as feasible
arguments for <tt>constexpr</tt> functions.
</blockquote>

<p><i>[
2009-10-30 Alisdair adds:
]</i></p>


<blockquote>
<p>
I suggest this issue moves from New to Open.
</p>

<p>
Half of this issue was dealt with in paper
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">n2994</a>
on constexpr constructors.
</p>

<p>
The other half (duration arithmetic) is on hold pending Core support for
<tt>const &amp;</tt> in <tt>constexpr</tt> functions.
</p>

</blockquote>

<p><i>[
2010-03-15 Alisdair updated wording to be consistent with
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3078.html">N3078</a>.
]</i></p>



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


<blockquote>
This issue was the motivation for Core adding the facility for <tt>constexpr</tt> functions to take parameters by <tt>const &</tt>.

Move to Tentatively Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add <tt>constexpr</tt> to declaration of following functions and constructors:
</p>
<p>
Modify p1 20.10 [time], and the prototype definitions in 20.10.3.5 [time.duration.nonmember], 20.10.3.6 [time.duration.comparisons],
and 20.10.3.7 [time.duration.cast]:
</p>

<blockquote>
<p>
<b>Header <tt>&lt;chrono&gt;</tt> synopsis</b>
</p>

<pre>
<i>// duration arithmetic</i>
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
   <ins>constexpr</ins> operator+(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
   <ins>constexpr</ins> operator-(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
template &lt;class Rep1, class Period, class Rep2&gt;
   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
   <ins>constexpr</ins> operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
template &lt;class Rep1, class Period, class Rep2&gt;
   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
   <ins>constexpr</ins> operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
template &lt;class Rep1, class Period, class Rep2&gt;
   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
   <ins>constexpr</ins> operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   typename common_type&lt;Rep1, Rep2&gt;::type
   <ins>constexpr</ins> operator/(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);

<i>// duration comparisons</i>
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   <ins>constexpr</ins> bool operator==(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   <ins>constexpr</ins> bool operator!=(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   <ins>constexpr</ins> bool operator&lt; (const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   <ins>constexpr</ins> bool operator&lt;=(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   <ins>constexpr</ins> bool operator&gt; (const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   <ins>constexpr</ins> bool operator&gt;=(const  duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);

<i>// duration_cast</i>
template &lt;class ToDuration, class Rep, class Period&gt;
   <ins>constexpr</ins> ToDuration duration_cast(const duration&lt;Rep, Period&gt;&amp; d);
</pre>

</blockquote>

<p>
Change 20.10.3 [time.duration]:
</p>

<blockquote>

<pre>
template &lt;class Rep, class Period = ratio&lt;1&gt;&gt;
class duration {
  ...
public:
  ...
  <ins>constexpr</ins> duration(const duration&amp;) = default;
  ...

};
</pre>
</blockquote>
<p><i>[
Note - this edit already seems assumed by definition of the duration static members <tt>zero/min/max</tt>.
They cannot meaningfully be <tt>constexpr</tt> without this change.
]</i></p>






<hr>
<h3><a name="1173"></a>1173. "Equivalence" wishy-washiness</h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="lwg-active.html#NAD Future">Tentatively NAD Future</a>
 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-07-14  <b>Last modified:</b> 2010-08-25</p>
<p><b>View other</b> <a href="lwg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="lwg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively NAD Future">Tentatively NAD Future</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Issue: The <tt>CopyConstructible</tt> requirements are wishy-washy.  It requires
that the copy is "equivalent" to the original, but "equivalent" is never
defined.
</p>
<p>
I believe this to be an example of a more general lack of rigor around
copy and assignment, although I haven't done the research to dig up all
the instances.
</p>
<p>
It's a problem because if you don't know what <tt>CopyConstructible</tt> means,
you also don't know what it means to copy a pair of <tt>CopyConstructible</tt>
types.  It doesn't prevent us from writing code, but it is a hole in our
ability to understand the meaning of copy.
</p>
<p>
Furthermore, I'm pretty sure that vector's copy constructor doesn't
require the elements to be <tt>EqualityComparable</tt>, so that table is actually
referring to some ill-defined notion of equivalence when it uses ==.
</p>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Move to "Open". Dave is right that this is a big issue. Paper D2987
("Defining Move Special Member Functions", Bjarne Stroustrup and
Lawrence Crowl) touches on this but does not solve it. This issue is
discussed in Elements of Programming.
</blockquote>


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


<blockquote>
This issue is quite vague, so it is difficult to know if and when it has been resolved.

John Lakos wrote a paper covering this area a while back, and there is a real interest in providing some sort of clean-up in the future.

We need a more clearly draughted issues with an addressable set of concerns, ideally with a paper proposing a resolution, but for a future revision of the standard.

Move to Tentatively NAD Future.
</blockquote>



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





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

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

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

<blockquote>
<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.
</blockquote>



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


<blockquote>
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 unodered container to be sure.

Howard suggests NAD Editorial as we updated the container requirement tables since this issue was written.

Daniel offers to look deeper, and hopefully produce wording addressing any outstanding concerns at the next meeting.

Move to Open.
</blockquote>



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





<hr>
<h3><a name="1181"></a>1181. Invalid <tt>sub_match</tt> comparison operators</h3>
<p><b>Section:</b> 28.9.2 [re.submatch.op] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2009-07-25  <b>Last modified:</b> 2010-03-27</p>
<p><b>View all other</b> <a href="lwg-index.html#re.submatch.op">issues</a> in [re.submatch.op].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Several heterogeneous comparison operators of class template
<tt>sub_match</tt> are specified by return clauses that are not valid
in general. E.g. 28.9.2 [re.submatch.op]/7:
</p>

<blockquote><pre>
template &lt;class BiIter, class ST, class SA&gt;
bool operator==(
  const basic_string&lt;
    typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
  const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
<blockquote>
<i>Returns:</i> <tt>lhs == rhs.str()</tt>.
</blockquote>
</blockquote>

<p>
The returns clause would be ill-formed for all cases where
<tt>ST != std::char_traits&lt;iterator_traits&lt;BiIter&gt;::value_type&gt;</tt>
or <tt>SA != std::allocator&lt;iterator_traits&lt;BiIter&gt;::value_type&gt;</tt>.
</p>
<p>
The generic character of the comparison was intended, so
there are basically two approaches to fix the problem: The
first one would define the semantics of the comparison
using the traits class <tt>ST</tt> (The semantic of <tt>basic_string::compare</tt>
is defined in terms of the compare function of the corresponding
traits class), the second one would define the semantics of the
comparison using the traits class
</p>

<blockquote><pre>
std::char_traits&lt;iterator_traits&lt;BiIter&gt;::value_type&gt;
</pre></blockquote>

<p>
which is essentially identical to
</p>

<blockquote><pre>
std::char_traits&lt;sub_match&lt;BiIter&gt;::value_type&gt;
</pre></blockquote>

<p>
I suggest to follow the second approach, because
this emphasizes the central role of the <tt>sub_match</tt>
object as part of the comparison and would also
make sure that a <tt>sub_match</tt> comparison using some
<tt>basic_string&lt;char_t, ..&gt;</tt> always is equivalent to
a corresponding comparison with a string literal
because of the existence of further overloads (beginning
from 28.9.2 [re.submatch.op]/19). If users really want to
take advantage of their own <tt>traits::compare</tt>, they can
simply write a corresponding compare function that
does so.
</p>


<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
In 28.9.2 [re.submatch.op] change as indicated:
</p>

<blockquote>
<pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator==(
    const basic_string&lt;
      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
    const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
<blockquote>
7 <i>Returns:</i> <tt><del>lhs</del><ins>typename
sub_match&lt;BiIter&gt;::string_type(lhs.begin(), lhs.end())</ins> ==
rhs.str()</tt>.
</blockquote>

<pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator!=(
    const basic_string&lt;
      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
    const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>

<blockquote>
8 <i>Returns:</i> <tt><ins>!(lhs == rhs)</ins><del>lhs != rhs.str()</del></tt>.
</blockquote>

<pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator&lt;(
    const basic_string&lt;
      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
    const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>

<blockquote>
9 <i>Returns:</i> <tt><del>lhs</del><ins>typename
sub_match&lt;BiIter&gt;::string_type(lhs.begin(), lhs.end())</ins> &lt;
rhs.str()</tt>.
</blockquote>

<pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator&gt;(
    const basic_string&lt;
      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
    const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>

<blockquote>
10 <i>Returns:</i> <tt><ins>rhs &lt; lhs</ins><del>lhs &gt; rhs.str()</del></tt>.
</blockquote>

<pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator&gt;=(
    const basic_string&lt;
      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
    const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>

<blockquote>
11 <i>Returns:</i> <tt><ins>!(lhs &lt; rhs)</ins><del>lhs &gt;= rhs.str()</del></tt>.
</blockquote>

<pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator&lt;=(
    const basic_string&lt;
      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
    const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>

<blockquote>
12 <i>Returns:</i> <tt><ins>!(rhs &lt; lhs)</ins><del>lhs &lt;= rhs.str()</del></tt>.
</blockquote>

<pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator==(const sub_match&lt;BiIter&gt;&amp; lhs,
    const basic_string&lt;
      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
</pre>

<blockquote>
13 <i>Returns:</i> <tt>lhs.str() == <del>rhs</del><ins>typename
sub_match&lt;BiIter&gt;::string_type(rhs.begin(), rhs.end())</ins></tt>.
</blockquote>

<pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator!=(const sub_match&lt;BiIter&gt;&amp; lhs,
    const basic_string&lt;
      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
</pre>

<blockquote>
14 <i>Returns:</i> <tt><ins>!(lhs == rhs)</ins><del>lhs.str() != rhs</del></tt>.
</blockquote>

<pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator&lt;(const sub_match&lt;BiIter&gt;&amp; lhs,
    const basic_string&lt;
      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
</pre>

<blockquote>
15 <i>Returns:</i> <tt>lhs.str() &lt; <del>rhs</del><ins>typename
sub_match&lt;BiIter&gt;::string_type(rhs.begin(), rhs.end())</ins></tt>.
</blockquote>

<pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator&gt;(const sub_match&lt;BiIter&gt;&amp; lhs,
    const basic_string&lt;
      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
</pre>

<blockquote>
16 <i>Returns:</i> <tt><ins>rhs &lt; lhs</ins><del>lhs.str() &gt; rhs</del></tt>.
</blockquote>

<pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator&gt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
    const basic_string&lt;
      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
</pre>

<blockquote>
17 <i>Returns:</i> <tt><ins>!(lhs &lt; rhs)</ins><del>lhs.str() &gt;= rhs</del></tt>.
</blockquote>

<pre>
template &lt;class BiIter, class ST, class SA&gt;
  bool operator&lt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
    const basic_string&lt;
      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
</pre>

<blockquote>
18 <i>Returns:</i> <tt><ins>!(rhs &lt; lhs)</ins><del>lhs.str() &lt;= rhs</del></tt>.
</blockquote>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="1183"></a>1183. <tt>basic_ios::set_rdbuf</tt> may break class invariants</h3>
<p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2009-07-28  <b>Last modified:</b> 2009-10-22</p>
<p><b>View all other</b> <a href="lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The protected member function <tt>set_rdbuf</tt> had been added during the
process of adding move and swap semantics to IO classes. A relevant
property of this function is described by it's effects in
27.5.4.2 [basic.ios.members]/19:
</p>

<blockquote>
<i>Effects:</i> Associates the <tt>basic_streambuf</tt> object pointed to by sb with
this stream without calling <tt>clear()</tt>.
</blockquote>

<p>
This means that implementors of or those who derive from existing IO classes
could cause an internal state where the stream buffer could be 0, but the
IO class has the state <tt>good()</tt>. This would break several currently existing
implementations which rely on the fact that setting a stream buffer via the
currently only ways, i.e. either by calling
</p>

<blockquote><pre>
void init(basic_streambuf&lt;charT,traits&gt;* sb);
</pre></blockquote>

<p>
or by calling
</p>

<blockquote><pre>
basic_streambuf&lt;charT,traits&gt;* rdbuf(basic_streambuf&lt;charT,traits&gt;* sb);
</pre></blockquote>

<p>
to set <tt>rdstate()</tt> to <tt>badbit</tt>, if the buffer is 0. This has the effect that many
internal functions can simply check <tt>rdstate()</tt> instead of <tt>rdbuf()</tt> for being 0.
</p>

<p>
I therefore suggest that a requirement is added for callers of <tt>set_rdbuf</tt> to
set a non-0 value.
</p>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Moved to Open.  Martin volunteers to provide new wording, where
<tt>set_rdbuf()</tt> sets the <tt>badbit</tt> but does not cause an
exception to be thrown like a call to <tt>clear()</tt> would.
</blockquote>

<p><i>[
2009-10-20 Martin provides wording:
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Change 27.5.4.2 [basic.ios.members] around p. 19 as indicated:
</p>

<blockquote><pre>
void set_rdbuf(basic_streambuf&lt;charT, traits&gt;* sb);
</pre>

<blockquote>
<p><del>
<i>Effects:</i> Associates the <tt>basic_streambuf</tt> object pointed
to by <tt>sb</tt> with this stream without calling <tt>clear()</tt>.
<i>Postconditions:</i> <tt>rdbuf() == sb</tt>.
</del></p>

<p><ins>
<i>Effects:</i> As if:
</ins></p>

<blockquote><pre><ins>
iostate state = rdstate();
try { rdbuf(sb); }
catch(ios_base::failure) {
   if (0 == (state &amp; ios_base::badbit))
       unsetf(badbit);
}
</ins></pre></blockquote>

<p>
<i>Throws:</i> Nothing.
</p>

</blockquote>
</blockquote>


<p><b>Rationale:</b></p>
We need to be able to call <tt>set_rdbuf()</tt> on stream objects
for which (<tt>rdbuf() == 0</tt>) holds without causing <tt>ios_base::failure</tt> to
be thrown. We also don't want <tt>badbit</tt> to be set as a result of
setting <tt>rdbuf()</tt> to 0 if it wasn't set before the call. This changed
Effects clause maintains the current behavior (as of N2914) without
requiring that <tt>sb</tt> be non-null.





<hr>
<h3><a name="1188"></a>1188. Unordered containers should have a minimum load factor as well as a maximum</h3>
<p><b>Section:</b> 23.2.5 [unord.req], 23.5 [unord] <b>Status:</b> <a href="lwg-active.html#NAD Future">Tentatively NAD Future</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2009-08-10  <b>Last modified:</b> 2010-08-25</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively NAD Future">Tentatively NAD Future</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Unordered associative containers have a notion of a maximum load factor:
when the number of elements grows large enough, the containers
automatically perform a rehash so that the number of elements per bucket
stays below a user-specified bound. This ensures that the hash table's
performance characteristics don't change dramatically as the size
increases.
</p>

<p>
For similar reasons, Google has found it useful to specify a minimum
load factor: when the number of elements shrinks by a large enough, the
containers automatically perform a rehash so that the number of elements
per bucket stays above a user-specified bound. This is useful for two
reasons. First, it prevents wasting a lot of memory when an unordered
associative container grows temporarily. Second, it prevents amortized
iteration time from being arbitrarily large; consider the case of a hash
table with a billion buckets and only one element. (This was discussed
even before TR1 was published; it was TR issue 6.13, which the LWG
closed as NAD on the grounds that it was a known design feature.
However, the LWG did not consider the approach of a minimum load
factor.)
</p>

<p>
The only interesting question is when shrinking is allowed. In principle
the cleanest solution would be shrinking on erase, just as we grow on
insert. However, that would be a usability problem; it would break a
number of common idioms involving erase. Instead, Google's hash tables
only shrink on insert and rehash.
</p>

<p>
The proposed resolution allows, but does not require, shrinking in
rehash, mostly because a postcondition for rehash that involves the
minimum load factor would be fairly complicated. (It would probably have
to involve a number of special cases and it would probably have to
mention yet another parameter, a minimum bucket count.)
</p>

<p>
The current behavior is equivalent to a minimum load factor of 0. If we
specify that 0 is the default, this change will have no impact on
backward compatibility.
</p>


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


<blockquote>
This seems to a useful extension, but is too late for 0x.

Move to Tentatively NAD Future.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add two new rows, and change rehash's postcondition in the unordered
associative container requirements table in 23.2.5 [unord.req]:
</p>

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

<tr>
<th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
<th>Complexity</th>
</tr>
<tr>
<td><ins>
<tt>a.min_load_factor()</tt>
</ins></td>
<td><ins>
<tt>float</tt>
</ins></td>
<td><ins>
Returns a non-negative number that the container attempts to keep the
load factor greater than or equal to. The container automatically
decreases the number of buckets as necessary to keep the load factor
above this number.
</ins></td>
<td><ins>
constant
</ins></td>
</tr>

<tr>
<td><ins><tt>a.min_load_factor(z)</tt></ins></td>
<td><ins><tt>void</tt></ins></td>
<td><ins>Pre: <tt>z</tt> shall be non-negative. Changes the container's minimum
load factor, using <tt>z</tt> as a hint. [<i>Footnote:</i> the minimum
load factor should be significantly smaller than the maximum. 
If <tt>z</tt> is too large, the implementation may reduce it to a more sensible value.]
</ins></td>
<td><ins>
constant
</ins></td>
</tr>
<tr>
<td><tt>a.rehash(n)</tt></td>
<td><tt>void</tt></td>
<td>
Post: <ins><tt>a.bucket_count() &gt;= n</tt>, and <tt>a.size() &lt;= a.bucket_count()
* a.max_load_factor()</tt>. [<i>Footnote:</i> It is intentional that the
postcondition does not mention the minimum load factor.
This member function is primarily intended for cases where the user knows
that the container's size will increase soon, in which case the container's
load factor will temporarily fall below <tt>a.min_load_factor()</tt>.]</ins>
<del>
<tt>a.bucket_cout &gt; a.size() / a.max_load_factor()</tt> and <tt>a.bucket_count()
&gt;= n</tt>.
</del>
</td>
<td>
Average case linear in <tt>a.size()</tt>, worst case quadratic.
</td>
</tr>
</table>
</blockquote>

<p>
Add a footnote to 23.2.5 [unord.req] p12:
</p>

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

<blockquote><ins>
[A consequence of these requirements is that while insert may change the
number of buckets, erase may not. The number of buckets may be reduced
on calls to insert or rehash.]
</ins></blockquote>
</blockquote>

<p>
Change paragraph 13:
</p>

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

<p>
Add to the <tt>unordered_map</tt> class synopsis in section 23.5.1 [unord.map],
the <tt>unordered_multimap</tt> class synopsis
in 23.5.2 [unord.multimap], the <tt>unordered_set</tt> class synopsis in
23.5.3 [unord.set], and the <tt>unordered_multiset</tt> class synopsis
in 23.5.4 [unord.multiset]:
</p>

<blockquote><pre><ins>
float min_load_factor() const;
void min_load_factor(float z);
</ins></pre></blockquote>

<p>
In 23.5.1.1 [unord.map.cnstr], 23.5.2.1 [unord.multimap.cnstr], 23.5.3.1 [unord.set.cnstr], and
23.5.4.1 [unord.multiset.cnstr], change:
</p>

<blockquote>
... <tt>max_load_factor()</tt> returns 1.0 <ins>and
<tt>min_load_factor()</tt> returns 0</ins>.
</blockquote>





<hr>
<h3><a name="1190"></a>1190. Setting the maximum load factor should return the previous value</h3>
<p><b>Section:</b> 23.2.5 [unord.req], 23.5 [unord] <b>Status:</b> <a href="lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2009-08-10  <b>Last modified:</b> 2010-08-25</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively NAD">Tentatively NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The unordered associative container requirements table specifies that
<tt>a.set_max_load_factor(z)</tt> has return type <tt>void</tt>. However, there is a
useful piece of information to return: the previous value. Users who
don't need it can always ignore it.
</p>


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


<blockquote>
The benefit seems minor, while breaking with the getter/setter idiom these overloads support.

Move to Tentatively NAD.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
In the unordered associative container requirements table, change:
</p>

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

<tr>
<th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td><tt>a.max_load_factor(z)</tt></td>
<td><tt><del>void</del> <ins>float</ins></tt></td>
<td>Pre: <tt>z</tt> shall be positive. Changes the container's maximum
<del>load</del> load factor, using <tt>z</tt> as a hint.
<ins>Returns: the previous value of
<tt>a.max_load_factor()</tt>.</ins>
</td>
<td>
constant
</td>
</tr>
<tr></tr>
</table>
</blockquote>

<p>
Change the return type of <tt>set_max_load_factor</tt>
in the class synopses in 23.5.1 [unord.map], 23.5.2 [unord.multimap],  23.5.3 [unord.set],
and 23.5.4 [unord.multiset].
</p>

<p>
If issue <a href="lwg-active.html#1188">1188</a> is also accepted, make the same changes for
<tt>min_load_factor</tt>.
</p>





<hr>
<h3><a name="1191"></a>1191. <tt>tuple get</tt> API should respect rvalues</h3>
<p><b>Section:</b> 20.4.2.6 [tuple.elem] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-08-18  <b>Last modified:</b> 2010-08-25</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>tuple get</tt> API should respect rvalues.  This would allow for moving a
single element out of a <tt>tuple</tt>-like type.
</p>

<p><i>[
2009-10-30 Alisdair adds:
]</i></p>


<blockquote>
<p>
The issue of rvalue overloads of get for tuple-like types was briefly
discussed in Santa Cruz.
</p>

<p>
The feedback was this would be welcome, but we need full wording for the
other types (<tt>pair</tt> and <tt>array</tt>) before advancing.
</p>

<p>
I suggest the issue moves to Open from New as it has been considered,
feedback given, and it has not (yet) been rejected as NAD.
</p>
</blockquote>


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


<blockquote>
Note that wording has been provided, and this issue becomes more important now that we have added a function to support forwarding argument lists as <tt>tuple</tt>s.

Move to Tentatively Ready.
</blockquote>




<p><b>Proposed resolution:</b></p>
<p>
Add the following signature to p2 20.4.1 [tuple.general]
</p>

<blockquote><pre><ins>
template &lt;size_t I, class ... Types&gt;
typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp;&amp; get(tuple&lt;Types...&gt; &amp;&amp;);
</ins></pre></blockquote>

<p>
And again to 20.4.2.6 [tuple.elem].
</p>

<blockquote><pre><ins>
template &lt;size_t I, class ... Types&gt;
typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp;&amp; get(tuple&lt;Types...&gt;&amp;&amp; t);
</ins></pre>

<blockquote>
<p><ins>
<i>Effects:</i> Equivalent to <tt>return std::forward&lt;typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp;&amp;&gt;(get&lt;I&gt;(t));</tt>
</ins></p>


<p><ins>
[<i>Note:</i> If a <tt>T</tt> in <tt>Types</tt> is some reference type <tt>X&amp;</tt>,
the return type is <tt>X&amp;</tt>, not <tt>X&amp;&amp;</tt>.
However, if the element type is non-reference type <tt>T</tt>,
the return type is <tt>T&amp;&amp;</tt>. &mdash; <i>end note</i>]
</ins></p>

</blockquote>
</blockquote>

<p>
Add the following signature to p1 20.3 [utility]
</p>

<blockquote><pre><ins>
template &lt;size_t I, class T1, class T2&gt;
typename tuple_element&lt;I, pair&lt;T1,T2&gt; &gt;::type&amp;&amp; get(pair&lt;T1, T2&gt;&amp;&amp;);
</ins></pre></blockquote>

<p>
And to p5 20.3.5.3 [pair.astuple]
</p>

<blockquote><pre><ins>
template &lt;size_t I, class T1, class T2&gt;
typename tuple_element&lt;I, pair&lt;T1,T2&gt; &gt;::type&amp;&amp; get(pair&lt;T1, T2&gt;&amp;&amp; p);
</ins></pre>

<blockquote>
<p><ins>
<i>Returns:</i> If <tt>I == 0</tt> returns <tt>std::forward&lt;T1&amp;&amp;&gt;(p.first)</tt>;
if <tt>I == 1</tt>
returns <tt>std::forward&lt;T2&amp;&amp;&gt;(p.second)</tt>; otherwise the program is ill-formed.
</ins></p>

<p><ins>
<i>Throws:</i> Nothing.
</ins></p>

</blockquote>

</blockquote>

<p>
Add the following signature to 23.3 [sequences] <tt>&lt;array&gt;</tt> synopsis
</p>

<blockquote><pre><ins>template &lt;size_t I, class T, size_t N&gt;
T&amp;&amp; get(array&lt;T,N&gt; &amp;&amp;);
</ins></pre></blockquote>

<p>
And after p8 23.3.1.8 [array.tuple]
</p>

<blockquote><pre>
<ins>template &lt;size_t I, class T, size_t N&gt;
T&amp;&amp; get(array&lt;T,N&gt; &amp;&amp; a);
</ins></pre>

<blockquote><ins>
<i>Effects:</i> Equivalent to <tt>return std::move(get&lt;I&gt;(a));</tt>
</ins></blockquote>
</blockquote>






<hr>
<h3><a name="1198"></a>1198. Container adaptor swap: member or non-member?</h3>
<p><b>Section:</b> 23.3.5 [container.adaptors] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-08-26  <b>Last modified:</b> 2010-08-25</p>
<p><b>View all other</b> <a href="lwg-index.html#container.adaptors">issues</a> in [container.adaptors].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Under 23.3.5 [container.adaptors] of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>
the member function of <tt>swap</tt> of <tt>queue</tt> and <tt>stack</tt> call:
</p>

<blockquote><pre>
swap(c, q.c);
</pre></blockquote>

<p>
But under 23.3.5 [container.adaptors] of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
these members are specified to call:
</p>

<blockquote><pre>
c.swap(q.c);
</pre></blockquote>

<p>
Neither draft specifies the semantics of member <tt>swap</tt> for
<tt>priority_queue</tt> though it is declared.
</p>

<p>
Although the distinction between member <tt>swap</tt> and non-member
<tt>swap</tt> is not important when these adaptors are adapting standard
containers, it may be important for user-defined containers.
</p>
<p>
We (Pablo and Howard) feel that
it is more likely for a user-defined container to support a namespace scope
<tt>swap</tt> than a member <tt>swap</tt>, and therefore these adaptors
should use the container's namespace scope <tt>swap</tt>.
</p>

<p><i>[
2009-09-30 Daniel adds:
]</i></p>


<blockquote>
The outcome of this issue should be considered with the outcome of <a href="lwg-defects.html#774">774</a> both in style and in content (e.g. <a href="lwg-defects.html#774">774</a> bullet 9
suggests to define the semantic of <tt>void
priority_queue::swap(priority_queue&amp;)</tt> in terms of the member
<tt>swap</tt> of the container).
</blockquote>

<p><i>[
2010-03-28 Daniel update to diff against N3092.
]</i></p>



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


<blockquote>
Preference to move the wording into normative text, rather than inline function definitions in the class synopsis.

Move to Tenatively Ready.
</blockquote>



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

<p>
Change 23.3.5.1.1 [queue.defn]:
</p>

<blockquote><pre>
template &lt;class T, class Container = deque&lt;T&gt; &gt; 
class queue {
   ...
   void swap(queue&amp; q) { <ins>using std::swap;</ins>
                          <del>c.</del>swap(<ins>c, </ins>q.c); }
   ...
};
</pre></blockquote>

<p>
Change 23.3.5.2 [priority.queue]:
</p>

<blockquote><pre>
template &lt;class T, class Container = vector&lt;T&gt;, 
          class Compare = less&lt;typename Container::value_type&gt; &gt; 
class priority_queue { 
    ...
    void swap(priority_queue&amp; <ins>q</ins>)<del>;</del> <ins>{ using std::swap;</ins>
                                     <ins>swap(c, q.c);</ins>
                                     <ins>swap(comp, q.comp); }</ins>
    ...
};
</pre></blockquote>

<p>
Change 23.3.5.3.1 [stack.defn]:
</p>

<blockquote><pre>
template &lt;class T, class Container = deque&lt;T&gt; &gt; 
class stack {
   ...
   void swap(stack&amp; s) { <ins>using std::swap;</ins>
                          <del>c.</del>swap(<ins>c, </ins>s.c); }
   ...
};
</pre></blockquote>






<hr>
<h3><a name="1200"></a>1200. "surprising" <tt>char_traits&lt;T&gt;::int_type</tt> requirements</h3>
<p><b>Section:</b> 21.2.2 [char.traits.typedefs] <b>Status:</b> <a href="lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> Sean Hunt <b>Opened:</b> 2009-09-03  <b>Last modified:</b> 2010-08-25</p>
<p><b>View all other</b> <a href="lwg-index.html#char.traits.typedefs">issues</a> in [char.traits.typedefs].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively NAD">Tentatively NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The footnote for <tt>int_type</tt> in 21.2.2 [char.traits.typedefs] says that
</p>

<blockquote>
If <tt>eof()</tt>
can be held in <tt>char_type</tt> then some iostreams implementations may give
surprising results.
</blockquote>

<p>
This implies that <tt>int_type</tt> should be a superset of
<tt>char_type</tt>. However, the requirements for <tt>char16_t</tt> and <tt>char32_t</tt> define
<tt>int_type</tt> to be equal to <tt>int_least16_t</tt> and <tt>int_least32_t</tt> respectively.
<tt>int_least16_t</tt> is likely to be the same size as <tt>char_16_t</tt>, which may lead
to surprising behavior, even if <tt>eof()</tt> is not a valid UTF-16 code unit.
The standard should not prescribe surprising behavior, especially
without saying what it is (it's apparently not undefined, just
surprising). The same applies for 32-bit types.
</p>

<p>
I personally recommend that behavior be undefined if <tt>eof()</tt> is a member
of <tt>char_type</tt>, and another type be chosen for <tt>int_type</tt> (my personal
favorite has always been a <tt>struct {bool eof; char_type c;}</tt>).
Alternatively, the exact results of such a situation should be defined,
at least so far that I/O could be conducted on these types as long as
the code units remain valid. Note that the argument that no one streams
<tt>char16_t</tt> or <tt>char32_t</tt> is not really valid as it would be perfectly
reasonable to use a <tt>basic_stringstream</tt> in conjunction with UTF character
types.
</p>

<p><i>[
2009-10-28 Ganesh provides two possible resolutions and expresses a preference
for the second:
]</i></p>


<blockquote>
<ol>
<li>
<p>
Replace 21.2.3.2 [char.traits.specializations.char16_t] para 3 with:
</p>

<blockquote>
The member <tt>eof()</tt> shall return <del>an implementation-defined
constant that cannot appear as a valid UTF-16 code unit</del>
<ins><tt>UINT_LEAST16_MAX</tt> [<i>Note:</i> this value is guaranteed to
be a permanently reserved UCS-2 code position if <tt>UINT_LEAST16_MAX ==
0xFFFF</tt> and it's not a UCS-2 code position otherwise &mdash; <i>end
note</i>]</ins>.
</blockquote>

<p>
Replace 21.2.3.3 [char.traits.specializations.char32_t] para 3 with:
</p>

<blockquote>
The member <tt>eof()</tt> shall return <del>an implementation-defined constant that
cannot appear as a Unicode code point</del>
<ins>
<tt>UINT_LEAST32_MAX</tt> [<i>Note:</i> this value is guaranteed to be a
permanently reserved UCS-4 code position if <tt>UINT_LEAST32_MAX ==
0xFFFFFFFF</tt> and it's not a UCS-4 code position otherwise &mdash; <i>end
note</i>]</ins>.
</blockquote>
</li>
<li>
<p>
In 21.2.3.2 [char.traits.specializations.char16_t], in the
definition of <tt>char_traits&lt;char16_t&gt;</tt> replace the definition of nested
typedef <tt>int_type</tt> with:
</p>

<blockquote><pre>
namespace std {
  template&lt;&gt; struct char_traits&lt;char16_t&gt; {
    typedef char16_t         char_type;
    typedef <del>uint_least16_t</del> <ins>uint_fast16_t</ins> int_type;
     ...
</pre></blockquote>

<p>
Replace 21.2.3.2 [char.traits.specializations.char16_t] para 3 with:
</p>

<blockquote>
The member <tt>eof()</tt> shall return <del>an implementation-defined
constant that cannot appear as a valid UTF-16 code unit</del>
<ins><tt>UINT_FAST16_MAX</tt> [<i>Note:</i> this value is guaranteed to
be a permanently reserved UCS-2 code position if <tt>UINT_FAST16_MAX ==
0xFFFF</tt> and it's not a UCS-2 code position otherwise &mdash; <i>end
note</i>]</ins>.
</blockquote>

<p>
In 21.2.3.3 [char.traits.specializations.char32_t], in the
definition of <tt>char_traits&lt;char32_t&gt;</tt> replace the definition of nested
typedef <tt>int_type</tt> with:
</p>

<blockquote><pre>
namespace std {
  template&lt;&gt; struct char_traits&lt;char32_t&gt; {
    typedef char32_t         char_type;
    typedef <del>uint_least32_t</del> <ins>uint_fast32_t</ins> int_type;
     ...
</pre></blockquote>

<p>
Replace 21.2.3.3 [char.traits.specializations.char32_t] para 3 with:
</p>

<blockquote>
The member <tt>eof()</tt> shall return <del>an implementation-defined constant that
cannot appear as a Unicode code point</del>
<ins>
<tt>UINT_FAST32_MAX</tt> [<i>Note:</i> this value is guaranteed to be a
permanently reserved UCS-4 code position if <tt>UINT_FAST32_MAX ==
0xFFFFFFFF</tt> and it's not a UCS-4 code position otherwise &mdash; <i>end
note</i>]</ins>.
</blockquote>
</li>
</ol>
</blockquote>


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


<blockquote>
This seems an overspecification, and it is not clear what problem is being solved - these values can be used portably by using the named functions; there is no need for the value itself to be portable.

Move to Tentatively NAD.
</blockquote>



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





<hr>
<h3><a name="1207"></a>1207. Underspecified std::list operations?</h3>
<p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Lo&iuml;c Joly <b>Opened:</b> 2009-09-13  <b>Last modified:</b> 2010-08-25</p>
<p><b>View other</b> <a href="lwg-index-open.html#list.ops">active issues</a> in [list.ops].</p>
<p><b>View all other</b> <a href="lwg-index.html#list.ops">issues</a> in [list.ops].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It looks to me like some operations of <tt>std::list</tt>
(<tt>sort</tt>, <tt>reverse</tt>, <tt>remove</tt>, <tt>unique</tt> &amp;
<tt>merge</tt>) do not specify the validity of iterators, pointers &amp;
references to elements of the list after those operations. Is it implied
by some other text in the standard?
</p>

<p>
I believe <tt>sort</tt> &amp; <tt>reverse</tt> do not invalidating
anything, <tt>remove</tt> &amp; <tt>unique</tt> only invalidates what
refers to erased elements, <tt>merge</tt> does not invalidate anything
(with the same precision as <tt>splice</tt> for elements who changed of
container). Are those assumptions correct ?
</p>

<p><i>[
2009-12-08 Jonathan Wakely adds:
]</i></p>


<blockquote>
<p>
23.2.1 [container.requirements.general] paragraph 11 says iterators
aren't invalidated unless specified, so I don't think it needs to be repeated on
every function that doesn't invalidate iterators. <tt>list::unique</tt> says it
"eliminates" elements, that should probably be "erases" because IMHO that term
is used elsewhere and so makes it clearer that iterators to the erased elements
are invalidated.
</p>

<p>
<tt>list::merge</tt> coud use the same wording as <tt>list::splice</tt> w.r.t
iterators and references to moved elements.
</p>

<p>
Suggested resolution:
</p>

<p>
In 23.3.4.4 [list.ops] change paragraph 19
</p>

<blockquote><pre>
                                 void unique();
template &lt;class BinaryPredicate&gt; void unique(BinaryPredicate binary_pred);
</pre>
<blockquote>
<i>Effects:</i> <del>Eliminates</del> <ins>Erases</ins> all but the first
element from every consecutive group ...
</blockquote>
</blockquote>

<p>
Add to the end of paragraph 23
</p>

<blockquote><pre>
void                          merge(list&lt;T,Allocator&gt;&amp;&amp; x);
template &lt;class Compare&gt; void merge(list&lt;T,Allocator&gt;&amp;&amp; x, Compare comp);
</pre>
<blockquote>
<p>...</p>
<p>
<i>Effects:</i> ... that is, for every iterator <tt>i</tt>, in the range other
than the first, the condition <tt>comp(*i, *(i - 1)</tt> will be false.
<ins>Pointers and references to the moved elements of <tt>x</tt> now refer to
those same elements but as members of <tt>*this</tt>. Iterators referring to the
moved elements will continue to refer to their elements, but they now behave as
iterators into <tt>*this</tt>, not into <tt>x</tt>.</ins>
</p>
</blockquote>
</blockquote>
</blockquote>

<p><i>[
2009-12-12 Lo&iuml;c adds wording.
]</i></p>


<p><i>[
2010-02-10 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


<p><i>[
2010-02-10 Alisdair opens:
]</i></p>


<blockquote>
<p>
I object to the current resolution of #1207.  I believe it is overly strict with
regard to <tt>list</tt> end iterators, being the only mutating operations to
require such stability.
</p>

<p>
More importantly, the same edits need to be applied to <tt>forward_list</tt>,
which uses slightly different words to describe some of these operations so may
require subtly different edits (not checked.)
</p>

<p>
I am prepared to pick up the <tt>end()</tt> iterator as a separate (new) issue,
as part of the FCD ballot review (BSI might tell me 'no' first ;~) but I do want
to see <tt>forward_list</tt> adjusted at the same time.
</p>
</blockquote>

<p><i>[
2010-03-28 Daniel adds the first 5 bullets in an attempt to address Alisdair's
concerns.
]</i></p>



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


<blockquote>
The wording looks good.

Move to Tentatively Ready.
</blockquote>



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

<ol>

<li>
<p>
Change 23.3.3.5 [forwardlist.ops]/12 as indicated:
</p>

<blockquote><pre>
void remove(const T&amp; value);
template &lt;class Predicate&gt; void remove_if(Predicate pred);
</pre>

<blockquote>
12 <i>Effects:</i> Erases all the elements in the list referred by a list
iterator <tt>i</tt> for which the following conditions hold: <tt>*i == value
(for remove()), pred(*i)</tt> is true (<tt>for remove_if()</tt>). This operation
shall be stable: the relative order of the elements that are not removed is the
same as their relative order in the original list. <ins>Invalidates only the
iterators and references to the erased elements.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.3.5 [forwardlist.ops]/15 as indicated:
</p>

<blockquote><pre>
template &lt;class BinaryPredicate&gt; void unique(BinaryPredicate pred);
</pre>

<blockquote>
15 <i>Effects:</i>: <del>Eliminates</del><ins>Erases</ins> all but the first
element from every consecutive group of equal elements referred to by the
iterator <tt>i</tt> in the range <tt>[first + 1,last)</tt> for which <tt>*i ==
*(i-1)</tt> (for the version with no arguments) or <tt>pred(*i, *(i - 1))</tt>
(for the version with a predicate argument) holds. <ins>Invalidates only the
iterators and references to the erased elements.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.3.5 [forwardlist.ops]/19 as indicated:
</p>

<blockquote><pre>
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;&amp; x, Compare comp)
</pre>

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

<p>
19 <i>Effects:</i>: Merges <tt>x</tt> into <tt>*this</tt>. This operation shall
be stable: for equivalent elements in the two lists, the elements from
<tt>*this</tt> shall always precede the elements from <tt>x</tt>. <tt>x</tt> is
empty after the merge. If an exception is thrown other than by a comparison
there are no effects. <ins>Pointers and references to the moved elements of
<tt>x</tt> now refer to those same elements but as members of <tt>*this</tt>.
Iterators referring to the moved elements will continue to refer to their
elements, but they now behave as iterators into <tt>*this</tt>, not into
<tt>x</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.3.5 [forwardlist.ops]/22 as indicated:
</p>

<blockquote><pre>
void sort();
template &lt;class Compare&gt; void sort(Compare comp);
</pre>

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

<p>
22 <i>Effects:</i>: Sorts the list according to the <tt>operator&lt;</tt> or the
<tt>comp</tt> function object. This operation shall be stable: the relative
order of the equivalent elements is preserved. If an exception is thrown the
order of the elements in <tt>*this</tt> is unspecified. <ins>Does not affect the
validity of iterators and references.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.3.5 [forwardlist.ops]/24 as indicated:
</p>

<blockquote><pre>
void reverse();
</pre>

<blockquote>
24 <i>Effects:</i>: Reverses the order of the elements in the list. <ins>Does
not affect the validity of iterators and references.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.4.4 [list.ops], p15:
</p>

<blockquote><pre>
                           void remove(const T&amp; value);
template &lt;class Predicate&gt; void remove_if(Predicate pred);
</pre>
<blockquote>
<i>Effects:</i> Erases all the elements in the list referred by a list iterator
<tt>i</tt> for which the following conditions hold: <tt>*i == value, pred(*i) !=
false</tt>.  <ins>Invalidates only the iterators and references to the erased
elements.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.4.4 [list.ops], p19:
</p>

<blockquote><pre>
                                 void unique();
template &lt;class BinaryPredicate&gt; void unique(BinaryPredicate binary_pred);
</pre>
<blockquote>
<i>Effects:</i> <del>Eliminates</del> <ins>Erases</ins> all but the first
element from every consecutive group of equal elements referred to by the
iterator <tt>i</tt> in the range <tt>[first + 1,last)</tt> for which <tt>*i ==
*(i-1)</tt> (for the version of <tt>unique</tt> with no arguments) or
<tt>pred(*i, *(i - 1))</tt> (for the version of <tt>unique</tt> with a predicate
argument) holds. <ins>Invalidates only the iterators and references to the
erased elements.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.4.4 [list.ops], p23:
</p>

<blockquote><pre>
void                          merge(list&lt;T,Allocator&gt;&amp;&amp; x);
template &lt;class Compare&gt; void merge(list&lt;T,Allocator&gt;&amp;&amp; x, Compare comp);
</pre>
<blockquote>
<i>Effects:</i> If <tt>(&amp;x == this)</tt> does nothing; otherwise, merges the
two sorted ranges <tt>[begin(), end())</tt> and <tt>[x.begin(), x.end())</tt>.
The result is a range in which the elements will be sorted in non-decreasing
order according to the ordering defined by <tt>comp</tt>; that is, for every
iterator <tt>i</tt>, in the range other than the first, the condition
<tt>comp(*i, *(i - 1)</tt> will be false.
<ins>Pointers and references to the moved elements of <tt>x</tt> now refer to
those same elements but as members of <tt>*this</tt>. Iterators referring to the
moved elements will continue to refer to their elements, but they now behave as
iterators into <tt>*this</tt>, not into <tt>x</tt>.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.4.4 [list.ops], p26:
</p>

<blockquote><pre>
void reverse();
</pre>
<blockquote>
<i>Effects:</i> Reverses the order of the elements in the list.
<ins>Does not affect the validity of iterators and references.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.4.4 [list.ops], p30:
</p>

<blockquote><pre>
                         void sort();
template &lt;class Compare&gt; void sort(Compare comp);
</pre>
<blockquote>
<i>Effects:</i> Sorts the list according to the <tt>operator&lt;</tt> or a
<tt>Compare</tt> function object.
<ins>Does not affect the validity of iterators and references.</ins>
</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#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2009-09-19  <b>Last modified:</b> 2009-09-19</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#New">New</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>
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.
</blockquote>

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

<blockquote>
An iterator is valid if it is dereferenceable or past-the-end.
</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.9.9 [specialized.algorithms]/1 says:
</p>

<blockquote>
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.
</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>
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>]
</blockquote>

<p>
[..]
</p>

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

<blockquote>
<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.
</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><b>Proposed resolution:</b></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#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2009-09-20  <b>Last modified:</b> 2010-03-27</p>
<p><b>View other</b> <a href="lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
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>
[..] Keys in an associative container are immutable.
</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>
This update attempts to provide normative wording that harmonizes the key and
function object constraints of associative and unordered containers.
</blockquote>



<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>
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.
</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>
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>
</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>
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>
</blockquote>
</li>

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

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

</ol>






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


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

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





<hr>
<h3><a name="1234"></a>1234. "Do the right thing" and NULL</h3>
<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2009-10-09  <b>Last modified:</b> 2010-03-21</p>
<p><b>View all other</b> <a href="lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
On g++ 4.2.4 (x86_64-linux-gnu), the following file gives a compile
error:
</p>

<blockquote><pre>
#include &lt;vector&gt;
void foo() { std::vector&lt;int*&gt; v(500l, NULL); }
</pre></blockquote>

<p>
Is this supposed to work? 
</p>

<p>
The issue: if <tt>NULL</tt> happens to be defined as <tt>0l</tt>, this is an invocation of
the constructor with two arguments of the same integral type.
23.2.3 [sequence.reqmts]/14
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3035.pdf">N3035</a>)
says that this will behave as if the the
overloaded constructor
</p>

<blockquote><pre>
X(size_type, const value_type&amp; = value_type(),
  const allocator_type&amp; = allocator_type())
</pre></blockquote>

<p>
were called instead, with the arguments
<tt>static_cast&lt;size_type&gt;(first)</tt>, <tt>last</tt> and
<tt>alloc</tt>, respectively. However, it does not say whether this
actually means invoking that constructor with the exact textual form of
the arguments as supplied by the user, or whether the standard permits
an implementation to invoke that constructor with variables of the same
type and value as what the user passed in. In most cases this is a
distinction without a difference. In this particular case it does make a
difference, since one of those things is a null pointer constant and the
other is not.
</p>

<p>
Note that an implementation based on forwarding functions will use the
latter interpretation.
</p>

<p><i>[
2010 Pittsburgh:  Moved to Open.
]</i></p>


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


<blockquote>
<ul>
<li>
Adapts the numbering used in the discussion to the recent working paper
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3035.pdf">N3035</a>.
</li>

<li>
Proposes a resolution that requires implementations to use sfinae-like means to
possibly filter away the too generic template c'tor. In fact this resolution is
equivalent to that used for the <tt>pair-NULL</tt> problem (<a href="lwg-defects.html#811">811</a>),
the only difference is, that issue 1234 was already a C++03 problem.
</li>
</ul>

<p>
This issue can be considered as a refinement of <a href="lwg-defects.html#438">438</a>.
</p>

</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 23.2.3 [sequence.reqmts]/14+15
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3035.pdf">N3035</a>)
as indicated:
</p>

<blockquote>
<p>
14 For every sequence container defined in this Clause and in Clause 21:
</p>

<ul>
<li>
<p>
If the constructor
</p>

<blockquote><pre>
template &lt;class InputIterator&gt;
X(InputIterator first, InputIterator last,
  const allocator_type&amp; alloc = allocator_type())
</pre></blockquote>

<p>
is called with a type <tt>InputIterator</tt> that does not qualify as an input
iterator, then
the constructor <ins>shall not participate in overload
resolution</ins><del>will
behave as if the overloaded constructor:</del>
</p>

<blockquote><pre><del>
X(size_type, const value_type& = value_type(),
  const allocator_type& = allocator_type())
</del></pre></blockquote>

<p>
<del>were called instead, with the arguments
<tt>static_cast&lt;size_type&gt;(first)</tt>, <tt>last</tt> and <tt>alloc</tt>,
respectively</del>.
</p>
</li>

<li>
<p>
If the member functions of the forms:
</p>

<blockquote><pre>
template &lt;class InputIterator&gt; <i>// such as insert()</i>
rt fx1(iterator p, InputIterator first, InputIterator last);

template &lt;class InputIterator&gt; <i>// such as append(), assign()</i>
rt fx2(InputIterator first, InputIterator last);

template &lt;class InputIterator&gt; <i>// such as replace()</i>
rt fx3(iterator i1, iterator i2, InputIterator first, InputIterator last);
</pre></blockquote>

<p>
are called with a type <tt>InputIterator</tt> that does not qualify as an input
iterator, then these functions <ins>shall not participate in overload
resolution</ins><del>will behave as if the overloaded member functions:</del>
</p>

<blockquote><pre>
<del>rt fx1(iterator, size_type, const value_type&amp;);</del>

<del>rt fx2(size_type, const value_type&amp;);</del>

<del>rt fx3(iterator, iterator, size_type, const value_type&amp;);</del>
</pre></blockquote>

<p>
<del>were called instead, with the same arguments.</del>
</p>
</li>

</ul>

<p><del>
15 In the previous paragraph the alternative binding will fail if <tt>first</tt>
is not implicitly convertible to <tt>X::size_type</tt> or if <tt>last</tt> is
not implicitly convertible to <tt>X::value_type</tt>.
</del></p>
</blockquote>






<hr>
<h3><a name="1240"></a>1240. Deleted comparison functions of std::function not  needed</h3>
<p><b>Section:</b> 20.8.14.2 [func.wrap.func] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2009-10-18  <b>Last modified:</b> 2009-10-19</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The class template <tt>std::function</tt> contains the following member
declarations:
</p>

<blockquote><pre>
// deleted overloads close possible hole in the type system
template&lt;class R2, class... ArgTypes2&gt;
  bool operator==(const function&lt;R2(ArgTypes2...)&gt;&amp;) = delete;
template&lt;class R2, class... ArgTypes2&gt;
  bool operator!=(const function&lt;R2(ArgTypes2...)&gt;&amp;) = delete;
</pre></blockquote>

<p>
The leading comment here is part of the history of <tt>std::function</tt>, which
was introduced with <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1402.html#undefined_operators">N1402</a>.
During that time no explicit conversion functions existed, and the
"safe-bool" idiom (based on pointers-to-member) was a popular
technique. The only disadvantage of this idiom was that given two
objects <tt>f1</tt> and <tt>f2</tt> of type <tt>std::function</tt> the expression
</p>

<blockquote><pre>
f1 == f2;
</pre></blockquote>

<p>
was well-formed, just because the built-in <tt>operator==</tt> for pointer to member
was considered after a single user-defined conversion. To fix this, an
overload set of <em>undefined</em> comparison functions was added,
such that overload resolution would prefer those ending up in a linkage error.
The new language facility of deleted functions provided a much better
diagnostic mechanism to fix this issue.
</p>

<p>
The central point of this issue is, that with the replacement of the
safe-bool idiom by explicit conversion to bool the original "hole in the
type system" does no longer exist and therefore the comment is wrong and
the superfluous function definitions should be removed as well. An
explicit conversion function is considered in direct-initialization
situations only, which indirectly contain the so-called "contextual
conversion to bool" (4 [conv]/3). These conversions are not considered for
<tt>==</tt> or <tt>!=</tt> as defined by the core language.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In 20.8.14.2 [func.wrap.func]/1, class function change as indicated:
</p>

<blockquote><pre>
// 20.7.15.2.3, function capacity:
explicit operator bool() const;

<del>// deleted overloads close possible hole in the type system</del>
<del>template&lt;class R2, class... ArgTypes2&gt;</del>
  <del>bool operator==(const function&lt;R2(ArgTypes2...)&gt;&amp;) = delete;</del>
<del>template&lt;class R2, class... ArgTypes2&gt;</del>
  <del>bool operator!=(const function&lt;R2(ArgTypes2...)&gt;&amp;) = delete;</del>
</pre></blockquote>





<hr>
<h3><a name="1249"></a>1249. basic_ios default ctor</h3>
<p><b>Section:</b> 27.5.4.1 [basic.ios.cons] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2009-10-25  <b>Last modified:</b> 2009-10-26</p>
<p><b>View all other</b> <a href="lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The basic_ios default ctor is required to leave the objects members
uninitialized (see below). The paragraph says the object must be
initialized by calling basic_ios::init() before it's destroyed by
I can't find a requirement that it be initialized before calling
any of the class other member functions. Am I not looking in the
right place or that an issue?
</p>

<p><i>[
2009-10-25 Daniel adds:
]</i></p>


<blockquote>
<p>
I agree, that your wording makes that clearer, but suggest to write
</p>

<blockquote>
... calling <tt>basic_ios::init<del>()</del></tt> before ...
</blockquote>

<p>
Doing so, I recommend to adapt that of <tt>ios_base();</tt> as well, where
we have:
</p>

<blockquote>
<i>Effects:</i> Each <tt>ios_base</tt> member has an indeterminate value
after construction. These members shall be initialized by calling
<tt>basic_ios::init</tt>. If an <tt>ios_base</tt> object is destroyed
before these initializations have taken place, the behavior is
undefined.
</blockquote>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 27.5.2.7 [ios.base.cons] p1:
</p>

<blockquote><pre>
ios_base();
</pre>
<blockquote>
<i>Effects:</i> Each <tt>ios_base</tt> member has an indeterminate value
after construction. <del>These</del> <ins>The object's</ins> members shall be initialized by calling
<tt>basic_ios::init</tt> <ins>before the object's first use or before
 it is destroyed, whichever comes first; otherwise the behavior
 is undefined.</ins>. <del>If an <tt>ios_base</tt> object is destroyed
before these initializations have taken place, the behavior is
undefined.</del>
</blockquote>
</blockquote>

<p>
Change 27.5.4.1 [basic.ios.cons] p2:
</p>

<blockquote><pre>
basic_ios();
</pre>
<blockquote>
<i>Effects:</i> Constructs an object of class <tt>basic_ios</tt>
(27.5.2.7) leaving its member objects uninitialized. The object shall be
initialized by calling <del>its</del>
<tt><ins>basic_ios::</ins>init</tt> <ins>before its first
use or before it is destroyed, whichever comes first; otherwise the
behavior is undefined.</ins> <del>member function. If it is destroyed
before it has been initialized the behavior is undefined.</del>
</blockquote>
</blockquote>





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

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

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

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

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

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

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


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





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

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


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

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




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

<p>
10 Unless otherwise specified (see 23.2.4.1, 23.2.5.1, 23.3.2.3, and 23.3.6.4)
all container types defined in this Clause meet the following additional
requirements:
</p>

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

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

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

<p>
Modify Table 96 &mdash; Associative container requirements in 23.2.4 [associative.reqmts]:
</p>

<blockquote>
<table border="1">
<caption>Table 96 &mdash; Associative container requirements (in addition to container)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion/note<br/>pre-/post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td colspan="4"><center>...</center></td>
</tr>

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

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

<tr>
<td colspan="4"><center>...</center></td>
</tr>

</table>
</blockquote>

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

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

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

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

<p>
Modify 23.2.5 [unord.req], p6, p12 and p13:
</p>

<blockquote>
<p>
6 An unordered associative container supports <i>unique keys</i> if it may
contain at most one element for each key. Otherwise, it supports <i>equivalent
keys</i>. <tt>unordered_set</tt> and <tt>unordered_map</tt> support unique keys.
<tt>unordered_multiset</tt> and <tt>unordered_multimap</tt> support equivalent
keys. In containers that support equivalent keys, elements with equivalent keys
are adjacent to each other. For <tt>unordered_multiset</tt> and
<tt>unordered_multimap</tt>, <tt>insert</tt><ins>, <tt>emplace</tt>,</ins> and
<tt>erase</tt> preserve the relative ordering of equivalent elements.
</p>

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

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

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

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





<hr>
<h3><a name="1260"></a>1260. <tt>is_constructible&lt;int*,void*&gt;</tt> reports true</h3>
<p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-11-07  <b>Last modified:</b> 2009-11-08</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The specification of <tt>is_constructible&lt;T,Args...&gt;</tt> in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>
uses
</p>

<blockquote><pre>
static_cast&lt;T&gt;(create&lt;Args&gt;()...)
</pre></blockquote>

<p>
for the one-argument case, but <tt>static_cast</tt> also permits
unwanted conversions such as <tt>void*</tt> to <tt>T*</tt> and
<tt>Base*</tt> to <tt>Derived*</tt>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.7.4.3 [meta.unary.prop], p6:
</p>

<blockquote>
<p>
the predicate condition for a template specialization
<tt>is_constructible&lt;T, Args&gt;</tt> shall be satisfied, if and only
if the following <del>expression <i>CE</i></del> <ins>variable
definition</ins> would be well-formed:
</p>

<ul>
<li>
<p>
if <tt>sizeof...(Args) == <ins>0</ins> <del>1</del></tt><del>, the expression</del>:
</p>
<blockquote><pre>
<del>static_cast&lt;T&gt;(create&lt;Args&gt;()...)</del>
<ins>T t;</ins>
</pre></blockquote>
</li>
<li>
<p>
otherwise <del>the expression</del>:
</p>
<blockquote><pre>
T<ins> t</ins>(create&lt;Args&gt;()...);
</pre></blockquote>
</li>
</ul>
</blockquote>





<hr>
<h3><a name="1268"></a>1268. The Mutex requirements in 30.4.1 and 30.4.2 are wrong</h3>
<p><b>Section:</b> 30.4 [thread.mutex] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2009-11-17  <b>Last modified:</b> 2010-03-28</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.mutex">issues</a> in [thread.mutex].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>Mutex</tt> requirements in 30.4.1 [thread.mutex.requirements] and
30.4.2 [thread.timedmutex.requirements] confuse the requirements on the
behaviour of <tt>std::mutex</tt> et al with the requirements on
<tt>Lockable</tt> types for use with <tt>std::unique_lock</tt>,
<tt>std::lock_guard</tt> and <tt>std::condition_variable_any</tt>.
</p>

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


<blockquote>
<p>
Concepts of threads chapter and issue presentation are: Lockable &lt; Mutex &lt;
TimedMutex and Lockable &lt; TimedLockable &lt; TimedMutex.
</p>
<p>
Typo in failed deletion of Mutex in 30.4.4 p4 edits.
</p>
<p>
Lockable requirements are too weak for condition_variable_any, but the Mutex
requirements are too strong.
</p>
<p>
Need subset of Lockable requirements for condition_variable_any that does not
include try_lock. E.g. CvLockable &lt; Lockable.
</p>
<p>
Text needs updating to recent draft changes.
</p>
<p>
Needs to specify exception behavior in Lockable.
</p>
<p>
The current standard is fine for what it says, but it places requirements that
are too strong on authors of mutexes and locks.
</p>
<p>
Move to open status. Suggest Anthony look at condition_variable_any
requirements. Suggest Anthony refine requirements/concepts categories.
</p>
<p>
Related to <a href="lwg-active.html#964">964</a> and <a href="lwg-active.html#966">966</a>
</p>
</blockquote>

<p><i>[
2010-03-28 Daniel synced with N3092.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Add a new section to 30.2 [thread.req] after 30.2.4 [thread.req.timing] as follows:
</p>

<blockquote>
<p>
30.2.5 Requirements for Lockable types
</p>

<p>
The standard library templates <tt>unique_lock</tt> (30.4.3.2 [thread.lock.unique]), <tt>lock_guard</tt> (30.4.3.1 [thread.lock.guard]), <tt>lock</tt>, <tt>try_lock</tt> (30.4.4 [thread.lock.algorithm]) and <tt>condition_variable_any</tt> (30.5.2 [thread.condition.condvarany]) all operate on user-supplied
<tt>Lockable</tt> objects. Such an object must support the member functions
specified for either the <tt>Lockable</tt> Requirements or the
<tt>TimedLockable</tt> requirements as appropriate to acquire or release
ownership of a <tt>lock</tt> by a given <tt>thread</tt>. [<i>Note:</i> the
nature of any lock ownership and any synchronization it may entail are not part
of these requirements. &mdash; <i>end note</i>]
</p>

<p>
30.2.5.1  Lockable Requirements
</p>

<p>
In order to qualify as a <tt>Lockable</tt> type, the following expressions must
be supported, with the specified semantics, where <tt>m</tt> denotes a value of
type <tt>L</tt> that supports the <tt>Lockable</tt>:
</p>

<p>
The expression <tt>m.lock()</tt> shall be well-formed and have the following
semantics:
</p>

<dl>
  <dt>Effects:</dt><dd>Block until a lock can be acquired for the current thread.</dd>
  <dt>Return type:</dt><dd><tt>void</tt></dd>
</dl>

<p>
The expression <tt>m.try_lock()</tt> shall be well-formed and have the
following semantics:
</p>

<dl>
  <dt>Effects:</dt><dd>Attempt to acquire a lock for the current thread without blocking.</dd>
  <dt>Return type:</dt><dd><tt>bool</tt></dd>
  <dt>Returns:</dt><dd><tt>true</tt> if the lock was
  acquired, <tt>false</tt> otherwise.</dd>
</dl>

<p>
The expression <tt>m.unlock()</tt> shall be well-formed and have the
following semantics:
</p>

<dl>
  <dt>Effects:</dt><dd>Release a lock on <tt>m</tt> held by the current thread.</dd>
  <dt>Return type:</dt><dd><tt> void</tt></dd>
  <dt>Throws:</dt><dd> Nothing if the current thread holds a lock on <tt>m</tt>.</dd>
</dl>

<p>
30.2.5.2 <tt>TimedLockable</tt> Requirements
</p>

<p>
For a type to qualify as <tt>TimedLockable</tt> it must meet the
<tt>Lockable</tt> requirements, and additionally the following
expressions must be well-formed, with the specified semantics,
where <tt>m</tt> is an instance of a type <tt>TL</tt> that supports
the <tt>TimedLockable</tt> requirements, <tt>rel_time</tt> denotes
instantiation of <tt>duration</tt> (20.10.3 [time.duration]) and <tt>abs_time</tt>
denotes an instantiation of <tt>time_point</tt> (20.10.4 [time.point])

</p>

<p>
The expression <tt>m.try_lock_for(rel_time)</tt> shall be well-formed and have the
following semantics:
</p>

<dl>
  <dt>Effects:</dt><dd>Attempt to acquire a lock for the current
  thread within the specified time period.</dd>
  <dt>Return type:</dt><dd><tt>bool</tt></dd>
  <dt>Returns:</dt><dd><tt>true</tt> if the lock was
  acquired, <tt>false</tt> otherwise.</dd>
</dl>

<p>
The expression <tt>m.try_lock_until(abs_time)</tt> shall be well-formed and have the
following semantics:
</p>

<dl>
  <dt>Effects:</dt><dd>Attempt to acquire a lock for the current
  thread before the specified point in time.</dd>
  <dt>Return type:</dt><dd><tt>bool</tt></dd>
  <dt>Returns:</dt><dd><tt>true</tt> if the lock was
  acquired, <tt>false</tt> otherwise.</dd>
</dl>
</blockquote>

<p>
Replace 30.4.1 [thread.mutex.requirements] paragraph 2 with the
following:
</p>

<blockquote>
2 This section describes requirements on <del>template argument types
used to instantiate templates defined in</del> <ins>the mutex types
supplied by</ins> the C++ standard library. <del>The template
definitions in the C++ standard library refer</del> These types shall
conform to the named <tt>Mutex</tt> requirements whose details are set
out below.  In this description, <tt>m</tt> is an object
of <del>a <tt>Mutex</tt> type</del>
<ins>one of the standard library mutex types <tt>std::mutex</tt>,
<tt>std::recursive_mutex</tt>, <tt>std::timed_mutex</tt> or
<tt>std::recursive_timed_mutex</tt>.</ins>.
</blockquote>

<p>
Add the following paragraph after 30.4.1 [thread.mutex.requirements]
paragraph 2:
</p>

<blockquote><ins>
A <tt>Mutex</tt> type shall conform to the <tt>Lockable</tt>
requirements (30.2.5.1).
</ins></blockquote>

<p>
Replace 30.4.2 [thread.timedmutex.requirements] paragraph 1 with the
following:
</p>

<blockquote>
<ins>The C++ standard library <tt>TimedMutex</tt> types <tt>std::timed_mutex</tt>
  and <tt>std::recursive_timed_mutex</tt> </ins>
<del>A <tt>TimedMutex</tt> type</del> shall meet the requirements for
a <tt>Mutex</tt> type. In addition, <del>it</del><ins>they</ins> shall
meet the requirements set out <del>in this Clause 30.4.2</del><ins>below</ins>,
where <tt>rel_time</tt> denotes an instantiation of <tt>duration</tt>
(20.10.3 [time.duration]) and <tt>abs_time</tt> denotes an instantiation
of <tt>time_point</tt> (20.10.4 [time.point]).
</blockquote>

<p>
Add the following paragraph after 30.4.2 [thread.timedmutex.requirements] paragraph 1:
</p>

<blockquote><ins>
A <tt>TimedMutex</tt> type shall conform to the <tt>TimedLockable</tt>
requirements (30.2.5.1).
</ins></blockquote>


<p>
Add the following paragraph following 30.4.3.1 [thread.lock.guard]
paragraph 1:
</p>

<blockquote><ins>
The supplied <tt>Mutex</tt> type shall meet the <tt>Lockable</tt> 
requirements
(30.2.5.1).
</ins></blockquote>

<p>
Add the following paragraph following 30.4.3.2 [thread.lock.unique]
paragraph 1:
</p>

<blockquote><ins>
The supplied <tt>Mutex</tt> type shall meet the <tt>Lockable</tt> 
requirements
(30.2.5.1). <tt>unique_lock&lt;Mutex&gt;</tt> meets the <tt>Lockable</tt>
requirements. If <tt>Mutex</tt> meets the <tt>TimedLockable</tt> 
requirements
(30.2.5.2) then <tt>unique_lock&lt;Mutex&gt;</tt> also meets the
<tt>TimedLockable</tt> requirements.
</ins></blockquote>

<p>
Replace the use of "mutex" or "mutex object" with "lockable object"
throughout clause 30.4.3 [thread.lock] paragraph 1:
</p>

<blockquote>
1 A lock is an object that holds a reference to
a <del>mutex</del><ins>lockable object</ins> and may unlock
the <del>mutex</del><ins>lockable object</ins> during the lock's
destruction (such as when leaving block scope). A thread of execution
may use a lock to aid in managing <del>mutex</del> ownership <ins>of a
lockable object</ins> in an exception safe manner. A lock is said to
own a <del>mutex</del><ins>lockable object</ins> if it is currently
managing the ownership of that <del>mutex</del><ins>lockable
object</ins> for a thread of execution. A lock does not manage the
lifetime of the <del>mutex</del><ins>lockable object</ins> it
references.  [ Note: Locks are intended to ease the burden of
unlocking the <del>mutex</del><ins>lockable object</ins> under both
normal and exceptional circumstances. &mdash; end note ]
</blockquote>

<p>30.4.3 [thread.lock] paragaph 2:</p>

<blockquote>
2 Some lock constructors take tag types which describe what should be
done with the <del>mutex</del><ins>lockable</ins> object during the
lock's constuction.
</blockquote>

<p>30.4.3.1 [thread.lock.guard] paragaph 1:</p>

<blockquote>
1 An object of type <tt>lock_guard</tt> controls the ownership of a
  <del>mutex</del><ins>lockable</ins> object within a scope. A
<tt>lock_guard</tt> object maintains ownership of
a <del>mutex</del><ins>lockable</ins> object throughout
the <tt>lock_guard</tt> object's lifetime. The behavior of a program
is undefined if the <del>mutex</del><ins>lockable object</ins>
referenced by <tt>pm</tt> does not exist for the entire lifetime (3.8)
of the <tt>lock_guard</tt> object. <ins><tt>Mutex</tt> shall meet
  the <tt>Lockable</tt> requirements (30.2.5.1).</ins>
</blockquote>

<p>30.4.3.2 [thread.lock.unique] paragaph 1:</p>

<blockquote>
1 An object of type <tt>unique_lock</tt> controls the ownership of
a <del>mutex</del><ins>lockable object</ins> within a
scope. <Del>Mutex</Del> <del>o</del><ins>O</ins>wnership <Ins>of the
lockable object</Ins> may be acquired at construction or after
construction, and may be transferred, after acquisition, to
another <tt>unique_lock</tt> object. Objects of
type <tt>unique_lock</tt> are not copyable but are movable. The
behavior of a program is undefined if the contained
pointer <tt>pm</tt> is not null and the mutex pointed to
by <tt>pm</tt> does not exist for the entire remaining lifetime (3.8)
of the <tt>unique_lock</tt> object. <ins><tt>Mutex</tt> shall meet
the <tt>Lockable</tt> requirements (30.2.5.1).</ins>
</blockquote>


<p>
Add the following to the precondition of <tt>unique_lock(mutex_type&amp;
 m,
const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time)</tt> in 
30.4.3.2.1 [thread.lock.unique.cons] paragraph 18:
</p>

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

<blockquote>
18 <i>Requires:</i> If <tt>mutex_type</tt> is not a recursive mutex 
the
calling thread does not own the mutex. <ins>The supplied <tt>mutex_type</tt>
type shall meet the <tt>TimedLockable</tt> requirements (30.2.5.2).</ins>
</blockquote>
</blockquote>

<p>
Add the following to the precondition of <tt>unique_lock(mutex_type&amp;
 m,
const chrono::duration&lt;Rep, Period&gt;&amp; rel_time)</tt> in 
30.4.3.2.1 [thread.lock.unique.cons]
paragraph 22
</p>

<blockquote>
22  <i>Requires:</i> If <tt>mutex_type</tt> is not a recursive mutex
 the
calling thread does not own the mutex. <ins>The supplied <tt>mutex_type</tt>
type shall meet the <tt>TimedLockable</tt> requirements (30.2.5.2).</ins>
</blockquote>

<p>
Add the following as a precondition of <tt>bool try_lock_until(const
chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time)</tt> before
30.4.3.2.2 [thread.lock.unique.locking] paragraph 8
</p>

<blockquote><pre>template &lt;class Clock, class Duration&gt;
  bool try_lock_until(const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
</pre>
<blockquote><ins>
<i>Requires:</i> The supplied <tt>mutex_type</tt> type shall meet the
<tt>TimedLockable</tt> requirements (30.2.5.2).
</ins></blockquote>
</blockquote>

<p>
Add the following as a precondition of <tt>bool try_lock_for(const
chrono::duration&lt;Rep, Period&gt;&amp; rel_time)</tt> before 
30.4.3.2.2 [thread.lock.unique.locking] paragraph 12
</p>

<blockquote><pre>template &lt;class Rep, class Period&gt;
  bool try_lock_for(const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
</pre>
<blockquote><ins>
<i>Requires:</i> The supplied <tt>mutex_type</tt> type shall meet the
<tt>TimedLockable</tt> requirements (30.2.5.2).
</ins></blockquote>
</blockquote>

<p>
Replace 30.4.4 [thread.lock.algorithm] p1 with the following:
</p>

<blockquote><pre>template &lt;class L1, class L2, class... L3&gt; int try_lock(L1&amp;, L2&amp;, L3&amp;...);
</pre>
<blockquote>
1 <i>Requires:</i> Each template parameter type shall meet the
<tt><del>Mutex</del> <ins>Lockable</ins></tt> requirements
<ins>(30.2.5.1).</ins><del>, except that a call to <tt>try_lock()</tt> 
may throw
an exception.</del> [<i>Note:</i> The <tt>unique_lock</tt> class 
template meets
these requirements when suitably instantiated. &mdash; <i>end note</i>]
</blockquote>
</blockquote>

<p>
Replace 30.4.4 [thread.lock.algorithm] p4 with the following:
</p>

<blockquote><pre>template &lt;class L1, class L2, class... L3&gt; void lock(L1&amp;, L2&amp;, L3&amp;...);
</pre>
<blockquote>
4 <i>Requires:</i> Each template parameter type shall meet the
<tt>Mutex<del>Mutex</del> <ins>Lockable</ins></tt>
requirements <ins>(30.2.5.1).</ins><del>, except that a call to
<tt>try_lock()</tt> may throw an exception.</del> [<i>Note:</i> The
<tt>unique_lock</tt> class template meets these requirements when 
suitably
instantiated. &mdash; <i>end note</i>]
</blockquote>
</blockquote>

<p>
Replace 30.5.2 [thread.condition.condvarany] paragraph 1 with:
</p>

<blockquote>
1 A <tt>Lock</tt> type shall meet the <del>requirements for a <tt>Mutex</tt>
type</del> <ins><tt>Lockable</tt> requirements (30.2.5.1)</ins>, except 
that
<tt>try_lock</tt> is not required. [<i>Note:</i> All of the standard 
mutex types
meet this requirement. &mdash; <i>end note</i>]
</blockquote>






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

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


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



<p><b>Proposed resolution:</b></p>
<p>
Change paragraph 20.8.3 [base]/1 as follows:
</p>

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





<hr>
<h3><a name="1281"></a>1281. CopyConstruction and Assignment between ratios having the same normalized form</h3>
<p><b>Section:</b> 20.6.1 [ratio.ratio] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Vicente Juan Botet Escrib&aacute; <b>Opened:</b> 2009-12-07  <b>Last modified:</b> 2010-03-27</p>
<p><b>View all other</b> <a href="lwg-index.html#ratio.ratio">issues</a> in [ratio.ratio].</p>
<p><b>Discussion:</b></p>
<p>
CopyConstruction and Assignment between <tt>ratio</tt>s having the same
normalized form. Current
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>
do not allows to copy-construct or assign <tt>ratio</tt> instances of
<tt>ratio</tt> classes having the same normalized form.
</p>

<p>
Two <tt>ratio</tt> classes <tt>ratio&lt;N1,D1&gt;</tt> and
<tt>ratio&lt;N2,D2&gt;</tt> have the same normalized form if
</p>

<blockquote><pre>
ratio&lt;N1, D1&gt;::num == ratio&lt;N2, D2&gt;::num &amp;&amp;
ratio&lt;N1, D1&gt;::den == ratio&lt;N2, D2&gt;::den
</pre></blockquote>

<p>
This simple example
</p>

<blockquote><pre>
ratio&lt;1,3&gt; r1;
ratio&lt;3,9&gt; r2;
r1 = r2; // (1)
</pre></blockquote>

<p>
fails to compile in (1). Other example
</p>

<blockquote><pre>
ratio&lt;1,3&gt; r1;
ratio_subtract&lt;ratio&lt;2,3&gt;, ratio&lt;1,3&gt;&gt;::type r2;
r1 = r2;  
</pre></blockquote>

<p>
The nested type of <tt>ratio_subtract&lt;ratio&lt;2,3&gt;,
ratio&lt;1,3&gt;&gt;</tt> could be <tt>ratio&lt;3,9&gt;</tt> so the compilation
could fail. It could also be <tt>ratio&lt;1,3&gt;</tt> and the compilation
succeeds.
</p>

<p>
In 20.6.2 [ratio.arithmetic] 3 and similar clauses
</p>

<blockquote>
3 The nested typedef <tt>type</tt> shall be a synonym for <tt>ratio&lt;T1,
T2&gt;</tt> where <tt>T1</tt> has the value <tt>R1::num * R2::den - R2::num *
R1::den</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::den</tt>.
</blockquote>

<p>
the meaning of synonym let think that the result shall be a normalized
<tt>ratio</tt> equivalent to <tt>ratio&lt;T1, T2&gt;</tt>, but there is not an
explicit definition of what synonym means in this context.
</p>

<p>
Additionally we should add a typedef for accessing the normalized
<tt>ratio</tt>, and  change 20.6.2 [ratio.arithmetic] to return only this
<em>normalized</em> result.
</p>

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


<blockquote>
<p>
There is no consensus to add the converting copy constructor or converting copy
assignment operator.  However there was consensus to add the typedef.
</p>

<p>
Proposed wording modified.  Original proposed wording preserved here.  Moved to
Review.
</p>

<blockquote class="note">
<p>
Make <tt>ratio</tt> default constructible, copy-constructible and assignable
from any <tt>ratio</tt> which has the same reduced form.
</p>

<p>
Add to 20.6.1 [ratio.ratio] synopsis
</p>

<blockquote><pre>
template &lt;intmax_t N, intmax_t D = 1&gt;
class ratio {
public:
  static constexpr intmax_t num;
  static constexpr intmax_t den;

  <ins>typedef ratio&lt;num, den&gt; type;</ins>

  <ins>ratio() = default;
  template &lt;intmax_t N2, intmax_t D2&gt;
    ratio(const ratio&lt;N2, D2&gt;&amp;);
  template &lt;intmax_t N2, intmax_t D2&gt;
    ratio&amp; operator=(const ratio&lt;N2, D2&gt;&amp;);</ins>
};
</pre></blockquote>

<p>
Add to 20.6.1 [ratio.ratio]:
</p>

<blockquote>
<p>
Two ratio classes <tt>ratio&lt;N1,D1&gt;</tt> and <tt>ratio&lt;N2,D2&gt;</tt>
have the same reduced form if <tt>ratio&lt;N1,D1&gt;::type</tt> is the same
type as <tt>ratio&lt;N2,D2&gt;::type</tt>
</p>

</blockquote>

<p>
Add a new section: [ratio.cons]
</p>

<blockquote>
<p><b>
Construction and assignment  [ratio.cons]
</b></p>

<pre>
template &lt;intmax_t N2, intmax_t D2&gt;
  ratio(const ratio&lt;N2, D2&gt;&amp; r);
</pre>

<blockquote>
<p>
<i>Effects:</i> Constructs a <tt>ratio</tt> object.
</p>
<p>
<i>Remarks:</i> This constructor shall not participate in overload resolution
unless <tt>r</tt> has the same reduced form as <tt>*this</tt>.
</p>
</blockquote>

<pre>
template &lt;intmax_t N2, intmax_t D2&gt;
  ratio&amp; operator=(const ratio&lt;N2, D2&gt;&amp; r);
</pre>

<blockquote>
<p>
<i>Effects:</i> None.
</p>
<p>
<i>Returns:</i> <tt>*this</tt>.
</p>
<p>
<i>Remarks:</i> This operator shall not participate in overload resolution
unless <tt>r</tt> has the same reduced form as <tt>*this</tt>.
</p>
</blockquote>

</blockquote>

<p>
Change 20.6.2 [ratio.arithmetic] 
</p>

<blockquote>
<p>
Implementations may use other algorithms to compute these values. If overflow
occurs, a diagnostic shall be issued.
</p>

<pre>
template &lt;class R1, class R2&gt; struct ratio_add {
  typedef <i>see below</i> type;
};
</pre>

<blockquote>
The nested typedef <tt>type</tt> shall be a synonym for <tt>ratio&lt;T1,
T2&gt;<ins>::type</ins></tt> where <tt>T1</tt> has the value <tt>R1::num *
R2::den + R2::num * R1::den</tt> and <tt>T2</tt> has the value <tt>R1::den *
R2::den</tt>.
</blockquote>

<pre>
template &lt;class R1, class R2&gt; struct ratio_subtract {
  typedef <i>see below</i> type;
};
</pre>

<blockquote>
The nested typedef <tt>type</tt> shall be a synonym for <tt>ratio&lt;T1,
T2&gt;<ins>::type</ins></tt> where <tt>T1</tt> has the value <tt>R1::num *
R2::den - R2::num * R1::den</tt> and <tt>T2</tt> has the value <tt>R1::den *
R2::den</tt>.
</blockquote>

<pre>
template &lt;class R1, class R2&gt; struct ratio_multiply {
  typedef <i>see below</i> type;
};
</pre>

<blockquote>
The nested typedef <tt>type</tt> shall be a synonym for <tt>ratio&lt;T1,
T2&gt;<ins>::type</ins></tt> where <tt>T1</tt> has the value <tt>R1::num *
R2::num</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::den</tt>.
</blockquote>

<pre>
template &lt;class R1, class R2&gt; struct ratio_divide {
  typedef <i>see below</i> type;
};
</pre>

<blockquote>
The nested typedef <tt>type</tt> shall be a synonym for <tt>ratio&lt;T1,
T2&gt;<ins>::type</ins></tt> where <tt>T1</tt> has the value <tt>R1::num *
R2::den</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::num</tt>.
</blockquote>

</blockquote>

</blockquote>

</blockquote>

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


<blockquote>
<p>
Daniel brought to my attention the recent addition of the typedef <tt>type</tt>
to the FCD
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf">N3092</a>:
</p>

<blockquote><pre>
typedef ratio type;
</pre></blockquote>

<p>
This issue was discussed in Pittsburgh, and the decision there was to accept the
typedef as proposed and move to Review.  Unfortunately the issue was accidently
applied to the FCD, and incorrectly.  The FCD version of the typedef refers to
<tt>ratio&lt;N, D&gt;</tt>, but the typedef is intended to refer to
<tt>ratio&lt;num, den&gt;</tt> which in general is not the same type.
</p>

<p>
I've updated the wording to diff against
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf">N3092</a>.
</p>

</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add to 20.6.1 [ratio.ratio] synopsis
</p>

<blockquote><pre>
template &lt;intmax_t N, intmax_t D = 1&gt;
class ratio {
public:
  static constexpr intmax_t num;
  static constexpr intmax_t den;

  typedef ratio<ins>&lt;num, den&gt;</ins> type;
};
</pre></blockquote>






<hr>
<h3><a name="1289"></a>1289. Generic casting requirements for smart pointers</h3>
<p><b>Section:</b> 20.3 [utility] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Ion Gazta&ntilde;aga <b>Opened:</b> 2009-12-14  <b>Last modified:</b> 2010-03-27</p>
<p><b>View all other</b> <a href="lwg-index.html#utility">issues</a> in [utility].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In section 20.2.5 [allocator.requirements], Table 40 &mdash; Allocator requirements,
the following expression is required for allocator pointers:
</p>

<blockquote>
<table border="1">
<caption>Table 40 &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>static_cast&lt;X::pointer&gt;(w)</tt></td>
<td><tt>X::pointer</tt></td>
<td><tt>static_cast&lt;X::pointer&gt;(w) == p</tt></td>
<td>&nbsp;</td>
</tr>
</table>
</blockquote>

<p>
To achieve this expression, a smart pointer writer must introduce an explicit
conversion operator from <tt>smart_ptr&lt;void&gt;</tt> to
<tt>smart_ptr&lt;T&gt;</tt> so that
<tt>static_cast&lt;pointer&gt;(void_ptr)</tt> is a valid expression.
Unfortunately this explicit conversion weakens the safety of a smart pointer
since the following expression (invalid for raw pointers) would become valid:
</p>

<blockquote><pre>
smart_ptr&lt;void&gt; smart_v = ...;
smart_ptr&lt;T&gt; smart_t(smart_v);
</pre></blockquote>

<p>
On the other hand, <tt>shared_ptr</tt> also defines its own casting functions in
20.9.11.2.10 [util.smartptr.shared.cast], and although it's unlikely that a
programmer will use <tt>shared_ptr</tt> as <tt>allocator::pointer</tt>, having
two different ways to do the same cast operation does not seem reasonable. A
possible solution would be to replace <tt>static_cast&lt;X::pointer&gt;(w)</tt>
expression with a user customizable (via ADL)
<tt>static_pointer_cast&lt;value_type&gt;(w)</tt>, and establish the
<tt>xxx_pointer_cast</tt> functions introduced by <tt>shared_ptr</tt> as the
recommended generic casting utilities of the standard.
</p>

<p>
Unfortunately, we've experienced problems in Boost when trying to establish
<tt>xxx_pointer_cast</tt> as customization points for generic libraries (<a
href="http://objectmix.com/c/40424-adl-lookup-explicit-template-parameters.html"
>http://objectmix.com/c/40424-adl-lookup-explicit-template-parameters.html</a>)
because these casting functions are called with explicit template parameters and
the standard says in 14.8.1 [temp.arg.explicit] p.8 "Explicit template
argument specification":
</p>

<blockquote>
8 ...But when a function template with explicit template arguments is used, the
call does not have the correct syntactic form unless there is a function
template with that name visible at the point of the call. If no such name is
visible, the call is not syntactically well-formed and argument-dependent lookup
does not apply.
</blockquote>

<p>
So we can do this:
</p>

<blockquote><pre>
template&lt;class BasePtr&gt;
void generic_ptr_swap(BasePtr p)
{
  //ADL customization point
  swap(p, p);
  //...
}
</pre></blockquote>

<p>
but not the following:
</p>

<blockquote><pre>
template&lt;class BasePtr&gt;
void generic_ptr_algo(BasePtr p)
{
  typedef std::pointer_traits&lt;BasePtr&gt;::template
     rebind&lt;Derived&gt; DerivedPtr;
  DerivedPtr dp = static_pointer_cast&lt;Derived&gt;(p);
}
</pre></blockquote>

<p>
The solution to make <tt>static_pointer_cast</tt> a customization point is to
add a generic declaration (no definition) of <tt>static_pointer_cast</tt> in a
namespace (like <tt>std</tt>) and apply "<tt>using
std::static_pointer_cast</tt>" declaration to activate ADL:
</p>

<blockquote><pre>
namespace std{

template&lt;typename U, typename T&gt;
<i>unspecified</i>
static_pointer_cast(T&amp;&amp;) = delete;

}

template&lt;class BasePtr&gt;
void generic_ptr_algo(BasePtr p)
{
  typedef std::pointer_traits&lt;BasePtr&gt;::template
     rebind&lt;Derived&gt; DerivedPtr;

  //ADL applies because static_pointer_cast is made
  //  visible according to [temp.arg.explicit]/8
  using std::static_pointer_cast;

  DerivedPtr dp = static_pointer_cast&lt;Derived&gt;(p);

  //...
}
</pre></blockquote>

<p>
A complete solution will need also the definition of
<tt>static_pointer_cast</tt> for raw pointers, and this definition has been
present in Boost (<a
href="http://www.boost.org/boost/pointer_cast.hpp">http://www.boost.org/boost/
pointer_cast.hpp</a>) for years.
</p>

<p><i>[
2010-03-26 Daniel made editorial adjustments to the proposed wording.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Add to section 20.3 [utility] Utility components, Header
<tt>&lt;utility&gt;</tt> synopsis:
</p>

<blockquote><pre>
// 20.3.X, generic pointer cast functions

template&lt;typename U, typename T&gt;
<i>unspecified</i>
static_pointer_cast(T&amp;&amp;) = delete;

template&lt;typename U, typename T&gt;
<i>unspecified</i>
dynamic_pointer_cast(T&amp;&amp;) = delete;

template&lt;typename U, typename T&gt;
<i>unspecified</i>
const_pointer_cast(T&amp;&amp;) = delete;

//Overloads for raw pointers
template&lt;typename U, typename T&gt;
auto static_pointer_cast(T* t) -&gt; decltype(static_cast&lt;U*&gt;(t));

template&lt;typename U, typename T&gt;
auto dynamic_pointer_cast(T* t) -&gt; decltype(dynamic_cast&lt;U*&gt;(t));

template&lt;typename U, typename T&gt;
auto const_pointer_cast(T* t) -&gt; decltype(const_cast&lt;U*&gt;(t));
</pre></blockquote>

<p>
Add to section 20.3 [utility] Utility components, a new subclause
20.3.X Pointer cast utilities [pointer.cast]:
</p>

<blockquote>
<p>
20.3.X Pointer cast utilities [pointer.cast]
</p>

<p>
1 The library defines generic pointer casting function templates so that template code
can explicitly make these names visible and activate argument-dependent lookup
for pointer cast calls.
</p>

<pre>
//Generic declarations
template&lt;typename U, typename T&gt;
<i>unspecified</i>
static_pointer_cast(T&amp;&amp;) = delete;

template&lt;typename U, typename T&gt;
<i>unspecified</i>
dynamic_pointer_cast(T&amp;&amp;) = delete;

template&lt;typename U, typename T&gt;
<i>unspecified</i>
const_pointer_cast(T&amp;&amp;) = delete;
</pre>

<p>
2 The library also defines overloads of these functions for raw pointers.
</p>

<pre>
//Overloads for raw pointers
template&lt;typename U, typename T&gt;
auto static_pointer_cast(T* t) -&gt; decltype(static_cast&lt;U*&gt;(t));
</pre>

<blockquote>
<i>Returns:</i> <tt>static_cast&lt;U*&gt;(t)</tt>
</blockquote>

<pre>
template&lt;typename U, typename T&gt;
auto dynamic_pointer_cast(T* t) -&gt; decltype(dynamic_cast&lt;U*&gt;(t));
</pre>

<blockquote>
<i>Returns:</i> <tt>dynamic_cast&lt;U*&gt;(t)</tt>
</blockquote>

<pre>
template&lt;typename U, typename T&gt;
auto const_pointer_cast(T* t) -&gt; decltype(const_cast&lt;U*&gt;(t));
</pre>

<blockquote>
<i>Returns:</i> <tt>const_cast&lt;U*&gt;(t)</tt>
</blockquote>

<p>
[<i>Example:</i>
</p>

<blockquote><pre>
#include &lt;utility&gt; //static_pointer_cast
#include &lt;memory&gt;  //pointer_traits

class Base{};
class Derived : public Base{};

template&lt;class BasePtr&gt;
void generic_pointer_code(BasePtr b)
{
   typedef std::pointer_traits&lt;BasePtr&gt;::template
      rebind&lt;Derived&gt; DerivedPtr;

   using std::static_pointer_cast;
   //ADL applies now that static_pointer_cast is visible
   DerivedPtr d = static_pointer_cast&lt;Derived&gt;(b);
}
</pre></blockquote>

<p>
&mdash; <i>end example</i>]
</p>

</blockquote>

<p>
Replace in section 20.2.5 [allocator.requirements] Table 40 &mdash; Allocator
requirements, the following table entries for allocator pointers:
</p>

<blockquote>
<table border="1">
<caption>Table 40 &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>static<ins>_pointer</ins>_cast&lt;<del>X::pointer</del><ins>T</ins>&gt;(w)</tt></td>
<td><tt>X::pointer</tt></td>
<td><tt>static<ins>_pointer</ins>_cast&lt;<del>X::pointer</del><ins>T</ins>&gt;(w) == p</tt></td>
<td>&nbsp;</td>
</tr>

<tr>
<td><tt>static<ins>_pointer</ins>_cast&lt;<del>X::const_pointer</del><ins>const T</ins>&gt;(w)</tt></td>
<td><tt>X::const_pointer</tt></td>
<td><tt>static<ins>_pointer</ins>_cast&lt;<del>X::const_pointer</del><ins>const T</ins>&gt;(z) == q</tt></td>
<td>&nbsp;</td>
</tr>

</table>
</blockquote>






<hr>
<h3><a name="1290"></a>1290. Don't require <tt>[u|bi]nary_function</tt> inheritance</h3>
<p><b>Section:</b> 20.8 [function.objects] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2009-12-14  <b>Last modified:</b> 2009-12-19</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#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
This issue is a follow-up of the discussion on issue <a href="lwg-defects.html#870">870</a> during
the 2009 Santa Cruz meeting.
</p>

<p>
The class templates <tt>unary_function</tt> and <tt>binary_function</tt> are
actually very simple typedef providers,
</p>

<blockquote><pre>
namespace std {

template &lt;class Arg, class Result&gt;
struct unary_function {
 typedef Arg argument_type;
 typedef Result result_type;
};

template &lt;class Arg1, class Arg2, class Result&gt;
struct binary_function {
 typedef Arg1 first_argument_type;
 typedef Arg2 second_argument_type;
 typedef Result result_type;
};

}
</pre></blockquote>

<p>
which <i>may</i> be used as base classes (similarly to the iterator template),
but were originally <i>not</i> intended as a customization point. The SGI
documentation introduced the concept <a
href="http://www.sgi.com/tech/stl/AdaptableUnaryFunction.html">Adaptable Unary
Function</a> as function objects "with nested typedefs that define its argument
type and result type" and a similar definition for <a
href="http://www.sgi.com/tech/stl/AdaptableBinaryFunction.html">Adaptable Binary
Function</a> related to <tt>binary_function</tt>. But as of TR1 a protocol was
introduced that relies on inheritance relations based on these types. 20.8.4 [refwrap]/3 b. 3 requires that a specialization of
<tt>reference_wrapper&lt;T&gt;</tt> shall derive from <tt>unary_function</tt>,
if type <tt>T</tt> is "a class type that is derived from
<tt>std::unary_function&lt;T1, R&gt;</tt>" and a similar inheritance-based rule
for <tt>binary_function</tt> exists as well.
</p>

<p>
As another disadvantage it has been pointed out in the TR1 issue list, <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1837.pdf">N1837</a>
(see section 10.39), that the requirements of <tt>mem_fn</tt> 20.8.13 [func.memfn]/2+3 to <em>derive</em> from
<tt>std::unary_function/std::binary_function</tt> under circumstances, where the
provision of corresponding typedefs would be sufficient, unnecessarily prevent
implementations that take advantage of empty-base-class- optimizations.
</p>

<p>
Both requirements should be relaxed in the sense that the
<tt>reference_wrapper</tt> should provide typedef's <tt>argument_type</tt>,
<tt>first_argument_type</tt>, and <tt>second_argument_type</tt> based on similar
rules as the <i>weak result type</i> rule (20.8.2 [func.require]/3) does
specify the presence of <tt>result_type</tt> member types.
</p>

<p>
For a related issue see also <a href="lwg-active.html#1279">1279</a>.
</p>


<p><b>Proposed resolution:</b></p>
<p><i>[
The here proposed resolution is an attempt to realize the common denominator of
the reflector threads c++std-lib-26011, c++std-lib-26095, and c++std-lib-26124.
]</i></p>


<ol>
<li>
<p>
Change 20.8.3 [base]/1 as indicated: <i>[The intend is to provide an
alternative fix for issue <a href="lwg-active.html#1279">1279</a> and some editorial harmonization
with existing wording in the library, like 24.4.2 [iterator.basic]/1]</i>
</p>

<blockquote>
<p>
1 The following class<ins> templat</ins>es are provided to simplify the
<ins>definition of</ins> typedefs of the argument and result types <ins>for
function objects. The behavior of a program that adds specializations for any of
these templates is undefined.</ins><del>:</del>
</p>

<blockquote><pre>
namespace std {
 template &lt;class Arg, class Result&gt;
 struct unary_function {
   typedef Arg argument_type;
   typedef Result result_type;
 };
}

namespace std {
 template &lt;class Arg1, class Arg2, class Result&gt;
 struct binary_function {
   typedef Arg1 first_argument_type;
   typedef Arg2 second_argument_type;
   typedef Result result_type;
 };
}
</pre></blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.8.4 [refwrap], class template <tt>reference_wrapper</tt>
synopsis as indicated: <i>[The intent is to remove the requirement that
<tt>reference_wrapper</tt> derives from <tt>unary_function</tt> or
<tt>binary_function</tt> if the situation requires the definition of the
typedefs <tt>argument_type</tt>, <tt>first_argument_type</tt>, or
<tt>second_argument_type</tt>. This change is suggested, because the new way of
definition uses the same strategy as the <em>weak result type</em> specification
applied to argument types, which provides the following advantages: It creates
less potential conflicts between <tt>[u|bi]nary_function</tt> bases and typedefs
in a function object and it ensures that user-defined function objects which
provide typedefs but no such bases are handled as first class citizens.]</i>
</p>

<blockquote><pre>
namespace std {
 template &lt;class T&gt; class reference_wrapper
   <del>: public unary_function&lt;T1, R&gt; // <i>see below</i></del>
   <del>: public binary_function&lt;T1, T2, R&gt; // <i>see below</i></del>
 {
 public :
   // types
   typedef T type;
   typedef <i>see below</i> result_type; // not always defined
   <ins>typedef <i>see below</i> argument_type; // not always defined</ins>
   <ins>typedef <i>see below</i> first_argument_type; // not always defined</ins>
   <ins>typedef <i>see below</i> second_argument_type; // not always defined</ins>

   // construct/copy/destroy
   ...
 };
</pre></blockquote>
</li>

<li>
<p>
Change 20.8.4 [refwrap]/3 as indicated: <i>[The intent is to remove the
requirement that <tt>reference_wrapper</tt> derives from <tt>unary_function</tt>
if the situation requires the definition of the typedef <tt>argument_type</tt>
and <tt>result_type</tt>. Note that this clause does concentrate on
<tt>argument_type</tt> alone, because the <tt>result_type</tt> is already ruled
by p. 2 via the <em>weak result type</em> specification. The new way of
specifying <tt>argument_type</tt> is equivalent to the <em>weak result type</em>
specification]</i>
</p>

<blockquote>
<p>
3 The template instantiation <tt>reference_wrapper&lt;T&gt;</tt> shall <del>be
derived from <tt>std::unary_function&lt;T1, R&gt;</tt></del><ins>define a nested
type named <tt>argument_type</tt> as a synonym for <tt>T1</tt></ins> only if the
type <tt>T</tt> is any of the following:
</p>
<ul>
<li>a function type or a pointer to function type taking one argument
of type <tt>T1</tt><del> and returning <tt>R</tt></del>
</li>
<li>a pointer to member function <tt>R T0::f</tt> <em>cv</em> (where
<em>cv</em> represents the member function's cv-qualifiers);
the type <tt>T1</tt> is <em>cv</em> <tt>T0*</tt>
</li>
<li>a class type <del>that is derived from
<tt>std::unary_function&lt;T1, R&gt;</tt></del><ins>with a member type
<tt>argument_type</tt>;
	the type <tt>T1</tt> is <tt>T::argument_type</tt></ins>
</li>
</ul>
</blockquote>
</li>

<li>
<p>
Change 20.8.4 [refwrap]/4 as indicated: <i>[The intent is to remove the
requirement that <tt>reference_wrapper</tt> derives from
<tt>binary_function</tt> if the situation requires the definition of the typedef
<tt>first_argument_type</tt>, <tt>second_argument_type</tt>, and
<tt>result_type</tt>. Note that this clause does concentrate on
<tt>first_argument_type</tt> and <tt>second_argument_type</tt> alone, because
the <tt>result_type</tt> is already ruled by p. 2 via the <em>weak result
type</em> specification. The new way of specifying <tt>first_argument_type</tt>
and <tt>second_argument_type</tt> is equivalent to the <em>weak result type</em>
specification]</i>
</p>

<blockquote>
<p>
The template instantiation <tt>reference_wrapper&lt;T&gt;</tt> shall <del>be
derived from <tt>std::binary_function&lt;T1, T2, R&gt;</tt></del><ins>define two
nested types named <tt>first_argument_type</tt> and
<tt>second_argument_type</tt> as a synonym for <tt>T1</tt> and <tt>T2</tt>,
respectively,</ins> only if the type <tt>T</tt> is any of the following:
</p>
<ul>
<li>a function type or a pointer to function type taking two arguments
of types <tt>T1</tt> and <tt>T2</tt><del> and returning
<tt>R</tt></del>
</li>
<li>a pointer to member function <tt>R T0::f(T2)</tt> <em>cv</em>
(where <em>cv</em> represents the member function's cv-qualifiers);
	the type <tt>T1</tt> is <em>cv</em> <tt>T0*</tt>
</li>
<li>a class type <del>that is derived from
<tt>std::binary_function&lt;T1, T2, R&gt;</tt></del><ins>with member
types <tt>first_argument_type</tt>
	and <tt>second_argument_type</tt>; the type <tt>T1</tt> is
<tt>T::first_argument_type</tt> and the type <tt>T2</tt> is
	<tt>T::second_argument_type</tt></ins>
</li>
</ul>
</blockquote>
</li>

<li>
<p>
Change 20.8.13 [func.memfn]/2+3 as indicated: <i>[The intent is to remove
the requirement that mem_fn's return type has to derive
from <tt>[u|bi]nary_function</tt>. The reason for suggesting the
change here is to better support empty-base-class optimization
choices as has been pointed out in <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1837.pdf">N1837</a>]</i>
</p>

<blockquote>
<p>
2 The simple call wrapper shall <del>be derived from
<tt>std::unary_function&lt;<em>cv</em> T*, <i>Ret</i>&gt;</tt></del><ins>define
two nested types named <tt>argument_type</tt> and <tt>result_type</tt> as a
synonym for <tt><em>cv</em> T*</tt> and <tt><i>Ret</i></tt>, respectively,</ins>
when <tt>pm</tt> is a pointer to member function with cv-qualifier <em>cv</em>
and taking no arguments, where <tt><i>Ret</i></tt> is <tt>pm</tt>'s return type.
</p>
<p>
3 The simple call wrapper shall <del>be derived from
<tt>std::binary_function&lt;<em>cv</em> T*, T1,
<i>Ret</i>&gt;</tt></del><ins>define three nested types named
<tt>first_argument_type</tt>, <tt>second_argument_type</tt>, and
<tt>result_type</tt> as a synonym for <tt><em>cv</em> T*</tt>, <tt>T1</tt>, and
<tt><i>Ret</i></tt>, respectively,</ins> when <tt>pm</tt> is a pointer to member
function with cv-qualifier <em>cv</em> and taking one argument of type
<tt>T1</tt>, where <tt><i>Ret</i></tt> is <tt>pm</tt>'s return type.
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="1292"></a>1292. <tt>std::function</tt> should support all callable types</h3>
<p><b>Section:</b> 20.8.14.2.1 [func.wrap.func.con] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2009-12-19  <b>Last modified:</b> 2009-12-21</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Some parts of the specification of <tt>std::function</tt> is unnecessarily
restricted to a subset of all callable types (as defined in 20.8.1 [func.def]/3), even though the intent clearly is to be usable for
<em>all</em> of them as described in 20.8.14.2 [func.wrap.func]/1. This
argument becomes strengthened by the fact that current C++0x-compatible
compilers work fine with them:
</p>

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

struct A
{
  int foo(int i) const {return i+1;}
};

struct B
{
  int mem;
};

int main()
{
  std::function&lt;int(const A&amp;, int)&gt; f(&amp;A::foo);
  A a;
  std::cout &lt;&lt; f(a, 1) &lt;&lt; '\n';
  std::cout &lt;&lt; f.target_type().name() &lt;&lt; '\n';
  typedef int (A::* target_t)(int) const;
  target_t* p = f.target&lt;target_t&gt;();
  std::cout &lt;&lt; (p != 0) &lt;&lt; '\n';
  std::function&lt;int(B&amp;)&gt; f2(&amp;B::mem);
  B b = { 42 };
  std::cout &lt;&lt; f2(b) &lt;&lt; '\n';
  std::cout &lt;&lt; f2.target_type().name() &lt;&lt; '\n';
  typedef int (B::* target2_t);
  target2_t* p2 = f2.target&lt;target2_t&gt;();
  std::cout &lt;&lt; (p2 != 0) &lt;&lt; '\n';
}
</pre></blockquote>

<p>
The problematics passages are 20.8.14.2.1 [func.wrap.func.con]/10:
</p>

<blockquote><pre>
template&lt;class F&gt; function(F f);
template &lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
</pre>
<blockquote>
<p>...</p>
<p>
10 <i>Postconditions:</i> <tt>!*this</tt> if any of the following hold:
</p>
<ul>
<li>
<tt>f</tt> is a NULL function pointer.
</li>
<li>
<tt>f</tt> is a NULL member function pointer.
</li>
<li>
<tt>F</tt> is an instance of the function class template, and <tt>!f</tt>
</li>
</ul>
</blockquote>
</blockquote>

<p>
because it does not consider pointer to data member and all constraints based on
<em>function objects</em> which like 20.8.14.2 [func.wrap.func]/2 or 20.8.14.2.5 [func.wrap.func.targ]/3. The latter two will be resolved by the proposed
resolution of <a href="lwg-defects.html#870">870</a> and are therefore not handled here.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Change 20.8.14.2.1 [func.wrap.func.con]/10+11 as indicated:
</p>

<blockquote><pre>
template&lt;class F&gt; function(F f);
template &lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
</pre>
<blockquote>
<p>...</p>
<p>
10 <i>Postconditions:</i> <tt>!*this</tt> if any of the following hold:
</p>
<ul>
<li>
<tt>f</tt> is a NULL function pointer.
</li>
<li>
<tt>f</tt> is a NULL <ins>pointer to</ins> member <del>function pointer</del>.
</li>
<li>
<tt>F</tt> is an instance of the function class template, and <tt>!f</tt>
</li>
</ul>

<p>
11 Otherwise, <tt>*this</tt> targets a copy of <tt>f</tt> <del>or</del><ins>,
initialized with</ins> <tt>std::move(f)</tt> <del>if <tt>f</tt> is not a pointer
to member function, and targets a copy of <tt>mem_fn(f)</tt> if <tt>f</tt> is a
pointer to member function</del>. [<i>Note:</i> implementations are encouraged
to avoid the use of dynamically allocated memory for small function objects, for
example, where <tt>f</tt>'s target is an object holding only a pointer or
reference to an object and a member function pointer. &mdash; <i>end note</i>]
</p>

</blockquote>
</blockquote>





<hr>
<h3><a name="1294"></a>1294. Difference between callable wrapper and forwarding  call wrapper unclear</h3>
<p><b>Section:</b> 20.8.2 [func.require] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-12-21  <b>Last modified:</b> 2009-12-21</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.require">active issues</a> in [func.require].</p>
<p><b>View all other</b> <a href="lwg-index.html#func.require">issues</a> in [func.require].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current wording in the standard makes it hard to discriminate the difference
between a "call wrapper" as defined in 20.8.1 [func.def]/5+6:
</p>

<blockquote>
<p>
5 A <i>call wrapper type</i> is a type that holds a callable object and supports
a call operation that forwards to that object.
</p>
<p>
6 A <i>call wrapper</i> is an object of a call wrapper type.
</p>
</blockquote>

<p>
and a "forwarding call wrapper" as defined in 20.8.2 [func.require]/4:
</p>

<blockquote>
<p>
4 [..] A <i>forwarding call wrapper</i> is a call wrapper that can be called
with an argument list. [<i>Note:</i> in a typical implementation forwarding call
wrappers have an overloaded function call operator of the form
</p>

<blockquote><pre>
template&lt;class... ArgTypes&gt;
R operator()(ArgTypes&amp;&amp;... args) <i>cv-qual</i>;
</pre></blockquote>

<p>
&mdash; <i>end note</i>]
</p>
</blockquote>

<p>
Reason for this lack of clear difference seems to be that the wording adaption
to variadics and rvalues that were applied after it's original proposal in <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1673.html#call%20wrapper">N1673</a>:
</p>

<blockquote>
<p>
[..] A <b>forwarding call wrapper</b> is a call wrapper that can be called
with an argument list <tt>t1, t2, ..., tN</tt> where each <tt>ti</tt> is an lvalue.
The effect of calling a forwarding call wrapper with one or more
arguments that are rvalues is implementation defined. [<i>Note:</i> in
a typical implementation forwarding call wrappers have overloaded
function call operators of the form
</p>

<blockquote><pre>
template&lt;class T1, class T2, ..., class TN&gt;
R operator()(T1&amp; t1, T2&amp; t2, ..., TN&amp; tN) <i>cv-qual</i>;
</pre></blockquote>

<p>
&mdash; <i>end note</i>]
</p>
</blockquote>

<p>
combined with the fact that the word "forward" has two different meanings in
this context. This issue attempts to clarify the difference better.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.8.2 [func.require]/4 as indicated:
</p>

<blockquote>
<p>
4 [..] A <i>forwarding call wrapper</i> is a call wrapper that can be called
with an <ins>arbitrary</ins> argument list<ins> and uses perfect forwarding to
deliver the arguments to the wrapped callable object</ins>. [<i>Note:</i> in a
typical implementation forwarding call wrappers have an overloaded function call
operator of the form
</p>

<blockquote><pre>
template&lt;class... ArgTypes&gt;
R operator()(ArgTypes&amp;&amp;... args) <i>cv-qual</i>;
</pre></blockquote>

<p>
&mdash; <i>end note</i>]
</p>
</blockquote>






<hr>
<h3><a name="1295"></a>1295. Contradictory call wrapper requirements</h3>
<p><b>Section:</b> 20.8.2 [func.require] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2009-12-22  <b>Last modified:</b> 2009-12-23</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.require">active issues</a> in [func.require].</p>
<p><b>View all other</b> <a href="lwg-index.html#func.require">issues</a> in [func.require].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.8.2 [func.require]/3 b 1 says
</p>

<blockquote>
<p>
3 If a call wrapper (20.8.1 [func.def]) has a <i>weak result type</i> the
type of its member type <tt>result_type</tt> is based on the type <tt>T</tt> of
the wrapper's target object (20.8.1 [func.def]):
</p>

<ul>
<li>
if <tt>T</tt> is a function, reference to function, or pointer to function type,
<tt>result_type</tt> shall be a synonym for the return type of <tt>T</tt>;
</li>
<li>
[..]
</li>
</ul>
</blockquote>

<p>
The first two enumerated types (function and reference to function)
can never be valid types for <tt>T</tt>, because
</p>

<p>
20.8.1 [func.def]/7
</p>

<blockquote>
7 A <i>target object</i> is the callable object held by a call wrapper.
</blockquote>

<p>
and 20.8.1 [func.def]/3
</p>

<blockquote>
3 A <i>callable type</i> is a pointer to function, a pointer to member function,
a pointer to member data, or a class type whose objects can appear immediately
to the left of a function call operator.
</blockquote>

<p>
exclude functions and references to function as "target objects".
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.8.2 [func.require]/3 b 1 as indicated:
</p>

<blockquote>
<p>
3 If a call wrapper (20.8.1 [func.def]) has a <i>weak result type</i> the
type of its member type <tt>result_type</tt> is based on the type <tt>T</tt> of
the wrapper's target object (20.8.1 [func.def]):
</p>

<ul>
<li>
if <tt>T</tt> is a <del>function, reference to function, or</del> pointer to
function type, <tt>result_type</tt> shall be a synonym for the return type of
<tt>T</tt>;
</li>
<li>
[..]
</li>
</ul>
</blockquote>






<hr>
<h3><a name="1297"></a>1297. <tt>unique_ptr</tt>'s relational operator functions should induce a total order</h3>
<p><b>Section:</b> 20.9.10.4 [unique.ptr.special] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2009-12-23  <b>Last modified:</b> 2010-03-27</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The comparison functions of <tt>unique_ptr</tt> currently directly delegate to
the underlying comparison functions of <tt>unique_ptr&lt;T, D&gt;::pointer</tt>.
This is disadvantageous, because this would not guarantee to induce a total
ordering for native pointers and it is hard to define a total order for mixed
types anyway.
</p>
<p>
The currently suggested resolution for <tt>shared_ptr</tt> comparison as of
<a href="lwg-defects.html#1262">1262</a> uses a normalization strategy: They perform the comparison on
the <em>composite pointer type</em> (5.9 [expr.rel]). This is not
exactly possible for <tt>unique_ptr</tt> in the presence of user-defined
pointer-like types but the existing definition of <tt>std::duration</tt>
comparison as of 20.10.3.6 [time.duration.comparisons] via
<tt>common_type</tt> of both argument types demonstrates a solution of this
problem. The approach can be seen as the general way to define a <em>composite
pointer type</em> and this is the approach which is used for here suggested
wording change.
</p>
<p>
For consistency reasons I would have preferred the same normalization strategy
for <tt>==</tt> and <tt>!=</tt>, but Howard convinced me not to do so (now).
</p>



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

<p>
Change 20.9.10.4 [unique.ptr.special]/4-7 as indicated: <i>[The implicit
requirements and remarks imposed on the last three operators are the same as for
the first one due to the normative "equivalent to" usage within a Requires
element, see 17.5.1.4 [structure.specifications]/4. The effects of this
change are that all real pointers wrapped in a <tt>unique_ptr</tt> will order
like <tt>shared_ptr</tt> does.]</i>
</p>

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

<blockquote>
<p>
<ins><i>Requires:</i> Let <tt>CT</tt> be <tt>common_type&lt;unique_ptr&lt;T1,
D1&gt;::pointer, unique_ptr&lt;T2, D2&gt;::pointer&gt;::type</tt>. Then
<tt>CT</tt> shall satisfy the <tt>LessThanComparable</tt> requirements.</ins>
</p>

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

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

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

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

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

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

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

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






<hr>
<h3><a name="1310"></a>1310. <tt>forward_list splice_after</tt> from lvalues</h3>
<p><b>Section:</b> 23.3.3.5 [forwardlist.ops] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2010-02-05  <b>Last modified:</b> 2010-02-05</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#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
We've moved <a href="lwg-defects.html#1133">1133</a> to Tentatively Ready and I'm fine with that.
</p>

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

</blockquote>






<hr>
<h3><a name="1316"></a>1316. <tt>scoped_allocator_adaptor operator==</tt> has no definition</h3>
<p><b>Section:</b> 20.9.6 [allocator.adaptor] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-02-11  <b>Last modified:</b> 2010-02-11</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The WP 
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>)
contains these declarations:
</p>

<blockquote>
<pre>template &lt;class OuterA1, class OuterA2, class... InnerAllocs&gt;
  bool operator==(const scoped_allocator_adaptor&lt;OuterA1, InnerAllocs...&gt;&amp; a,
                  const scoped_allocator_adaptor&lt;OuterA2, InnerAllocs...&gt;&amp; b);
template &lt;class OuterA1, class OuterA2, class... InnerAllocs&gt;
  bool operator!=(const scoped_allocator_adaptor&lt;OuterA1, InnerAllocs...&gt;&amp; a,
                  const scoped_allocator_adaptor&lt;OuterA2, InnerAllocs...&gt;&amp; b);</pre>
</blockquote>

<p>
But does not define what the behavior of these operators are.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Add a new section after 20.9.6.3 [allocator.adaptor.members]:
</p>

<blockquote>
<p><b>Scoped allocator operators  [scoped.adaptor.operators]</b></p>

<pre>template &lt;class OuterA1, class OuterA2, class... InnerAllocs&gt;
  bool operator==(const scoped_allocator_adaptor&lt;OuterA1, InnerAllocs...&gt;&amp; a,
                  const scoped_allocator_adaptor&lt;OuterA2, InnerAllocs...&gt;&amp; b);</pre>

<blockquote>
<i>Returns:</i> <code>a.outer_allocator() == b.outer_allocator()</code>
if <code>sizeof...(InnerAllocs)</code> is zero; otherwise,
<code>a.outer_allocator() == b.outer_allocator() &amp;&amp;
a.inner_allocator() == b.inner_allocator()</code>.
</blockquote>

<pre>template &lt;class OuterA1, class OuterA2, class... InnerAllocs&gt;
  bool operator!=(const scoped_allocator_adaptor&lt;OuterA1, InnerAllocs...&gt;&amp; a,
                  const scoped_allocator_adaptor&lt;OuterA2, InnerAllocs...&gt;&amp; b);</pre>

<blockquote>
<i>Returns:</i> <code>!(a == b)</code>.
</blockquote>

</blockquote>






<hr>
<h3><a name="1318"></a>1318. N2982 removes previous allocator capabilities</h3>
<p><b>Section:</b> 20.9.4.1 [allocator.traits.types] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2010-02-11  <b>Last modified:</b> 2010-02-25</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>
says that containers should have a nested typedef that defines their
<tt>reference_type</tt> as <tt>value_type&amp;</tt>; the previous
standard deferred to the allocator to define its
<tt>reference_type</tt>, and containers simply passed the allocator's
typedef on. This change is a mistake. Allocators should define both a
<tt>pointer</tt> type and a <tt>reference</tt> type. That's essential
for their original purpose, which was to make different memory models
transparent. If an allocator defines a <tt>pointer</tt> type that isn't
compatible with a normal pointer it also has to define a corresponding
<tt>reference</tt> type. For example (and please forgive a Windows-ism),
if an allocator's pointer is <tt>T __far*</tt>, then it's
<tt>reference</tt> has to be <tt>T __far&amp;</tt>. Otherwise everything
crashes (under the hood, references are pointers and have to have the
same memory access mechanics). Extensions such as this for more general
memory models were explicitly encouraged by C++03, and the allocator's
<tt>pointer</tt> and <tt>reference</tt> typedefs were the hooks for such
extensions. Removing the allocator's <tt>reference</tt> and
<tt>const_reference</tt> typedefs makes those extensions unimplementable
and breaks existing implementations that rely on those hooks.
</p>

<p><i>[
2010-02-25 Alisdair adds:
]</i></p>


<blockquote>
<p>
<tt>vector&lt;bool&gt;::reference</tt> is a nested class, and not a typedef.  It
should be removed from the list of containers when this change is made.
</p>

<p>
In general, I am unfcomfortable placing this reference requirement on each
container, as I would prefer to require:
</p>

<blockquote><pre>
is_same&lt;Container::reference, Container::iterator::reference&gt;
</pre></blockquote>

<p>
This distinction is important, if we intend to support proxy iterators.  The
iterator paper in the pre-Pittsburgh mailing
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3046.html">N3046</a>)
does <em>not</em> make this proposal, but organises clause 24 in such a way this
will be much easier to specify.
</p>

<p>
The changes to clause 20 remain important for all the reasons Pete highlights.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Add the following two rows to Table 40, Allocator requirements:
</p>

<blockquote>
<table border="1">
<caption>Table 40 &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><ins><tt>X::reference</tt></ins></td>

<td><tt></tt></td>

<td><tt></tt></td>

<td><ins><tt>T&amp;</tt></ins></td>
</tr>

<tr>
<td><ins><tt>X::const_reference</tt></ins></td>

<td><tt></tt></td>

<td><tt></tt></td>

<td><ins><tt>const T&amp;</tt></ins></td>
</tr>

</table>
</blockquote>

</li>

<li>
<p>
2. Change the following two rows in Table 40:
</p>

<blockquote>
<table border="1">
<caption>Table 40 &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><ins><tt>*p</tt></ins></td>

<td><tt><del>T&amp;</del> <ins>X::reference</ins></tt></td>

<td><tt></tt></td>

<td></td>
</tr>

<tr>
<td><ins><tt>*q</tt></ins></td>

<td><tt><del>const T&amp;</del> <ins>X::const_reference</ins></tt></td>

<td><tt></tt></td>

<td></td>
</tr>

</table>
</blockquote>

</li>

<li>
<p>
Add the following typedef declarations to allocator_traits 20.9.4 [allocator.traits]:
</p>

<blockquote><pre>
template &lt;class Alloc&gt; struct allocator_traits {
  ...
  <ins>typedef <i>see below</i> reference;</ins>
  <ins>typedef <i>see below</i> const_reference;</ins>
  ...
</pre></blockquote>
</li>

<li>
<p>
Add the following descriptions to 20.9.4.1 [allocator.traits.types]:
</p>

<blockquote>
<pre>typedef see below reference;</pre>
<blockquote>
<i>Type:</i> <tt>Alloc::reference</tt> if such a type exists; otherwise,
<tt>value_type&amp;</tt>.
</blockquote>

<pre>typedef see below const reference;</pre>
<blockquote>
<i>Type:</i> <tt>Alloc::const_reference</tt> if such a type exists; otherwise,
<tt>const value_type&amp;</tt>.
</blockquote>
</blockquote>
</li>

<li>
<p>
Add the following typdef declarations to scoped_allocator_adaptor 20.9.6 [allocator.adaptor]:
</p>

<blockquote><pre>
template &lt;class OuterAlloc, class... InnerAllocs&gt;
class scoped_allocator_adaptor : public OuterAlloc {
  ...
  <ins>typedef typename OuterTraits::reference reference;</ins>
  <ins>typedef typename OuterTraits::const_reference const_reference;</ins>
  ...
</pre></blockquote>
</li>

<li>
<p>
Change the nested typedefs reference and
const_reference to:
</p>

<blockquote><pre>
typedef typename allocator_traits&lt;Allocator&gt;::reference reference;
typedef typename allocator_traits&lt;Allocator&gt;::const_reference const_reference;
</pre></blockquote>

<p>
for each of the following class templates:
</p>

<blockquote>
<tt>deque</tt> 23.3.2 [deque]<br/>
<tt>forward_list</tt> 23.3.3 [forwardlist]<br/>
<tt>list</tt> 23.3.4 [list]<br/>
<tt>queue</tt> 23.3.5.1.1 [queue.defn]<br/>
<tt>priority_queue</tt> 23.3.5.2 [priority.queue]<br/>
<tt>stack</tt> 23.3.5.3.1 [stack.defn]<br/>
<tt>vector</tt> 23.3.6 [vector]<br/>
<tt>vector&lt;bool&gt;</tt> 23.3.7 [vector.bool]<br/>
<tt>map</tt> 23.4.1 [map]<br/>
<tt>multimap</tt> 23.4.2 [multimap]<br/>
<tt>set</tt> 23.4.3 [set]<br/>
<tt>multiset</tt> 23.4.4 [multiset]<br/>
<tt>unordered_map</tt> 23.5.1 [unord.map]<br/>
<tt>unordered_multimap</tt> 23.5.2 [unord.multimap]<br/>
<tt>unordered_set</tt> 23.5.3 [unord.set]<br/>
<tt>unordered_multiset</tt> 23.5.4 [unord.multiset]<br/>
<tt>basic_string</tt> 21.4 [basic.string]<br/>
<tt>match_results</tt> 28.10 [re.results]
</blockquote>
</li>

</ol>





<hr>
<h3><a name="1319"></a>1319. Containers should require an iterator that is at least a Forward Iterator</h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2010-02-16  <b>Last modified:</b> 2010-02-16</p>
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The requirements on container iterators are spelled out in
23.2.1 [container.requirements.general], table 91.
</p>

<blockquote>
<table border="1">
<caption>Table 91 &mdash; Container requirements</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion/note<br/>pre-/post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td colspan="5"><center>...</center></td>
</tr>

<tr>
<td><tt>X::iterator</tt></td>
<td>iterator type whose value type is <tt>T</tt></td>
<td></td>
<td>any iterator category except output iterator. Convertible to
<tt>X::const_iterator</tt>.</td>
<td>compile time</td>
</tr>

<tr>
<td><tt>X::const_iterator</tt></td>
<td>constant iterator type whose value type is <tt>T</tt></td>
<td></td>
<td>any iterator category except output iterator</td>
<td>compile time</td>
</tr>

<tr>
<td colspan="5"><center>...</center></td>
</tr>

</table>
</blockquote>

<p>
As input iterators do not have the multi-pass guarantee, they are not suitable
for iterating over a container.  For example, taking two calls to
<tt>begin()</tt>, incrementing either iterator might invalidate the other. 
While data structures might be imagined where this behaviour produces
interesting and useful results, it is very unlikely to meet the full set of
requirements for a standard container.
</p>



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

<p>
Change Table 91 in 23.2.1 [container.requirements.general] as indicated:
</p>

<blockquote>
<table border="1">
<caption>Table 91 &mdash; Container requirements</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion/note<br/>pre-/post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td colspan="5"><center>...</center></td>
</tr>

<tr>
<td><tt>X::iterator</tt></td>
<td>iterator type whose value type is <tt>T</tt></td>
<td></td>
<td><del>any iterator category except output iterator.</del> <ins>A Forward,
Bidirectional or Random Access Iterator.</ins> Convertible to
<tt>X::const_iterator</tt>.</td>
<td>compile time</td>
</tr>

<tr>
<td><tt>X::const_iterator</tt></td>
<td>constant iterator type whose value type is <tt>T</tt></td>
<td></td>
<td><del>any iterator category except output iterator</del> <ins>A Forward,
Bidirectional or Random Access Iterator.</ins></td>
<td>compile time</td>
</tr>

<tr>
<td colspan="5"><center>...</center></td>
</tr>

</table>
</blockquote>






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

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

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



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

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

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

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






<hr>
<h3><a name="1322"></a>1322. Explicit <tt>CopyConstructible</tt> requirements are insufficient</h3>
<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2010-02-16  <b>Last modified:</b> 2010-03-27</p>
<p><b>View all other</b> <a href="lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
With the acceptance of library defect <a href="lwg-defects.html#822">822</a> only
direct-initialization is supported, and not copy-initialization in the
requirement sets <tt>MoveConstructible</tt> and <tt>CopyConstructible</tt>. This
is usually a good thing, if only the library implementation needs to obey these
restrictions, but the Empire strikes back quickly:
</p>

<ol>
<li>
<p>
<em>Affects user-code</em>: <tt>std::exception_ptr</tt> is defined purely via
requirements, among them <tt>CopyConstructible</tt>. A strict reading of the
standard would make implementations conforming where <tt>std::exception_ptr</tt>
has an explicit copy-c'tor and user-code must code defensively. This is a very
unwanted effect for such an important component like
<tt>std::exception_ptr</tt>.
</p>
</li>

<li>
<p>
<em>Wrong re-use</em>: Recently proposed requirement sets
(<tt>NullablePointer</tt> as of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3025.html">N3025</a>,
Hash) or cleanup of existing requirement sets (e.g. iterator requirements as of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3046.html">N3046</a>)
tend to reuse existing requirement sets, so reusing <tt>CopyConstructible</tt>
is attempting, even in cases, where the intend is to support copy-initialization
as well.
</p>
</li>

<li>
<p>
<em>Inconsistency</em>: The current iterator requirements set Table 102 (output
iterator requirements) and Table 103 (forward iterator requirements) demonstrate
quite clearly a strong divergence of copy-semantics: The specified semantics of
</p>

<blockquote><pre>
X u(a);
X u = a;
</pre></blockquote>

<p>
are underspecified compared to the most recent clarifications of the
<tt>CopyConstructible</tt> requirements, c.f. issue <a href="lwg-defects.html#1309">1309</a> which is
very unsatisfactory. This will become worse for each further issue that involves
the <tt>CopyConstructible</tt> specification (for possible directions see <a href="lwg-active.html#1173">1173</a>).
</p>
</li>
</ol>

<p>
The suggested resolution is to define two further requirements
<tt>implicit-MoveConstructible</tt> and <tt>implicit-CopyConstructible</tt> (or
any other reasonable name like <tt>MoveConvertible</tt> and
<tt>CopyConvertible</tt>) each with a very succinct but precise meaning solving
all three problems mentioned above.
</p>



<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Add the following new table ?? after Table 34 &mdash; <tt>MoveConstructible</tt>
requirements [moveconstructible]:
</p>

<blockquote>

<table border="1">
<caption><ins>Table ?? &mdash; <tt>Implicit MoveConstructible</tt> requirements
[implicit.moveconstructible] (in addition to
<tt>MoveConstructible</tt>)</ins></caption>

<tr>
<th><ins>Expression</ins></th>
<th><ins>Operational Semantics</ins></th>
</tr>

<tr>
<td><ins><tt>T u = rv;</tt></ins></td>
<td><ins>Equivalent to: <tt>T u(rv);</tt></ins></td>
</tr>

</table>
</blockquote>

</li>

<li>
<p>
Add the following new table ?? after Table 35 &mdash; <tt>CopyConstructible</tt>
requirements [copyconstructible]:
</p>

<blockquote>

<table border="1">
<caption><ins>Table ?? &mdash; <tt>Implicit CopyConstructible</tt> requirements
[implicit.copyconstructible] (in addition to
<tt>CopyConstructible</tt>)</ins></caption>

<tr>
<th><ins>Expression</ins></th>
<th><ins>Operational Semantics</ins></th>
</tr>

<tr>
<td><ins><tt>T u = v;</tt></ins></td>
<td><ins>Equivalent to: <tt>T u(v);</tt></ins></td>
</tr>

</table>
</blockquote>

</li>

<li>
<p>
Change 20.2.3 [nullablepointer.requirements]/1 as follows:
</p>

<blockquote>
<p>
A <tt>NullablePointer</tt> type is a pointer-like type that supports null
values. A type <tt>P</tt> meets the requirements of <tt>NullablePointer</tt> if:
</p>

<ul>
<li>
<tt>P</tt> satisfies the requirements of <tt>EqualityComparable</tt>,
<tt>DefaultConstructible</tt>, <tt><ins>implicit</ins> CopyConstructible</tt>,
<tt>CopyAssignable</tt>, and <tt>Destructible</tt>,
</li>

<li>[..]</li>
</ul>
</blockquote>
</li>

<li>
<p>
Change 20.2.4 [hash.requirements]/1 as indicated: <i>[explicit
copy-constructible functors could not be provided as arguments
to any algorithm that takes these by value. Also a typo is fixed.]</i>
</p>

<blockquote>
<p>
1 A type <tt>H</tt> meets the <i>Hash</i> requirements if:
</p>
<ul>
<li>
it is a function object type (20.8),
</li>
<li>
it satis<ins>fies</ins><del>ifes</del> the requirements of
<tt><ins>implicit</ins> CopyConstructible</tt> and <tt>Destructible</tt>
(20.2.1),
</li>
<li>
[..]
</li>
</ul>

</blockquote>

</li>

<li>
<p>
Change 20.7.1 [meta.rqmts]/1+2 as indicated:
</p>

<blockquote>
<p>
1 A <i>UnaryTypeTrait</i> describes a property of a type. It shall be a class
template that takes one template type argument and, optionally, additional
arguments that help define the property being described. It shall be
<tt>DefaultConstructible</tt>, <tt><ins>implicit</ins> CopyConstructible</tt>,
[..]
</p>

<p>
2 A <tt>BinaryTypeTrait</tt> describes a relationship between two types. It
shall be a class template that takes two template type arguments and,
optionally, additional arguments that help define the relationship being
described. It shall be <tt>DefaultConstructible</tt>,
<tt><ins>implicit </ins>CopyConstructible</tt>, and [..]
</p>

</blockquote>

</li>

<li>
<p>
Change 20.8.2 [func.require]/4 as indicated: <i>[explicit
copy-constructible functors could not be provided as arguments to any algorithm
that takes these by value]</i>
</p>

<blockquote>
4 Every call wrapper (20.8.1) shall be <tt><ins>implicit</ins>
MoveConstructible</tt>. A simple call wrapper is a call wrapper that is
<tt><ins>implicit</ins> CopyConstructible</tt> and <tt>CopyAssignable</tt> and
whose copy constructor, move constructor, and assignment operator do not throw
exceptions. [..]
</blockquote>
</li>

<li>
<p>
Change 20.8.4 [refwrap]/1 as indicated:
</p>

<blockquote>
1 <tt>reference_wrapper&lt;T&gt;</tt> is a<ins>n <tt>implicit</tt></ins>
<tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> wrapper around a
reference to an object or function of type <tt>T</tt>.
</blockquote>
</li>

<li>
<p>
Change 20.8.10.1.2 [func.bind.bind]/5+9 as indicated:
</p>

<blockquote>
<p>
5 <i>Remarks:</i> The return type shall satisfy the requirements of
<tt><ins>implicit</ins> MoveConstructible</tt>. If all of <tt>FD</tt> and
<tt>TiD</tt> satisfy the requirements of <tt>CopyConstructible</tt>, then the
return type shall satisfy the requirements of <tt><ins>implicit</ins>
CopyConstructible</tt>. [<i>Note:</i> this implies that all of <tt>FD</tt> and
<tt>TiD</tt> are <tt>MoveConstructible</tt>. &mdash; <i>end note</i>]
</p>

<p>
[..]
</p>

<p>
9 <i>Remarks:</i> The return type shall satisfy the requirements of
<tt><ins>implicit</ins> MoveConstructible</tt>. If all of <tt>FD</tt> and
<tt>TiD</tt> satisfy the requirements of <tt>CopyConstructible</tt>, then the
return type shall satisfy the requirements of <tt><ins>implicit</ins>
CopyConstructible</tt>. [<i>Note:</i> this implies that all of <tt>FD</tt> and
<tt>TiD</tt> are <tt>MoveConstructible</tt>. &mdash; <i>end note</i>]
</p>
</blockquote>

</li>

<li>
<p>
Change 20.8.10.1.3 [func.bind.place] as indicated:
</p>

<blockquote>
1 All placeholder types shall be <tt>DefaultConstructible</tt> and
<tt><ins>implicit</ins> CopyConstructible</tt>, and [..]
</blockquote>
</li>

<li>
<p>
Change 20.9.10 [unique.ptr]/5 as indicated:
</p>

<blockquote>
5 Each object of a type <tt>U</tt> instantiated form the <tt>unique_ptr</tt>
template specified in this subclause has the strict ownership semantics,
specified above, of a unique pointer. In partial satisfaction of these
semantics, each such <tt>U</tt> is <tt><ins>implicit</ins>
MoveConstructible</tt> and <tt>MoveAssignable</tt>, but is not
<tt>CopyConstructible</tt> nor <tt>CopyAssignable</tt>. The template parameter
<tt>T</tt> of <tt>unique_ptr</tt> may be an incomplete type.
</blockquote>
</li>

<li>
<p>
Change 20.9.11.2 [util.smartptr.shared]/2 as indicated:
</p>

<blockquote>
2 Specializations of <tt>shared_ptr</tt> shall be
<tt><ins>implicit</ins> CopyConstructible</tt>, <tt>CopyAssignable</tt>, and
<tt>LessThanComparable</tt>, [..]
</blockquote>
</li>

<li>
<p>
Change 20.9.11.3 [util.smartptr.weak]/2 as indicated:
</p>

<blockquote>
2 Specializations of <tt>weak_ptr</tt> shall be <tt><ins>implicit</ins>
CopyConstructible</tt> and <tt>CopyAssignable</tt>, allowing their use in
standard containers. The template parameter <tt>T</tt> of <tt>weak_ptr</tt> may
be an incomplete type.
</blockquote>
</li>

<li>
<p>
Change 24.2.2 [iterator.iterators]/2 as indicated: <i>[This fixes a
defect in the Iterator requirements. None of the usual algorithms accepting
iterators would be usable with iterators with explicit copy-constructors]</i>
</p>

<blockquote>
<p>
2 A type <tt>X</tt> satisfies the Iterator requirements if:
</p>

<ul>
<li>
<tt>X</tt> satisfies the <tt><ins>implicit</ins> CopyConstructible</tt>,
<tt>CopyAssignable</tt>, and <tt>Destructible</tt> requirements (20.2.1)
and lvalues of type <tt>X</tt> are swappable (20.2.2), and [..]
</li>
<li>...</li>
</ul>

</blockquote>

</li>

<li>
<p>
Change D.10.1 [auto.ptr]/3 as indicated:
</p>

<blockquote>
3 [..] Instances of <tt>auto_ptr</tt> meet the requirements of
<tt><ins>implicit</ins> MoveConstructible</tt> and <tt>MoveAssignable</tt>, but
do not meet the requirements of <tt>CopyConstructible</tt> and
<tt>CopyAssignable</tt>. &mdash; <i>end note</i>]
</blockquote>
</li>

</ol>






<hr>
<h3><a name="1323"></a>1323. <tt>basic_string::replace</tt> should use <tt>const_iterator</tt></h3>
<p><b>Section:</b> 21.4.6.6 [string::replace] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2010-02-19  <b>Last modified:</b> 2010-03-27</p>
<p><b>View all other</b> <a href="lwg-index.html#string::replace">issues</a> in [string::replace].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
In contrast to all library usages of purely positional iterator values several
overloads of <tt>std::basic_string::replace</tt> still use iterator instead of
<tt>const_iterator</tt> arguments. The paper
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3021.pdf">N3021</a>
quite nicely visualizes the purely positional responsibilities of the function
arguments.
</p>

<p>
This should be fixed to make the library consistent, the proposed changes are
quite mechanic.
</p>



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

<li>
<p>
In 21.4 [basic.string], class template <tt>basic_string</tt> synopsis
change as indicated:
</p>

<blockquote><pre>
// 21.4.6 modifiers:
...
basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
                      const basic_string&amp; str);
basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
                      const charT* s, size_type n);
basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
                      const charT* s);
basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
                      size_type n, charT c);
template&lt;class InputIterator&gt;
  basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
                        InputIterator j1, InputIterator j2);
basic_string&amp; replace(<ins>const_</ins>iterator, <ins>const_</ins>iterator,
                      initializer_list&lt;charT&gt;);
</pre></blockquote>
</li>

<li>
<p>
In 21.4.6.6 [string::replace] before p.18, change the following signatures
as indicated:
</p>

<blockquote><pre>
basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2, const basic_string&amp; str);
</pre></blockquote>
</li>

<li>
<p>
In 21.4.6.6 [string::replace] before p.21, change the following signatures
as indicated:
</p>

<blockquote><pre>
basic_string&amp;
  replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2, const charT* s, size_type n);
</pre></blockquote>
</li>

<li>
<p>
In 21.4.6.6 [string::replace] before p.24, change the following signatures
as indicated:
</p>

<blockquote><pre>
basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2, const charT* s);
</pre></blockquote>
</li>

<li>
<p>
In 21.4.6.6 [string::replace] before p.27, change the following signatures
as indicated:
</p>

<blockquote><pre>
basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2, size_type n,
                      charT c);
</pre></blockquote>
</li>

<li>
<p>
In 21.4.6.6 [string::replace] before p.30, change the following signatures
as indicated:
</p>

<blockquote><pre>
template&lt;class InputIterator&gt;
  basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
                        InputIterator j1, InputIterator j2);
</pre></blockquote>
</li>

<li>
<p>
In 21.4.6.6 [string::replace] before p.33, change the following signatures
as indicated:
</p>

<blockquote><pre>
basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
                      initializer_list&lt;charT&gt; il);
</pre></blockquote>
</li>

</ol>






<hr>
<h3><a name="1324"></a>1324. Still too many implicit conversions for <tt>pair</tt> and  <tt>tuple</tt></h3>
<p><b>Section:</b> 20.3.5.2 [pairs.pair], 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2010-03-20  <b>Last modified:</b> 2010-03-27</p>
<p><b>View other</b> <a href="lwg-index-open.html#pairs.pair">active issues</a> in [pairs.pair].</p>
<p><b>View all other</b> <a href="lwg-index.html#pairs.pair">issues</a> in [pairs.pair].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In analogy to library defect <a href="lwg-defects.html#811">811</a>, <tt>tuple</tt>'s variadic
constructor
</p>

<blockquote><pre>
template &lt;class... UTypes&gt;
explicit tuple(UTypes&amp;&amp;... u);
</pre></blockquote>

<p>
creates the same problem as pair:
</p>

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

int main()
{
  std::tuple&lt;char*&gt; p(0);
}
</pre></blockquote>

<p>
produces a similar compile error for a recent gcc implementation.
</p>

<p>
I suggest to follow the same resolution path as has been applied to
<tt>pair</tt>'s corresponding c'tor, that is require that these c'tors should
not participate in overload resolution, if the arguments are not implicitly
convertible to the element types.
</p>

<p>
Further-on both <tt>pair</tt> and <tt>tuple</tt> provide converting constructors
from different <tt>pairs</tt>/<tt>tuples</tt> that should be not available, if
the corresponding element types are not implicitly convertible. It seems
astonishing that in the following example
</p>

<blockquote><pre>
struct A {
  explicit A(int);
};

A  a = 1; <font color="#C80000">// Error</font>

std::tuple&lt;A&gt; ta = std::make_tuple(1); <font color="#C80000">// # OK?</font>
</pre></blockquote>

<p>
the initialization marked with # could be well-formed.
</p>


<p><b>Proposed resolution:</b></p>
<p><i>[
Only constraints on constructors are suggested. Adding similar constraints on
assignment operators is considered as QoI, because the assigments wouldn't be
well-formed anyway.
]</i></p>


<ol>

<li>
<p>
Following 20.3.5.2 [pairs.pair]/5 add a new Remarks element:
</p>

<blockquote><pre>
template&lt;class U, class V&gt; pair(const pair&lt;U, V&gt;&amp; p);
</pre>

<blockquote>
<p>
5 <i>Effects:</i> Initializes members from the corresponding members of the
argument<del>, performing implicit conversions as needed</del>.
</p>

<p>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution unless <tt>U</tt> is implicitly convertible to <tt>first_type</tt>
and <tt>V</tt> is implicitly convertible to <tt>second_type</tt>.</ins>
</p>
</blockquote>
</blockquote>

</li>

<li>
<p>
Following 20.3.5.2 [pairs.pair]/6 add a new Remarks element:
</p>

<blockquote><pre>
template&lt;class U, class V&gt; pair(pair&lt;U, V&gt;&amp;&amp; p);
</pre>

<blockquote>
<p>
6 <i>Effects:</i> The constructor initializes <tt>first</tt> with
<tt>std::move(p.first)</tt> and second with <tt>std::move(p.second)</tt>.
</p>

<p>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution unless <tt>U</tt> is implicitly convertible to <tt>first_type</tt>
and <tt>V</tt> is implicitly convertible to <tt>second_type</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Following 20.4.2.1 [tuple.cnstr]/7 add a new Remarks element:
</p>

<blockquote><pre>
template &lt;class... UTypes&gt;
explicit tuple(UTypes&amp;&amp;... u);
</pre>

<blockquote>
<p>
6 <i>Requires:</i> Each type in <tt>Types</tt> shall satisfy the requirements of
<tt>MoveConstructible</tt> (Table 33) from the corresponding type in
<tt>UTypes</tt>. <tt>sizeof...(Types) == sizeof...(UTypes)</tt>.
</p>

<p>
7 <i>Effects:</i> Initializes the elements in the <tt>tuple</tt> with the
corresponding value in <tt>std::forward&lt;UTypes&gt;(u)</tt>.
</p>

<p>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution unless each type in <tt>UTypes</tt> is implicitly convertible to its
corresponding type in <tt>Types</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Following 20.4.2.1 [tuple.cnstr]/13 add a new Remarks element:
</p>

<blockquote><pre>
template &lt;class... UTypes&gt; tuple(const tuple&lt;UTypes...&gt;&amp; u);
</pre>

<blockquote>
<p>
12 <i>Requires:</i> Each type in <tt>Types</tt> shall be constructible from the
corresponding type in <tt>UTypes</tt>. <tt>sizeof...(Types) ==
sizeof...(UTypes)</tt>.
</p>

<p>
13 <i>Effects:</i> Constructs each element of <tt>*this</tt> with the
corresponding element of <tt>u</tt>.
</p>

<p>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution unless each type in <tt>UTypes</tt> is implicitly convertible to its
corresponding type in <tt>Types</tt>.</ins>
</p>

<p>
14 [<i>Note:</i> <tt>enable_if</tt> can be used to make the converting
constructor and assignment operator exist only in the cases where the source and
target have the same number of elements. &mdash; <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Following 20.4.2.1 [tuple.cnstr]/16 add a new Remarks element:
</p>

<blockquote><pre>
template &lt;class... UTypes&gt; tuple(tuple&lt;UTypes...&gt;&amp;&amp; u);
</pre>

<blockquote>
<p>
15 <i>Requires:</i> Each type in <tt>Types</tt> shall shall satisfy the
requirements of <tt>MoveConstructible</tt> (Table 33) from the corresponding
type in <tt>UTypes</tt>. <tt>sizeof...(Types) == sizeof...(UTypes)</tt>.
</p>

<p>
16 <i>Effects:</i> Move-constructs each element of <tt>*this</tt> with the
corresponding element of <tt>u</tt>.
</p>

<p>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution unless each type in <tt>UTypes</tt> is implicitly convertible to its
corresponding type in <tt>Types</tt>.</ins>
</p>

<p>
[<i>Note:</i> <tt>enable_if</tt> can be used to make the converting constructor
and assignment operator exist only in the cases where the source and target have
the same number of elements. &mdash; <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Following 20.4.2.1 [tuple.cnstr]/18 add a new Remarks element:
</p>

<blockquote><pre>
template &lt;class U1, class U2&gt; tuple(const pair&lt;U1, U2&gt;&amp; u);
</pre>

<blockquote>
<p>
17 <i>Requires:</i> The first type in <tt>Types</tt> shall be constructible from
<tt>U1</tt> and the second type in <tt>Types</tt> shall be constructible from
<tt>U2</tt>. <tt>sizeof...(Types) == 2</tt>.
</p>

<p>
18 <i>Effects:</i> Constructs the first element with <tt>u.first</tt> and the
second element with <tt>u.second</tt>.
</p>

<p>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution unless <tt>U1</tt> is implicitly convertible to the first type in
<tt>Types</tt> and <tt>U2</tt> is implicitly convertible to the second type in
<tt>Types</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Following 20.4.2.1 [tuple.cnstr]/20 add a new Remarks element:
</p>

<blockquote><pre>
template &lt;class U1, class U2&gt; tuple(pair&lt;U1, U2&gt;&amp;&amp; u);
</pre>

<blockquote>
<p>
19 <i>Requires:</i> The first type in <tt>Types</tt> shall shall satisfy the
requirements of <tt>MoveConstructible</tt>(Table 33) from <tt>U1</tt> and the
second type in <tt>Types</tt> shall be move-constructible from <tt>U2</tt>.
<tt>sizeof...(Types) == 2</tt>.
</p>

<p>
20 <i>Effects:</i> Constructs the first element with <tt>std::move(u.first)</tt>
and the second element with <tt>std::move(u.second)</tt>
</p>

<p>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution unless <tt>U1</tt> is implicitly convertible to the first type in
<tt>Types</tt> and <tt>U2</tt> is implicitly convertible to the second type in
<tt>Types</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="1325"></a>1325. bitset</h3>
<p><b>Section:</b> 20.5.1 [bitset.cons] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Christopher Jefferson <b>Opened:</b> 2010-03-07  <b>Last modified:</b> 2010-03-15</p>
<p><b>View all other</b> <a href="lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As mentioned on the boost mailing list:
</p>

<p>
The following code, valid in C++03, is broken in C++0x due to ambiguity
between the "<tt>unsigned long long</tt>" and "<tt>char*</tt>"
constructors.
</p>

<blockquote><pre>
#include &lt;bitset&gt;
std::bitset&lt;10&gt; b(0);
</pre></blockquote>

<p><i>[
The proposed resolution has been reviewed by Stephan T. Lavavej.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
In WD N3035, 20.5 [template.bitset]/1, replace the fourth
bitset constructor:
</p>

<blockquote><pre>
<del>explicit bitset(const char *str);</del>
<ins>template &lt;class charT&gt;
   explicit bitset(
     const charT *str,
     typename basic_string&lt;charT&gt;::size_type pos = 0,
     typename basic_string&lt;charT&gt;::size_type n =
       basic_string&lt;charT&gt;::npos,
     charT zero = charT('0'), charT one = charT('1'));</ins>
</pre></blockquote>

<p>
And in 20.5.1 [bitset.cons]/8:
</p>

<blockquote><pre>
<del>explicit bitset(const char *str);</del>
</pre>
<blockquote>
<del><i>Effects:</i> Constructs an object of class
<tt>bitset&lt;N&gt;</tt> as if by <tt>bitset(string(str))</tt>.</del>
</blockquote>

<pre>
<ins>template &lt;class charT&gt;
 explicit
 bitset(const charT *str,
   typename basic_string&lt;charT&gt;::size_type pos = 0,
   typename basic_string&lt;charT&gt;::size_type n =
     basic_string&lt;charT&gt;::npos,
     charT zero = charT('0'), charT one = charT('1'));</ins>
</pre>

<blockquote>
<ins><i>Effects:</i> Constructs an object of class <tt>bitset&lt;N&gt;</tt>
as if by <tt>bitset(basic_string&lt;charT&gt;(str), pos, n, zero,
one)</tt>.</ins>
</blockquote>
</blockquote>





<hr>
<h3><a name="1326"></a>1326. Missing/wrong preconditions for <tt>pair</tt> and <tt>tuple</tt> functions</h3>
<p><b>Section:</b> 20.3.5.2 [pairs.pair], 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2010-03-07  <b>Last modified:</b> 2010-03-27</p>
<p><b>View other</b> <a href="lwg-index-open.html#pairs.pair">active issues</a> in [pairs.pair].</p>
<p><b>View all other</b> <a href="lwg-index.html#pairs.pair">issues</a> in [pairs.pair].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There are several constructors and creation functions of std::tuple
that impose requirements on it's arguments, that are unnecessary
restrictive and don't match the intention for the supported argument
types. This is related to the fact that tuple is supposed to accept both
object types and lvalue-references and the usual MoveConstructible and
CopyConstructible requirements are bad descriptions for non-const
references. Some examples:
</p>

<ol type="a">
<li>
<p>
20.4.2.1 [tuple.cnstr] before p.4 and p.8, resp.:
</p>

<blockquote><pre>
explicit tuple(const Types&amp;...);
</pre>
<blockquote>
4 <i>Requires:</i> Each type in <tt>Types</tt> shall be copy constructible.
</blockquote>

<pre>
tuple(const tuple& u) = default;
</pre>
<blockquote>
8 <i>Requires:</i> Each type in <tt>Types</tt> shall satisfy the requirements of
<tt>CopyConstructible</tt> (Table 34).

</blockquote>
</blockquote>

<p>
A tuple that contains lvalue-references to non-const can never
satisfy the <tt>CopyConstructible</tt> requirements. <tt>CopyConstructible</tt>
requirements <i>refine</i> the <tt>MoveConstructible</tt> requirements and
this would require that these lvalue-references could bind
rvalues. But the core language does not allow that. Even, if we
would interpret that requirement as referring to the underlying
non-reference type, this requirement would be wrong as well,
because there is no reason to disallow a type such as
</p>

<blockquote><pre>
struct NoMoveNoCopy {
  NoMoveNoCopy(NoMoveNoCopy&amp;&amp;) = delete;
  NoMoveNoCopy(const NoMoveNoCopy&amp;) = delete;
  ...
}:
</pre></blockquote>

<p>
for the instantiation of <tt>std::tuple&lt;NoMoveNoCopy&amp;&gt;</tt> and
that of it's copy constructor.
</p>

<p>
A more reasonable requirement for this example would be to require that
"<tt>is_constructible&lt;Ti, const Ti&amp;&gt;::value</tt> shall
evaluate to true for all <tt>Ti</tt> in <tt>Types</tt>". In this case
the special reference-folding and const-merging rules of references
would make this well-formed in all cases. We could also add the further
constraint "if <tt>Ti</tt> is an object type, it shall satisfy the
<tt>CopyConstructible</tt> requirements", but this additional
requirement seems not really to help here. Ignoring it would only mean
that if a user would provide a curious object type <tt>C</tt> that
satisfies the <tt>std::is_constructible&lt;C, const C&amp;&gt;</tt>
test, but not the "<tt>C</tt> is <tt>CopyConstructible</tt>" test would
produce a <tt>tuple&lt;C&gt;</tt> that does not satisfy the
<tt>CopyConstructible</tt> requirements as well.
</p>
</li>

<li>
<p>
20.4.2.1 [tuple.cnstr] before p.6 and p.10, resp.:
</p>

<blockquote><pre>
template &lt;class... UTypes&gt;
explicit tuple(UTypes&amp;&amp;... u);
</pre>

<blockquote>
6 <i>Requires:</i> Each type in <tt>Types</tt> shall satisfy the
requirements of <tt>MoveConstructible</tt> (Table 33) from the
corresponding type in <tt>UTypes</tt>. <tt>sizeof...(Types) ==
sizeof...(UTypes)</tt>.
</blockquote>

<pre>
tuple(tuple&amp;&amp; u);
</pre>
<blockquote>
10 <i>Requires:</i> Each <tt>type</tt> in <tt>Types</tt> shall shall
satisfy the requirements of <tt>MoveConstructible</tt> (Table 33).
</blockquote>
</blockquote>

<p>
We have a similar problem as in (a): Non-const lvalue-references
are intended template arguments for <tt>std::tuple</tt>, but cannot satisfy
the <tt>MoveConstructible</tt> requirements. In this case the correct
requirements would be
</p>

<blockquote>
<tt>is_constructible&lt;Ti, Ui&gt;::value</tt> shall evaluate to true
for all <tt>Ti</tt> in <tt>Types</tt> and for all <tt>Ui</tt> in
<tt>UTypes</tt>
</blockquote>

<p>
and
</p>

<blockquote>
<tt>is_constructible&lt;Ti, Ti&gt;::value</tt> shall evaluate to true
for all <tt>Ti</tt> in <tt>Types</tt>
</blockquote>

<p>
respectively.
</p>
</li>
</ol>

<p>
Many <tt>std::pair</tt> member functions do not add proper requirements, e.g.
the default c'tor does not require anything. This is corrected within the
suggested resolution. Further-on the P/R has been adapted to the FCD numbering.
</p>

<p><i>[
2010-03-25 Daniel updated wording:
]</i></p>


<blockquote>
The issue became updated to fix some minor inconsistencies and to ensure a
similarly required fix for <tt>std::pair</tt>, which has the same specification
problem as <tt>std::tuple</tt>, since <tt>pair</tt> became extended to support
reference members as well.
</blockquote>



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

<li>
<p>
Change 20.3.5.2 [pairs.pair]/1 as indicated <i>[The changes for the effects
elements are not normative changes, they just ensure
harmonization with existing wording style]</i>:
</p>

<blockquote><pre>
constexpr pair();
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> <tt>first_type</tt> and <tt>second_type</tt> shall satisfy
the <tt>DefaultConstructible</tt> requirements.</ins>
</p>

<p>
1 <i>Effects:</i> <ins>Value-initializes <tt>first</tt> and
<tt>second</tt>.</ins><del>Initializes its members as if implemented: <tt>pair()
: first(), second() { }</tt>.</del>
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.3.5.2 [pairs.pair]/2 as indicated:
</p>

<blockquote><pre>
pair(const T1&amp; x, const T2&amp; y);
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> <tt>is_constructible&lt;T1, const T1&amp;&gt;::value</tt>
is <tt>true</tt> and <tt>is_constructible&lt;T2, const T2&amp;&gt;::value</tt>
is <tt>true</tt>.</ins>
</p>

<p>
2 <i>Effects:</i> The constructor initializes <tt>first</tt> with <tt>x</tt> and
<tt>second</tt> with <tt>y</tt>.
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.3.5.2 [pairs.pair]/3 as indicated:
</p>

<blockquote><pre>
template&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; y);
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> <tt>is_constructible&lt;first_type, U&gt;::value</tt> is
<tt>true</tt> and <tt>is_constructible&lt;second_type, V&gt;::value</tt> is
<tt>true</tt>.</ins>
</p>

<p>
3 <i>Effects:</i> The constructor initializes <tt>first</tt> with
<tt>std::forward&lt;U&gt;(x)</tt> and <tt>second</tt> with
<tt>std::forward&lt;V&gt;(y)</tt>.
</p>

<p>
4 <i>Remarks:</i> If <tt>U</tt> is not implicitly convertible to
<tt>first_type</tt> or <tt>V</tt> is not implicitly convertible to
<tt>second_type</tt> this constructor shall not participate in overload
resolution.
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.3.5.2 [pairs.pair]/5 as indicated <i>[The change in the effects
element should be non-normatively and is in compatible to the change suggestion
of <a href="lwg-active.html#1324">1324</a>]</i>:
</p>

<blockquote><pre>
template&lt;class U, class V&gt; pair(const pair&lt;U, V&gt;&amp; p);
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> <tt>is_constructible&lt;first_type, const
U&amp;&gt;::value</tt> is <tt>true</tt> and <tt>is_constructible&lt;second_type,
const V&amp;&gt;::value</tt> is <tt>true</tt>.</ins>
</p>

<p>
5 <i>Effects:</i> Initializes members from the corresponding members of the
argument<del>, performing implicit conversions as needed</del>.
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.3.5.2 [pairs.pair]/6 as indicated:
</p>

<blockquote><pre>
template&lt;class U, class V&gt; pair(pair&lt;U, V&gt;&amp;&amp; p);
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> <tt>is_constructible&lt;first_type, U&gt;::value</tt> is
<tt>true</tt> and <tt>is_constructible&lt;second_type, V&gt;::value</tt> is
<tt>true</tt>.</ins>
</p>

<p>
6 <i>Effects:</i> The constructor initializes <tt>first</tt> with
<tt>std::<del>move</del><ins>forward&lt;U&gt;</ins>(p.first)</tt> and
<tt>second</tt> with
<tt>std::<del>move</del><ins>forward&lt;V&gt;</ins>(p.second)</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.3.5.2 [pairs.pair]/7+8 as indicated [The deletion in the effects
element should be non-normatively]:
</p>

<blockquote><pre>
template&lt;class... Args1, class... Args2&gt;
  pair(piecewise_construct_t,
       tuple&lt;Args1...&gt; first_args, tuple&lt;Args2...&gt; second_args);
</pre>

<blockquote>
<p>
7 <i>Requires:</i> <ins><tt>is_constructible&lt;first_type,
Args1...&gt;::value</tt> is <tt>true</tt> and
<tt>is_constructible&lt;second_type, Args2...&gt;::value</tt> is
<tt>true</tt>.</ins> <del>All the types in <tt>Args1</tt> and <tt>Args2</tt>
shall be <tt>CopyConstructible</tt> (Table 35). <tt>T1</tt> shall be
constructible from <tt>Args1</tt>. <tt>T2</tt> shall be constructible from
<tt>Args2</tt>.</del>
</p>

<p>
8 <i>Effects:</i> The constructor initializes <tt>first</tt> with arguments of
types <tt>Args1...</tt> obtained by forwarding the elements of
<tt>first_args</tt> and initializes <tt>second</tt> with arguments of types
<tt>Args2...</tt> obtained by forwarding the elements of <tt>second_args</tt>.
<del>(Here, forwarding an element <tt>x</tt> of type <tt>U</tt> within a
<tt>tuple</tt> object means calling <tt>std::forward&lt;U&gt;(x)</tt>.)</del>
This form of construction, whereby constructor arguments for <tt>first</tt> and
<tt>second</tt> are each provided in a separate <tt>tuple</tt> object, is called
piecewise construction.
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.3.5.2 [pairs.pair] before 12 as indicated:
</p>

<blockquote><pre>
pair&amp; operator=(pair&amp;&amp; p);
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> <tt>first_type</tt> and <tt>second_type</tt> shall satisfy
the <tt>MoveAssignable</tt> requirements.</ins>
</p>

<p>
12 <i>Effects:</i> Assigns to <tt>first</tt> with <tt>std::move(p.first)</tt>
and to <tt>second</tt> with <tt>std::move(p.second)</tt>.
</p>

<p>
13 <i>Returns:</i> <tt>*this</tt>.
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change [pairs.pair] before 14 as indicated: [The heterogeneous usage
of MoveAssignable is actually not defined,
but the library uses it at several places, so we follow this tradition
until a better term has been agreed on. One
alternative could be to write "first_type shall be assignable from an
rvalue of U [..]"]
</p>

<blockquote><pre>
template&lt;class U, class V&gt; pair&amp; operator=(pair&lt;U, V&gt;&amp;&amp; p);
</pre>

<blockquote>

<p>
<ins><i>Requires:</i> <tt>first_type</tt> shall be <tt>MoveAssignable</tt> from
<tt>U</tt> and <tt>second_type</tt> shall be <tt>MoveAssignable</tt> from
<tt>V</tt>.</ins>
</p>

<p>
14 <i>Effects:</i> Assigns to <tt>first</tt> with <tt>std::move(p.first)</tt>
and to <tt>second</tt> with <tt>std::move(p.second)</tt>.
</p>

<p>
15 <i>Returns:</i> <tt>*this</tt>.
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.4.2.1 [tuple.cnstr]/4+5 as indicated:
</p>

<blockquote><pre>
explicit tuple(const Types&amp;...);
</pre>

<blockquote>
<p>
4 <i>Requires:</i> <ins><tt>is_constructible&lt;Ti, const
Ti&amp;&gt;::value == true</tt> for e</ins><del>E</del>ach type
<ins><tt>Ti</tt></ins> in <tt>Types</tt><del> shall be copy
constructible</del>.
</p>

<p>
5 <i>Effects:</i> <del>Copy i</del><ins>I</ins>nitializes each element with the
value of the corresponding parameter.
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.4.2.1 [tuple.cnstr]/6 as indicated:
</p>

<blockquote><pre>
template &lt;class... UTypes&gt;
explicit tuple(UTypes&amp;&amp;... u);
</pre>

<blockquote>
<p>
6 <i>Requires:</i> <ins><tt>is_constructible&lt;Ti, Ui&gt;::value ==
true</tt> for e</ins><del>E</del>ach type <ins><tt>Ti</tt></ins> in
<tt>Types</tt> <del>shall satisfy the requirements of
<tt>MoveConstructible</tt> (Table 33) from</del><ins>and for</ins> the
corresponding type <ins><tt>Ui</tt></ins> in <tt>UTypes</tt>.
<tt>sizeof...(Types) == sizeof...(UTypes)</tt>.
</p>

<p>
7 <i>Effects:</i> Initializes the elements in the <tt>tuple</tt> with the
corresponding value in <tt>std::forward&lt;UTypes&gt;(u)</tt>.
</p>

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

<li>
<p>
Change 20.4.2.1 [tuple.cnstr]/8+9 as indicated:
</p>

<blockquote><pre>
tuple(const tuple&amp; u) = default;
</pre>

<blockquote>
<p>
8 <i>Requires:</i> <ins><tt>is_constructible&lt;Ti, const
Ti&amp;&gt;::value == true</tt> for e</ins><del>E</del>ach type
<ins><tt>Ti</tt></ins> in <tt>Types</tt><del> shall satisfy the
requirements of <tt>CopyConstructible</tt>(Table 34)</del>.
</p>

<p>
9 <i>Effects:</i> <ins>Initializes</ins><del>Copy constructs</del> each element
of <tt>*this</tt> with the corresponding element of <tt>u</tt>.
</p>

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

<li>
<p>
Change 20.4.2.1 [tuple.cnstr]/10+11 as indicated:
</p>

<blockquote><pre>
tuple(tuple&amp;&amp; u);
</pre>

<blockquote>
<p>
10 <i>Requires:</i> <ins>Let <tt>i</tt> be in <tt>[0, sizeof...(Types))</tt> and
let <tt>Ti</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>Types</tt>.
Then <tt>is_constructible&lt;Ti, Ti&gt;::value</tt> shall be <tt>true</tt> for
all <tt>i</tt>.</ins> <del>Each type in <tt>Types</tt> shall shall satisfy the
requirements of <tt>MoveConstructible</tt> (Table 34)</del>.
</p>

<p>
11 <i>Effects:</i> <ins>For each <tt>Ti</tt> in <tt>Types</tt>, initializes the
<tt>i</tt><sup><i>th</i></sup></ins> <del>Move-constructs each</del> element of
<tt>*this</tt> with <del>the corresponding element of</del>
<ins><tt>std::forward&lt;Ti&gt;(get&lt;i&gt;(</tt></ins><tt>u</tt><ins><tt>))</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.4.2.1 [tuple.cnstr]/15+16 as indicated:
</p>

<blockquote><pre>
template &lt;class... UTypes&gt; tuple(tuple&lt;UTypes...&gt;&amp;&amp; u);
</pre>

<blockquote>
<p>
15 <i>Requires:</i> <ins>Let <tt>i</tt> be in <tt>[0, sizeof...(Types))</tt>,
<tt>Ti</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>Types</tt>, and
<tt>Ui</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>UTypes</tt>. Then
<tt>is_constructible&lt;Ti, Ui&gt;::value</tt> shall be <tt>true</tt> for all
<tt>i</tt>.</ins> <del>Each type in <tt>Types</tt> shall shall satisfy the
requirements of <tt>MoveConstructible</tt> (Table 34) from the corresponding
type in <tt>UTypes</tt></del>. <tt>sizeof...(Types) == sizeof...(UTypes)</tt>.
</p>

<p>
16 <i>Effects:</i> <ins>For each type <tt>Ti</tt>, initializes the
<tt>i</tt><sup><i>th</i></sup></ins> <del>Move-constructs each</del> element of
<tt>*this</tt> with <del>the corresponding element of</del>
<ins><tt>std::forward&lt;Ui&gt;(get&lt;i&gt;(</tt></ins><tt>u</tt><ins><tt>))</tt></ins>.
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.4.2.1 [tuple.cnstr]/19+20 as indicated:
</p>

<blockquote><pre>
template &lt;class U1, class U2&gt; tuple(pair&lt;U1, U2&gt;&amp;&amp; u);
</pre>

<blockquote>
<p>
19 <i>Requires:</i> <ins><tt>is_constructible&lt;T1, U1&gt;::value ==
true</tt> for <tt>t</tt></ins><del><tt>T</tt></del>he first type
<ins><tt>T1</tt></ins> in <tt>Types</tt> <del>shall shall satisfy the
requirements of <tt>MoveConstructible</tt>(Table 33) from
<tt>U1</tt></del> and <ins><tt>is_constructible&lt;T2, U2&gt;::value ==
true</tt> for</ins> the second type <ins><tt>T2</tt></ins> in
<tt>Types</tt> <del>shall be move-constructible from <tt>U2</tt></del>.
<tt>sizeof...(Types) == 2</tt>.
</p>

<p>
20 <i>Effects:</i> <ins>Initializes</ins><del>Constructs</del> the first
element with
<tt>std::<ins>forward&lt;U1&gt;</ins><del>move</del>(u.first)</tt> and
the second element with
<tt>std::<ins>forward&lt;U2&gt;</ins><del>move</del>(u.second)</tt>.
</p>

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

<li>
<p>
Change 20.4.2.4 [tuple.creation]/9-16 as indicated:
</p>

<blockquote><pre>
template &lt;class... TTypes, class... UTypes&gt;
tuple&lt;TTypes..., UTypes...&gt; tuple_cat(const tuple&lt;TTypes...&gt;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);
</pre>

<blockquote>
<p>
9 <i>Requires:</i> <ins><tt>is_constructible&lt;Ti, const
Ti&amp;&gt;::value == true</tt> for each type <tt>Ti</tt></ins><del>All
the types</del> in <tt>TTypes</tt> <del>shall be
<tt>CopyConstructible</tt> (Table 34)</del>.
<ins><tt>is_constructible&lt;Ui, const Ui&amp;&gt;::value == true</tt>
for each type <tt>Ui</tt></ins><del>All the types</del> in
<tt>UTypes</tt> <del>shall be <tt>CopyConstructible</tt> (Table
34)</del>.
</p>

<p>
10 <i>Returns:</i> A <tt>tuple</tt> object constructed by
<ins>initializing</ins><del>copy constructing</del> its first
<tt>sizeof...(TTypes)</tt> elements from the corresponding elements of
<tt>t</tt> and <ins>initializing</ins><del>copy constructing</del> its
last <tt>sizeof...(UTypes)</tt> elements from the corresponding elements
of <tt>u</tt>.
</p>
</blockquote>

<pre>
template &lt;class... TTypes, class... UTypes&gt;
tuple&lt;TTypes..., UTypes...&gt; tuple_cat(tuple&lt;TTypes...&gt;&amp;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);
</pre>

<blockquote>
<p>
11 <i>Requires:</i> <ins>Let <tt>i</tt> be in <tt>[0, sizeof...(TTypes))</tt>,
<tt>Ti</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>Types</tt>,
<tt>j</tt> be in <tt>[0, sizeof...(UTypes))</tt>, and <tt>Uj</tt> be the
<tt>j</tt><sup><i>th</i></sup> type in <tt>UTypes</tt>.
<tt>is_constructible&lt;Ti, Ti&gt;::value</tt> shall be <tt>true</tt> for each
type <tt>Ti</tt> and <tt>is_constructible&lt;Uj, const Uj&amp;&gt;::value</tt>
shall be <tt>true</tt> for each type <tt>Uj</tt></ins> <del>All the types in
<tt>TTypes</tt> shall be <tt>MoveConstructible</tt> (Table 34). All the types in
<tt>UTypes</tt> shall be <tt>CopyConstructible</tt> (Table 35)</del>.
</p>

<p>
12 <i>Returns:</i> A <tt>tuple</tt> object constructed by <ins>initializing the
<tt>i</tt><sup><i>th</i></sup> element with
<tt>std::forward&lt;Ti&gt;(get&lt;i&gt;(t))</tt> for all <tt>Ti</tt> in
<tt>TTypes</tt> and initializing the
<tt>(j+sizeof...(TTypes))</tt><sup><i>th</i></sup> element with
<tt>get&lt;j&gt;(u)</tt> for all <tt>Uj</tt> in <tt>UTypes</tt>.</ins> <del>move
constructing its first <tt>sizeof...(TTypes)</tt> elements from the
corresponding elements of <tt>t</tt> and copy constructing its last
<tt>sizeof...(UTypes)</tt> elements from the corresponding elements of
<tt>u</tt></del>.
</p>
</blockquote>

<pre>
template &lt;class... TTypes, class... UTypes&gt;
tuple&lt;TTypes..., UTypes...&gt; tuple_cat(const tuple&lt;TTypes...&gt;&amp; t, tuple&lt;UTypes...&gt;&amp;&amp; u);
</pre>

<blockquote>
<p>
13 <i>Requires:</i> <ins>Let <tt>i</tt> be in <tt>[0, sizeof...(TTypes))</tt>,
<tt>Ti</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>Types</tt>,
<tt>j</tt> be in <tt>[0, sizeof...(UTypes))</tt>, and <tt>Uj</tt> be the
<tt>j</tt><sup><i>th</i></sup> type in <tt>UTypes</tt>.
<tt>is_constructible&lt;Ti, const Ti&amp;&gt;::value</tt> shall be <tt>true</tt>
for each type <tt>Ti</tt> and <tt>is_constructible&lt;Uj, Uj&gt;::value</tt>
shall be <tt>true</tt> for each type <tt>Uj</tt></ins> <del>All the types in
<tt>TTypes</tt> shall be <tt>CopyConstructible</tt> (Table 35). All the types in
<tt>UTypes</tt> shall be <tt>MoveConstructible</tt> (Table 34)</del>.
</p>

<p>
14 <i>Returns:</i> A <tt>tuple</tt> object constructed by <ins>initializing the
<tt>i</tt><sup><i>th</i></sup> element with <tt>get&lt;i&gt;(t)</tt> for each
type <tt>Ti</tt> and initializing the
<tt>(j+sizeof...(TTypes))</tt><sup><i>th</i></sup> element with
<tt>std::forward&lt;Uj&gt;(get&lt;j&gt;(u))</tt> for each type <tt>Uj</tt></ins>
<del>copy constructing its first <tt>sizeof...(TTypes)</tt> elements from the
corresponding elements of <tt>t</tt> and move constructing its last
<tt>sizeof...(UTypes)</tt> elements from the corresponding elements of
<tt>u</tt></del>.
</p>
</blockquote>

<pre>
template &lt;class... TTypes, class... UTypes&gt;
tuple&lt;TTypes..., UTypes...&gt; tuple_cat(tuple&lt;TTypes...&gt;&amp;&amp; t, tuple&lt;UTypes...&gt;&amp;&amp; u);
</pre>

<blockquote>
<p>
15 <i>Requires:</i> <ins>Let <tt>i</tt> be in <tt>[0, sizeof...(TTypes))</tt>,
<tt>Ti</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>Types</tt>,
<tt>j</tt> be in <tt>[0, sizeof...(UTypes))</tt>, and <tt>Uj</tt> be the
<tt>j</tt><sup><i>th</i></sup> type in <tt>UTypes</tt>.
<tt>is_constructible&lt;Ti, Ti&gt;::value</tt> shall be <tt>true</tt> for each
type <tt>Ti</tt> and <tt>is_constructible&lt;Uj, Uj&gt;::value</tt> shall be
<tt>true</tt> for each type <tt>Uj</tt></ins> <del>All the types in
<tt>TTypes</tt> shall be <tt>MoveConstructible</tt> (Table 34). All the types in
<tt>UTypes</tt> shall be <tt>MoveConstructible</tt> (Table 34)</del>.
</p>

<p>
16 <i>Returns:</i> A <tt>tuple</tt> object constructed by <ins>initializing the
<tt>i</tt><sup><i>th</i></sup> element with
<tt>std::forward&lt;Ti&gt;(get&lt;i&gt;(t))</tt> for each type <tt>Ti</tt> and
initializing the <tt>(j+sizeof...(TTypes))</tt><sup><i>th</i></sup> element with
<tt>std::forward&lt;Uj&gt;(get&lt;j&gt;(u))</tt> for each type <tt>Uj</tt></ins>
<del>move constructing its first <tt>sizeof...(TTypes)</tt> elements from the
corresponding elements of <tt>t</tt> and move constructing its last
<tt>sizeof...(UTypes)</tt> elements from the corresponding elements of
<tt>u</tt></del>.
</p>
</blockquote>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="1327"></a>1327. templates defined in <tt>&lt;cmath&gt;</tt> replacing C macros with the same name</h3>
<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Michael Wong <b>Opened:</b> 2010-03-07  <b>Last modified:</b> 2010-03-15</p>
<p><b>View all other</b> <a href="lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 26.8 [c.math]p12
The templates defined in <tt>&lt;cmath&gt;</tt> replace the C99 macros
with the same names. The templates have the following declarations:
</p>

<blockquote><pre>
namespace std {
template &lt;class T&gt; bool signbit(T x);
template &lt;class T&gt; int fpclassify(T x);
template &lt;class T&gt; bool isfinite(T x);
template &lt;class T&gt; bool isinf(T x);
template &lt;class T&gt; bool isnan(T x);
template &lt;class T&gt; bool isnormal(T x);
template &lt;class T&gt; bool isgreater(T x, T y);
template &lt;class T&gt; bool isgreaterequal(T x, T y);
template &lt;class T&gt; bool isless(T x, T y);
template &lt;class T&gt; bool islessequal(T x, T y);
template &lt;class T&gt; bool islessgreater(T x, T y);
template &lt;class T&gt; bool isunordered(T x, T y);
}
</pre></blockquote>

<p>
and p13:
</p>

<blockquote>
13 The templates behave the same as the C99 macros with corresponding
names defined in C99 7.12.3, Classification macros, and C99 7.12.14,
Comparison macros in the C standard.
</blockquote>

<p>
The C Std versions look like this:
</p>

<blockquote>
<p>
7.12.14.1/p1:
</p>
<blockquote>
<p>
Synopsis
</p>
<p>
1 <tt>#include &lt;math.h&gt;</tt>
</p>
<pre>
int isgreaterequal(real-floating x, real-floating y);
</pre>
</blockquote>
</blockquote>

<p>
which is not necessarily the same types as is required by C++ since the
two parameters may be different. Would it not be better if it were truly
aligned with C?
</p>

<p><i>[
2010 Pittsburgh:  Bill to ask WG-14 if heterogeneous support for the
two-parameter macros is intended.
]</i></p>




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





<hr>
<h3><a name="1328"></a>1328. istream extractors not setting failbit if eofbit is already set</h3>
<p><b>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2010-02-17  <b>Last modified:</b> 2010-03-09</p>
<p><b>View all other</b> <a href="lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
basing on the recent discussion on the library reflector, see c++std-lib-27728
and follow ups, I hereby formally ask for LWG 419 to be re-opened, the rationale
being that according to the current specifications, per
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">n3000</a>,
it seems actually impossible to seek away from end of file, contrary to the
rationale which led <a href="lwg-closed.html#342">342</a> to its closure as NAD. My request is also
supported by Martin Sebor, and I'd like also to add, as tentative proposed
resolution for the re-opened issue, the wording suggested by Sebor, thus, change
the beginning of 27.7.1.1.3 [istream::sentry]/2, to:
</p>

<blockquote>
2 <i>Effects:</i> If <tt><ins>(!noskipws &amp;&amp; !</ins>is.good())</tt> is
<tt><del>false</del> <ins>true</ins></tt>, calls <tt>is.setstate(failbit)</tt>.
Otherwise prepares for formatted or unformatted input. ...
</blockquote>




<p><b>Proposed resolution:</b></p>
<p>
Change 27.7.1.1.3 [istream::sentry]/2:
</p>

<blockquote>
2 <i>Effects:</i> If <tt><ins>(!noskipws &amp;&amp; !</ins>is.good())</tt> is
<tt><del>false</del> <ins>true</ins></tt>, calls <tt>is.setstate(failbit)</tt>.
Otherwise prepares for formatted or unformatted input. ...
</blockquote>






<hr>
<h3><a name="1330"></a>1330. Move container requirements into requirements tables</h3>
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2010-03-10  <b>Last modified:</b> 2010-03-10</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Abstract:
</p>
<p>
In general, it seems that in a couple of places container behavior is
not described in requirement tables although it is a general behavior.
</p>

<p>
History:
</p>

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

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

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

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

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

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

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


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





<hr>
<h3><a name="1331"></a>1331. incorporate move special member functions into library</h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2010-03-10  <b>Last modified:</b> 2010-03-11</p>
<p><b>View other</b> <a href="lwg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="lwg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Review the library portion of the spec and incorporate the newly added
core feature Move Special Member Functions (N3044).
</p>


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





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

<blockquote>
<table border="1">

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

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

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

</table>
</blockquote>

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

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

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

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

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

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

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


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

<blockquote>
<table border="1">

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

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

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

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

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

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






<hr>
<h3><a name="1333"></a>1333. Missing forwarding during std::function invocation</h3>
<p><b>Section:</b> 20.8.14.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2010-03-26  <b>Last modified:</b> 2010-03-27</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func.inv">issues</a> in [func.wrap.func.inv].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current wording of 20.8.14.2.4 [func.wrap.func.inv]/1:
</p>

<blockquote><pre>
R operator()(ArgTypes... args) const
</pre>

<blockquote>
<i>Effects:</i> <tt><i>INVOKE</i>(f, t1, t2, ..., tN, R)</tt> (20.8.2), where
<tt>f</tt> is the target object (20.8.1) of <tt>*this</tt> and <tt>t1, t2, ...,
tN</tt> are the values in <tt>args...</tt>.
</blockquote>
</blockquote>

<p>
uses an unclear relation between the actual args and the used variables
<tt>ti</tt>. It should be made clear, that <tt>std::forward</tt> has to be used
to conserve the expression lvalueness.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.8.14.2.4 [func.wrap.func.inv]/1+2 as indicated:
</p>

<blockquote><pre>
R operator()(ArgTypes... args) const
</pre>

<blockquote>
<p>
1 <i>Effects:</i>: <tt><i>INVOKE</i>(f,
<ins>std::forward&lt;ArgTypes&gt;(args)...</ins><del>t1, t2, ..., tN</del>,
R)</tt> (20.8.2), where <tt>f</tt> is the target object (20.8.1) of
<tt>*this</tt> <del>and <tt>t1, t2, ..., tN</tt> are the values in
<tt>args...</tt></del>.
</p>

<p>
2 <i>Returns:</i> Nothing if <tt>R</tt> is <tt>void</tt>, otherwise the return
value of <tt><i>INVOKE</i>(f,
<ins>std::forward&lt;ArgTypes&gt;(args)...</ins><del>t1, t2, ..., tN</del>,
R)</tt>.
</p>

<p>
3 <i>Throws:</i> <tt>bad_function_call</tt> if <tt>!*this</tt>; otherwise, any
exception thrown by the wrapped callable object.
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="1334"></a>1334. Insert iterators are broken for some proxy  containers compared to C++03</h3>
<p><b>Section:</b> 24.5.2.2.2 [back.insert.iter.op=], 24.5.2.4.2 [front.insert.iter.op=], X [insert.insert.iter.op=] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2010-03-28  <b>Last modified:</b> 2010-03-28</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In C++03 this was valid code:
</p>

<blockquote><pre>
#include &lt;vector&gt;
#include &lt;iterator&gt;

int main() {
  typedef std::vector&lt;bool&gt; Cont;
  Cont c;
  std::back_insert_iterator&lt;Cont&gt; it = std::back_inserter(c);
  *it = true;
}
</pre></blockquote>

<p>
In C++0x this code does no longer compile because of an ambiguity error for this
<tt>operator=</tt> overload pair:
</p>

<blockquote><pre>
back_insert_iterator&lt;Container&gt;&amp;
operator=(typename Container::const_reference value);

back_insert_iterator&lt;Container&gt;&amp;
operator=(typename Container::value_type&amp;&amp; value);
</pre></blockquote>

<p>
This is so, because for proxy-containers like <tt>std::vector&lt;bool&gt;</tt>
the <tt>const_reference</tt> usually is a non-reference type and in this case
it's identical to <tt>Container::value_type</tt>, thus forming the ambiguous
overload pair
</p>

<blockquote><pre>
back_insert_iterator&lt;Container&gt;&amp;
operator=(bool value);

back_insert_iterator&lt;Container&gt;&amp;
operator=(bool&amp;&amp; value);
</pre></blockquote>

<p>
The same problem exists for <tt>std::back_insert_iterator</tt>,
<tt>std::front_insert_iterator</tt>, and <tt>std::insert_iterator</tt>.
</p>

<p>
One possible fix would be to require that <tt>const_reference</tt> of a proxy
container must not be the same as the <tt>value_type</tt>, but this would break
earlier valid code. The alternative would be to change the first signature to
</p>

<blockquote><pre>
back_insert_iterator&lt;Container&gt;&amp;
operator=(const typename Container::const_reference&amp; value);
</pre></blockquote>

<p>
This would have the effect that this signature <em>always</em> expects an lvalue
or rvalue, but it would not create an ambiguity relative to the second form with
rvalue-references. [For all non-proxy containers the signature will be the same
as before due to reference-collapsing and const folding rules]
</p>


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

<li>
<p>
Change 24.5.2.1 [back.insert.iterator], class back_insert_iterator synopsis
as indicated:
</p>

<blockquote><pre>
template &lt;class Container&gt;
class back_insert_iterator :
  public iterator&lt;output_iterator_tag,void,void,void,void&gt; {
protected:
  Container* container;
public:
  [..]
  back_insert_iterator&lt;Container&gt;&amp;
    operator=(<ins>const</ins> typename Container::const_reference<ins>&amp;</ins> value);
  back_insert_iterator&lt;Container&gt;&amp;
    operator=(typename Container::value_type&amp;&amp; value);
  [..]
};
</pre></blockquote>
</li>

<li>
<p>
Change 24.5.2.2.2 [back.insert.iter.op=] before p. 1 as indicated:
</p>

<blockquote><pre>
back_insert_iterator&lt;Container&gt;&amp;
  operator=(<ins>const</ins> typename Container::const_reference<ins>&amp;</ins> value);
</pre></blockquote>
</li>

<li>
<p>
Change 24.5.2.3 [front.insert.iterator], class front_insert_iterator
synposis as indicated:
</p>

<blockquote><pre>
template &lt;class Container&gt;
class front_insert_iterator :
  public iterator&lt;output_iterator_tag,void,void,void,void&gt; {
protected:
  Container* container;
public:
  [..]
  front_insert_iterator&lt;Container&gt;&amp;
    operator=(<ins>const</ins> typename Container::const_reference<ins>&amp;</ins> value);
  front_insert_iterator&lt;Container&gt;&amp;
    operator=(typename Container::value_type&amp;&amp; value);
  [..]
};
</pre></blockquote>
</li>

<li>
<p>
Change 24.5.2.4.2 [front.insert.iter.op=] before p.1 as indicated:
</p>

<blockquote><pre>
front_insert_iterator&lt;Container&gt;&amp;
  operator=(<ins>const</ins> typename Container::const_reference<ins>&amp;</ins> value);
</pre></blockquote>
</li>

<li>
<p>
Change 24.5.2.5 [insert.iterator], class insert_iterator synopsis as
indicated:
</p>

<blockquote><pre>
template &lt;class Container&gt;
class insert_iterator :
  public iterator&lt;output_iterator_tag,void,void,void,void&gt; {
protected:
  Container* container;
  typename Container::iterator iter;
public:
  [..]
  insert_iterator&lt;Container&gt;&amp;
    operator=(<ins>const</ins> typename Container::const_reference<ins>&amp;</ins> value);
  insert_iterator&lt;Container&gt;&amp;
    operator=(typename Container::value_type&amp;&amp; value);
  [..]
};
</pre></blockquote>
</li>

<li>
<p>
Change 24.5.2.6.2 [insert.iter.op=] before p. 1 as indicated:
</p>

<blockquote><pre>
insert_iterator&lt;Container&gt;&amp;
  operator=(<ins>const</ins> typename Container::const_reference<ins>&amp;</ins> value);
</pre></blockquote>
</li>

</ol>






<hr>
<h3><a name="1335"></a>1335. Insufficient requirements for <tt>tuple::operator&lt;()</tt></h3>
<p><b>Section:</b> 20.4.2.7 [tuple.rel] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2010-05-15  <b>Last modified:</b> 2010-06-02</p>
<p><b>View all other</b> <a href="lwg-index.html#tuple.rel">issues</a> in [tuple.rel].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The requirements section for <tt>std::tuple</tt> says the following: 
</p>

<blockquote>
<i>Requires:</i> For all <tt>i</tt>, where <tt>0 &lt;= i and i &lt;
sizeof...(Types)</tt>, <tt>get&lt;i&gt;(t) &lt; get&lt;i&gt;(u)</tt> is a valid
expression returning a type that is convertible to <tt>bool</tt>.
<tt>sizeof...(TTypes) == sizeof...(UTypes)</tt>.
</blockquote>

<p>
This is necessary but not sufficient, as the algorithm for comparing
<tt>tuple</tt>s also computes <tt>get&lt;i&gt;(u) &lt; get&lt;i&gt;(t)</tt>
(note the order)
</p>



<p><b>Proposed resolution:</b></p>
<p>
Change 20.4.2.7 [tuple.rel] to say
</p>

<blockquote><pre>
template&lt;class... TTypes, class... UTypes&gt;
  bool operator&lt;(const tuple&lt;TTypes...&gt;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);
</pre>
<blockquote>
<i>Requires:</i> For all <tt>i</tt>, where <tt>0 &lt;= i and i &lt;
sizeof...(Types)</tt>, <tt>get&lt;i&gt;(t) &lt; get&lt;i&gt;(u)</tt> <ins>and
<tt>get&lt;i&gt;(u) &lt; get&lt;i&gt;(t)</tt> are</ins> <del>is a</del> valid
expressions returning types that are convertible to <tt>bool</tt>.
<tt>sizeof...(TTypes) == sizeof...(UTypes)</tt>.
</blockquote>
</blockquote>






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


<p><b>Proposed resolution:</b></p>
<p>
Change the first bullet item in 30.6.10.1 [futures.task.members] /22:
</p>

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





<hr>
<h3><a name="1337"></a>1337. Swapped arguments in <tt>regex_traits::isctype</tt></h3>
<p><b>Section:</b> 28.7 [re.traits] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2010-06-21  <b>Last modified:</b> 2010-06-25</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
28.7 [re.traits]/12 describes <tt>regex_traits::isctype</tt> in terms
of <tt>ctype::is(c, m)</tt>, where <tt>c</tt> is a <tt>charT</tt> and <tt>m</tt>
is a <tt>ctype_base::mask</tt>.  Unfortunately 22.4.1.1.1 [locale.ctype.members]
specifies this function as <tt>ctype::is(m, c)</tt>
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 28.7 [re.traits]/12:
</p>

<blockquote><pre>
bool isctype(charT c, char_class_type f) const;
</pre>
<blockquote>
<p>
11 ...
</p>
<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, and returns
<tt>true</tt> if <tt>use_facet&lt;ctype&lt;charT&gt;
&gt;(getloc()).is(<del>c</del><ins>m</ins>, <del>m</del><ins>c</ins>)</tt> is
<tt>true</tt>. Otherwise returns <tt>true</tt> 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 <tt>"w"</tt> is not equal to 0 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 <tt>"blank"</tt> is not equal to 0 and <tt>c</tt> is one of an
implementation-defined subset of the characters for which <tt>isspace(c,
getloc())</tt> returns <tt>true</tt>, otherwise returns <tt>false</tt>.
</p>
</blockquote>
</blockquote>





<hr>
<h3><a name="1338"></a>1338. LWG 1205 incorrectly applied</h3>
<p><b>Section:</b> 25.2.13 [alg.search] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2010-06-25  <b>Last modified:</b> 2010-06-25</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.search">issues</a> in [alg.search].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="lwg-defects.html#1205">1205</a> (currently in WP) clarified the return value of several
algorithms when dealing with empty ranges.  In particular it recommended for
25.2.13 [alg.search]:
</p>

<blockquote><pre>
template&lt;class ForwardIterator1, class ForwardIterator2&gt;
  ForwardIterator1
    search(ForwardIterator1 first1, ForwardIterator1 last1,
           ForwardIterator2 first2, ForwardIterator2 last2);

template&lt;class ForwardIterator1, class ForwardIterator2,
         class BinaryPredicate&gt;
  ForwardIterator1
    search(ForwardIterator1 first1, ForwardIterator1 last1,
           ForwardIterator2 first2, ForwardIterator2 last2,
           BinaryPredicate pred);
</pre>
<blockquote>
<p>
1 <i>Effects:</i> ...
</p>
<p>
2 <i>Returns:</i> ... Returns <tt>last1</tt> if no such iterator is found.
</p>
<p><ins>
3 <i>Remarks:</i> Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is empty.
</ins></p>
</blockquote>
</blockquote>

<p>
Unfortunately this got translated to an incorrect specification for what gets
returned when no such iterator is found (N3092):
</p>

<blockquote><pre>
template&lt;class ForwardIterator1, class ForwardIterator2&gt;
  ForwardIterator1
    search(ForwardIterator1 first1, ForwardIterator1 last1,
           ForwardIterator2 first2, ForwardIterator2 last2);

template&lt;class ForwardIterator1, class ForwardIterator2,
         class BinaryPredicate&gt;
  ForwardIterator1
    search(ForwardIterator1 first1, ForwardIterator1 last1,
           ForwardIterator2 first2, ForwardIterator2 last2,
           BinaryPredicate pred);
</pre>
<blockquote>
<p>
1 <i>Effects:</i> ...
</p>
<p>
2 <i>Returns:</i> ... Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is
empty or if no such iterator is found.
</p>
</blockquote>
</blockquote>

<p>
LWG <a href="lwg-defects.html#1205">1205</a> is correct and N3092 is not equivalent nor correct.
</p>

<p>
I have not reviewed the other 10 recommendations of <a href="lwg-defects.html#1205">1205</a>.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Reapply LWG <a href="lwg-defects.html#1205">1205</a>.
</p>





<hr>
<h3><a name="1339"></a>1339. <tt>uninitialized_fill_n</tt> should return the end of its range</h3>
<p><b>Section:</b> 20.9.9.4 [uninitialized.fill.n] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jared Hoberock <b>Opened:</b> 2010-07-14  <b>Last modified:</b> 2010-07-14</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf">N3092's</a>
specification of <tt>uninitialized_fill_n</tt> discards useful information and
is inconsistent with other algorithms such as <tt>fill_n</tt> which accept an
iterator and a size.  As currently specified, <tt>unintialized_fill_n</tt>
requires an additional linear traversal to find the end of the range.
</p>

<p>
Instead of returning <tt>void</tt>, <tt>unintialized_fill_n</tt> should return
one past the last iterator it dereferenced.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In section 20.9 [memory] change:,
</p>

<blockquote><pre>
template &lt;class ForwardIterator, class Size, class T&gt;
  <del>void</del> <ins>ForwardIterator</ins> uninitialized_fill_n(ForwardIterator first, Size n, const T&amp; x);
</pre></blockquote>


<p>
In section 20.9.9.4 [uninitialized.fill.n] change,
</p>

<blockquote><pre>
template &lt;class ForwardIterator, class Size, class T&gt;
  <del>void</del> <ins>ForwardIterator</ins> uninitialized_fill_n(ForwardIterator first, Size n, const T&amp; x);
</pre>
<blockquote>
<p>
1 <i>Effects:</i>
</p>
<blockquote><pre>
for (; n--; ++first)
  ::new (static_cast&lt;void*&gt;(&amp;*first))
    typename iterator_traits&lt;ForwardIterator&gt;::value_type(x);
<ins>return first;</ins>
</pre></blockquote>
</blockquote>
</blockquote>






<hr>
<h3><a name="1340"></a>1340. Why does <tt>forward_list::resize</tt> take the object to be copied by value?</h3>
<p><b>Section:</b> 23.3.3.4 [forwardlist.modifiers] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> 		
James McNellis <b>Opened:</b> 2010-07-16  <b>Last modified:</b> 2010-07-16</p>
<p><b>View all other</b> <a href="lwg-index.html#forwardlist.modifiers">issues</a> in [forwardlist.modifiers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf">N3092</a>
23.3.3.4 [forwardlist.modifiers], the <tt>resize()</tt> member function is 
declared as:
</p>

<blockquote><pre>
void resize(size_type sz, value_type c); 
</pre></blockquote>

<p>
The other sequence containers (<tt>list</tt>, <tt>deque</tt>, and
<tt>vector</tt>) take <tt>'c'</tt> by const reference.
</p>

<p>
Is there a reason for this difference?  If not, then <tt>resize()</tt> should 
be declared as: 
</p>

<blockquote><pre>
void resize(size_type sz, const value_type&amp; c); 
</pre></blockquote>

<p>
The declaration would need to be changed both at its declaration in the class
definition at 23.3.3 [forwardlist]/3 and where its behavior is specified
at 23.3.3.4 [forwardlist.modifiers]/22.
</p>

<p>
This would make <tt>forward_list</tt> consistent with the CD1 issue <a href="lwg-defects.html#679">679</a>.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Change 23.3.3 [forwardlist]/3:
</p>

<blockquote><pre>
  ...
  void resize(size_type sz, <ins>const</ins> value_type<ins>&amp;</ins> c);
  ...
</pre></blockquote>

<p>
Change 23.3.3.4 [forwardlist.modifiers]/22:
</p>

<blockquote><pre>
void resize(size_type sz);
void resize(size_type sz, <ins>const</ins> value_type<ins>&amp;</ins> c);
</pre></blockquote>






<hr>
<h3><a name="1341"></a>1341. 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#New">New</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2010-07-19  <b>Last modified:</b> 2010-07-20</p>
<p><b>View all other</b> <a href="lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
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_bounds</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="1342"></a>1342. <tt>is_* traits</tt> for binding operations can't be meaningfully specialized</h3>
<p><b>Section:</b> 20.8.10.1.1 [func.bind.isbind] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Sean Hunt <b>Opened:</b> 2010-07-19  <b>Last modified:</b> 2010-07-20</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#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.8.10.1.1 [func.bind.isbind] says for <tt>is_bind_expression</tt>:
</p>

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

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

<blockquote>
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>.
</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><b>Proposed resolution:</b></p>





<hr>
<h3><a name="1343"></a>1343. unexpected output required of strings</h3>
<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> James Kanze <b>Opened:</b> 2010-07-23  <b>Last modified:</b> 2010-07-23</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#New">New</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]/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>
<i>Effects:</i> Behaves as a formatted output function (27.7.2.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>.
</blockquote>
</blockquote>

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

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

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

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

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

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

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

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

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

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

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

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

</blockquote>

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



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





</body>
</html>
