Add NIOS2 support. Code from SourceyG++.

[pf3gnuchains/gcc-fork.git] / libstdc++-v3 / doc / html / ext / lwg-active.html

diff --git a/libstdc++-v3/doc/html/ext/lwg-active.html b/libstdc++-v3/doc/html/ext/lwg-active.html
index 74e43ef..15281f3 100644 (file)
--- a/libstdc++-v3/doc/html/ext/lwg-active.html
+++ b/libstdc++-v3/doc/html/ext/lwg-active.html
@@ -7,6 +7,14 @@
 <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>
@@ -14,11 +22,11 @@ del {background-color:#FFA0A0}
 <table>
 <tbody><tr>
 <td align="left">Doc. no.</td>
-<td align="left">N2940=09-0130</td>
+<td align="left">N3011=09-0201</td>
 </tr>
 <tr>
 <td align="left">Date:</td>
-<td align="left">2009-08-02</td>
+<td align="left">2009-11-08</td>
 </tr>
 <tr>
 <td align="left">Project:</td>
@@ -29,7 +37,7 @@ del {background-color:#FFA0A0}
 <td align="left">Howard Hinnant &lt;<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>&gt;</td>
 </tr>
 </tbody></table>
-<h1>C++ Standard Library Active Issues List (Revision R66)</h1>
+<h1>C++ Standard Library Active Issues List (Revision R68)</h1>
 
   <p>Reference ISO/IEC IS 14882:2003(E)</p>
   <p>Also see:</p>
@@ -82,9 +90,139 @@ del {background-color:#FFA0A0}
   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>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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1230">1230</a>.</li>
+<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1229">1229</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1236">1236</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1243">1243</a>.</li>
+<li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1232">1232</a>.</li>
+<li>Added the following NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1235">1235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1242">1242</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1248">1248</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1218">1218</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1219">1219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1221">1221</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1222">1222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1223">1223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1224">1224</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1225">1225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1234">1234</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1240">1240</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1244">1244</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1245">1245</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1246">1246</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1249">1249</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1250">1250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1251">1251</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1252">1252</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1253">1253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1254">1254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1255">1255</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1256">1256</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1257">1257</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1258">1258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1259">1259</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1260">1260</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1228">1228</a>.</li>
+<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1227">1227</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1237">1237</a>.</li>
+<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1247">1247</a>.</li>
+<li>Added the following Tentatively NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1233">1233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1239">1239</a>.</li>
+<li>Added the following Tentatively NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1238">1238</a>.</li>
+<li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1220">1220</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1226">1226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1231">1231</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1241">1241</a>.</li>
+<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1148">1148</a>.</li>
+<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1064">1064</a>.</li>
+<li>Changed the following issues from Review to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1102">1102</a>.</li>
+<li>Changed the following issues from Tentatively NAD to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>.</li>
+<li>Changed the following issues from Tentatively NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>.</li>
+<li>Changed the following issues from NAD Concepts to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1143">1143</a>.</li>
+<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1145">1145</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1146">1146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1147">1147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1155">1155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1166">1166</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1172">1172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1174">1174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1179">1179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1195">1195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1196">1196</a>.</li>
+<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#431">431</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1160">1160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1161">1161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1162">1162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1163">1163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1165">1165</a>.</li>
+<li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1050">1050</a>.</li>
+<li>Changed the following issues from New to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1150">1150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1184">1184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1203">1203</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1217">1217</a>.</li>
+<li>Changed the following issues from Open to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#851">851</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1053">1053</a>.</li>
+<li>Changed the following issues from Tentatively NAD Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1031">1031</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1119">1119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1151">1151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1153">1153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1156">1156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1171">1171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1173">1173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1183">1183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1191">1191</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1211">1211</a>.</li>
+<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#430">430</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
+<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>.</li>
+<li>Changed the following issues from Tentatively NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>.</li>
+<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1144">1144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1194">1194</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1204">1204</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1216">1216</a>.</li>
+<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#296">296</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#485">485</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>.</li>
+<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#473">473</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1052">1052</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1157">1157</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1130">1130</a>.</li>
+<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>.</li>
+<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>.</li>
+<li>Changed the following issues from New to Tentatively NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1186">1186</a>.</li>
+<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1115">1115</a>.</li>
+<li>Changed the following issues from New to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1201">1201</a>.</li>
+<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1112">1112</a>.</li>
+<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1152">1152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1158">1158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1189">1189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1192">1192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1208">1208</a>.</li>
+<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1113">1113</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</a>.</li>
+<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#419">419</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>.</li>
+<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1187">1187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1188">1188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1189">1189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1190">1190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1191">1191</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1192">1192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1193">1193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1194">1194</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1195">1195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1196">1196</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1197">1197</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1198">1198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1199">1199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1200">1200</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1201">1201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1202">1202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1203">1203</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1204">1204</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1205">1205</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1206">1206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1207">1207</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1208">1208</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1209">1209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1210">1210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1211">1211</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1212">1212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1213">1213</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1214">1214</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1215">1215</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1216">1216</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1217">1217</a>.</li>
+<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#296">296</a>.</li>
+<li>Changed the following issues from WP to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>.</li>
+<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1052">1052</a>.</li>
+<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>.</li>
+</ul></li>
+</ul>
+</li>
 <li>R66: 
 2009-07-31 post-Frankfurt mailing.
 <ul>
@@ -97,9 +235,9 @@ del {background-color:#FFA0A0}
 <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1164">1164</a>.</li>
 <li>Added the following NAD Concepts issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1149">1149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1167">1167</a>.</li>
 <li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1168">1168</a>.</li>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1144">1144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1145">1145</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1146">1146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1147">1147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1148">1148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1150">1150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1151">1151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1152">1152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1153">1153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1154">1154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1155">1155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1156">1156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1158">1158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1159">1159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1166">1166</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1169">1169</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1170">1170</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1171">1171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1172">1172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1173">1173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1174">1174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1175">1175</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1176">1176</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1179">1179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1180">1180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1181">1181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1182">1182</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1183">1183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1184">1184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1185">1185</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1186">1186</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1160">1160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1161">1161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1162">1162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1163">1163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1165">1165</a>.</li>
-<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1178">1178</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1144">1144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1145">1145</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1146">1146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1147">1147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1148">1148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1150">1150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1151">1151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1152">1152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1153">1153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1154">1154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1155">1155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1156">1156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1158">1158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1159">1159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1166">1166</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1169">1169</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1170">1170</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1171">1171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1172">1172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1173">1173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1174">1174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1175">1175</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1176">1176</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1179">1179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1180">1180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1181">1181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1182">1182</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1183">1183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1184">1184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1185">1185</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1186">1186</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1160">1160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1161">1161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1162">1162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1163">1163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1165">1165</a>.</li>
+<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>.</li>
 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1157">1157</a>.</li>
 <li>Changed the following issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#895">895</a>.</li>
 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#290">290</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#309">309</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#343">343</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#382">382</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#394">394</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#398">398</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#417">417</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#418">418</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#421">421</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#459">459</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#492">492</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#606">606</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#614">614</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>.</li>
@@ -116,23 +254,23 @@ del {background-color:#FFA0A0}
 <li>Changed the following issues from Tentatively NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1101">1101</a>.</li>
 <li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1107">1107</a>.</li>
 <li>Changed the following issues from Open to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#255">255</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#423">423</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#708">708</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#839">839</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>.</li>
-<li>Changed the following issues from CD1 to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>.</li>
-<li>Changed the following issues from NAD Editorial to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>.</li>
-<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>.</li>
-<li>Changed the following issues from Tentatively NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#458">458</a>.</li>
-<li>Changed the following issues from Tentatively NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>.</li>
-<li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#419">419</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#430">430</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>.</li>
+<li>Changed the following issues from CD1 to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#823">823</a>.</li>
+<li>Changed the following issues from NAD Editorial to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>.</li>
+<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>.</li>
+<li>Changed the following issues from Tentatively NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#458">458</a>.</li>
+<li>Changed the following issues from Tentatively NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>.</li>
+<li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>.</li>
+<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#419">419</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#430">430</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>.</li>
 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>.</li>
-<li>Changed the following issues from Tentatively NAD to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>.</li>
-<li>Changed the following issues from Tentatively Ready to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>.</li>
+<li>Changed the following issues from Tentatively NAD to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#822">822</a>.</li>
+<li>Changed the following issues from Tentatively Ready to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>.</li>
 <li>Changed the following issues from NAD to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>.</li>
-<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#473">473</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>.</li>
-<li>Changed the following issues from Tentatively NAD to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>.</li>
+<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#473">473</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>.</li>
+<li>Changed the following issues from Tentatively NAD to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>.</li>
 <li>Changed the following issues from Tentatively Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>.</li>
-<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>.</li>
-<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>.</li>
-<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>.</li>
+<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>.</li>
+<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>.</li>
+<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>.</li>
 <li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1103">1103</a>.</li>
 </ul></li>
 </ul>
@@ -146,24 +284,24 @@ del {background-color:#FFA0A0}
 <li>1143 issues total, up by 32.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1115">1115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1119">1119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1124">1124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1125">1125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1130">1130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1131">1131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1133">1133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1137">1137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1143">1143</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1115">1115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1119">1119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1124">1124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1125">1125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1130">1130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1131">1131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1133">1133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1137">1137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1143">1143</a>.</li>
 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1112">1112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1113">1113</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</a>.</li>
 <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>.</li>
-<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1111">1111</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>.</li>
+<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1111">1111</a>.</li>
 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1087">1087</a>.</li>
 <li>Changed the following issues from New to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#918">918</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1074">1074</a>.</li>
-<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>.</li>
+<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>.</li>
 <li>Changed the following issues from Review to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>.</li>
-<li>Changed the following issues from Tentatively Ready to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#988">988</a>.</li>
+<li>Changed the following issues from Tentatively Ready to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#988">988</a>.</li>
 <li>Changed the following issues from New to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1109">1109</a>.</li>
 <li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#884">884</a>.</li>
 <li>Changed the following issues from Review to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>.</li>
-<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>.</li>
-<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1107">1107</a>.</li>
+<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>.</li>
+<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1107">1107</a>.</li>
 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>.</li>
-<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>.</li>
+<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>.</li>
 </ul></li>
 </ul>
 </li>
@@ -176,7 +314,7 @@ del {background-color:#FFA0A0}
 <li>1111 issues total, up by 19.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1107">1107</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1109">1109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1111">1111</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1107">1107</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1109">1109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1111">1111</a>.</li>
 <li>Changed the following issues from DR to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#406">406</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#434">434</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438">438</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#444">444</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#455">455</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#469">469</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>.</li>
 <li>Changed the following issues from Review to New: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>.</li>
 </ul></li>
@@ -193,9 +331,9 @@ del {background-color:#FFA0A0}
 <li><b>Details:</b><ul>
 <li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1022">1022</a>.</li>
 <li>Added the following NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.</li>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1074">1074</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1092">1092</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1007">1007</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1008">1008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1029">1029</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1032">1032</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1034">1034</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1052">1052</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1053">1053</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1064">1064</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1078">1078</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1089">1089</a>.</li>
-<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1003">1003</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1050">1050</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1074">1074</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1092">1092</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1007">1007</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1008">1008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1029">1029</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1032">1032</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1034">1034</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1052">1052</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1053">1053</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1064">1064</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1078">1078</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1089">1089</a>.</li>
+<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1003">1003</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1050">1050</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>.</li>
 <li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#988">988</a>.</li>
 <li>Changed the following issues from New to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>.</li>
 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>.</li>
@@ -204,15 +342,15 @@ del {background-color:#FFA0A0}
 <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#683">683</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li>
 <li>Changed the following issues from Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
 <li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>.</li>
-<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>.</li>
-<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>.</li>
+<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>.</li>
+<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>.</li>
 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>.</li>
 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>.</li>
 <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#949">949</a>.</li>
 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a>.</li>
-<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>.</li>
+<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>.</li>
 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
 </ul></li>
 </ul>
@@ -226,7 +364,7 @@ del {background-color:#FFA0A0}
 <li>982 issues total, up by 44.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>.</li>
 </ul></li>
 </ul>
 </li>
@@ -239,7 +377,7 @@ del {background-color:#FFA0A0}
 <li>938 issues total, up by 20.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>.</li>
 </ul></li>
 </ul>
 </li>
@@ -253,28 +391,28 @@ del {background-color:#FFA0A0}
 </ul></li>
 <li><b>Details:</b><ul>
 <li>Added the following CD1 issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#882">882</a>.</li>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#918">918</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#887">887</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#895">895</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#896">896</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#918">918</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#887">887</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#895">895</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#896">896</a>.</li>
 <li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li>
 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>.</li>
 <li>Changed the following issues from New to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>.</li>
 <li>Changed the following issues from Ready to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li>
-<li>Changed the following issues from Review to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>.</li>
+<li>Changed the following issues from Review to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#823">823</a>.</li>
 <li>Changed the following issues from WP to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#44">44</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#167">167</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#231">231</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#239">239</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#240">240</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274">274</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#282">282</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#291">291</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#300">300</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#305">305</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#310">310</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#315">315</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#316">316</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#318">318</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#319">319</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#320">320</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#321">321</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#324">324</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#325">325</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#328">328</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#331">331</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#333">333</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#337">337</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#338">338</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#340">340</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#341">341</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#345">345</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#346">346</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#349">349</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#352">352</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#354">354</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#355">355</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#358">358</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#359">359</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#360">360</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#363">363</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#364">364</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#365">365</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#370">370</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#373">373</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#375">375</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#379">379</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#380">380</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#381">381</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#391">391</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#395">395</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#400">400</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#403">403</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#405">405</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#410">410</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#411">411</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#414">414</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#415">415</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#420">420</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#425">425</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#426">426</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#428">428</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#435">435</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#436">436</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#442">442</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#443">443</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#448">448</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#449">449</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
 <li>Changed the following issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>.</li>
 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>.</li>
 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>.</li>
-<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>.</li>
-<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>.</li>
+<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>.</li>
+<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>.</li>
 <li>Changed the following issues from Pending NAD Editorial to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>.</li>
-<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>.</li>
+<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#851">851</a>.</li>
+<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>.</li>
 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>.</li>
 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>.</li>
 <li>Changed the following issues from TC to TC1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1">1</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5">5</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#7">7</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#11">11</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#13">13</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#14">14</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#15">15</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#16">16</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#18">18</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#20">20</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#21">21</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#27">27</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#30">30</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#32">32</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#34">34</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#35">35</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#36">36</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#37">37</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#39">39</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#40">40</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#42">42</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#46">46</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#47">47</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#48">48</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#50">50</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#51">51</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#52">52</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#53">53</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#54">54</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#56">56</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#57">57</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#59">59</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#62">62</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#66">66</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#68">68</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#71">71</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#74">74</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#78">78</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#79">79</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#80">80</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#90">90</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#106">106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#124">124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#125">125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#141">141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#148">148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#150">150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#151">151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#152">152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#154">154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#155">155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#156">156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#158">158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#161">161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#168">168</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#169">169</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#174">174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#175">175</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#176">176</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.</li>
 </ul></li>
 </ul>
@@ -288,7 +426,7 @@ del {background-color:#FFA0A0}
 <li>878 issues total, up by 9.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>.</li>
 </ul></li>
 </ul>
 </li>
@@ -319,21 +457,21 @@ del {background-color:#FFA0A0}
 </ul></li>
 <li><b>Details:</b><ul>
 <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li>
 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#839">839</a>.</li>
 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li>
-<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
+<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#851">851</a>.</li>
 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>.</li>
 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>.</li>
 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>.</li>
 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
 <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
-<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.</li>
+<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>.</li>
 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>.</li>
 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>.</li>
 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
 <li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>.</li>
 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
@@ -349,7 +487,7 @@ del {background-color:#FFA0A0}
 <li>838 issues total, up by 25.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#838">838</a>.</li>
 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>.</li>
 </ul></li>
 </ul>
@@ -365,7 +503,7 @@ del {background-color:#FFA0A0}
 <li><b>Details:</b><ul>
 <li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
 <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>.</li>
 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
 <li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li>
@@ -376,14 +514,14 @@ del {background-color:#FFA0A0}
 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
 <li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>.</li>
 <li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li>
 <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>.</li>
 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
 <li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>.</li>
 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li>
 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li>
 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>.</li>
 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li>
 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
 <li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
@@ -418,7 +556,7 @@ del {background-color:#FFA0A0}
 </ul></li>
 <li><b>Details:</b><ul>
 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li>
-<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li>
+<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>.</li>
 <li>Changed the following issues from Pending WP to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li>
 </ul></li>
 </ul>
@@ -436,7 +574,7 @@ del {background-color:#FFA0A0}
 <li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>.</li>
 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>.</li>
 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#708">708</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#708">708</a>.</li>
 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
 <li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li>
 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
@@ -457,7 +595,7 @@ del {background-color:#FFA0A0}
 <li>723 issues total, up by 15.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a>.</li>
 </ul></li>
 </ul>
 </li>
@@ -497,7 +635,7 @@ del {background-color:#FFA0A0}
 <li>696 issues total, up by 20.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>.</li>
 <li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#683">683</a>.</li>
 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>.</li>
 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>.</li>
@@ -514,15 +652,15 @@ del {background-color:#FFA0A0}
 <li>676 issues total, up by 20.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
 <li>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li>
-<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
+<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
 <li>Changed the following issues from NAD to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#357">357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#368">368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>.</li>
 <li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>.</li>
-<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
+<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
 <li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
-<li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</a>.</li>
+<li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</a>.</li>
 <li>Changed the following issues from Tentatively Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
@@ -541,11 +679,11 @@ del {background-color:#FFA0A0}
 <li>656 issues total, up by 37.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#614">614</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#614">614</a>.</li>
 <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
-<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
+<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
 <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>.</li>
 </ul></li>
 </ul>
@@ -559,7 +697,7 @@ del {background-color:#FFA0A0}
 <li>619 issues total, up by 10.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#614">614</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#614">614</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
 </ul></li>
 </ul>
 </li>
@@ -591,7 +729,7 @@ del {background-color:#FFA0A0}
 <li>592 issues total, up by 5.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
 </ul></li>
 </ul>
 </li>
@@ -604,7 +742,7 @@ del {background-color:#FFA0A0}
 <li>587 issues total, up by 13.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a>.</li>
 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#255">255</a>.</li>
 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Tentatively Ready.</li>
 </ul></li>
@@ -621,7 +759,7 @@ del {background-color:#FFA0A0}
 <li><b>Details:</b><ul>
 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
+<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li>
 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li>
 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
@@ -637,7 +775,7 @@ del {background-color:#FFA0A0}
 <li>566 issues total, up by 31.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a> ,<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a> ,<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li>
 <li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a> from Ready to Open.</li>
 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#309">309</a>.</li>
 </ul></li>
@@ -652,7 +790,7 @@ del {background-color:#FFA0A0}
 <li>535 issues total.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
 </ul></li>
 </ul>
 </li>
@@ -661,7 +799,7 @@ del {background-color:#FFA0A0}
 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.
 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a> from Review to Ready.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open.
 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready.
 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
@@ -673,7 +811,7 @@ Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed
 </li>
 <li>R37: 
 2005-06 mid-term mailing.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#503">503</a>.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#503">503</a>.
 </li>
 <li>R36: 
 2005-04 post-Lillehammer mailing. All issues in "ready" status except
@@ -697,7 +835,7 @@ new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#
 <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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
+new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
 </li>
 <li>R30: 
 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
@@ -712,7 +850,7 @@ Post-Kona mailing: reflects decisions made at the Kona meeting.
 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#440">440</a>.
 </li>
 <li>R27: 
-Pre-Kona mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
+Pre-Kona mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#431">431</a>.
 </li>
 <li>R26: 
 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
@@ -1007,690 +1145,294 @@ format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64
 
 <h2>Active Issues</h2>
 <hr>
-<h3><a name="96"></a>96. Vector&lt;bool&gt; is not a container</h3>
-<p><b>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2009-07-29</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector">active issues</a> in [vector].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="296"></a>296. Missing descriptions and requirements of pair operators</h3>
+<p><b>Section:</b> 20.3.4 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-14  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
-<p><tt>vector&lt;bool&gt;</tt> is not a container as its reference and
-pointer types are not references and pointers. </p>
-
-<p>Also it forces everyone to have a space optimization instead of a
-speed one.</p>
-
-<p><b>See also:</b> 99-0008 == N1185 Vector&lt;bool&gt; is
-Nonconforming, Forces Optimization Choice.</p>
-
-<p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>
-
-
-<p><i>[In Dublin many present felt that failure to meet Container
-requirements was a defect. There was disagreement as to whether
-or not the optimization requirements constituted a defect.]</i></p>
-
-
-<p><i>[The LWG looked at the following resolutions in some detail:
-<br>
-&nbsp;&nbsp;&nbsp;&nbsp; * Not A Defect.<br>
-&nbsp;&nbsp;&nbsp;&nbsp; * Add a note explaining that vector&lt;bool&gt; does not meet
-Container requirements.<br>
-&nbsp;&nbsp;&nbsp;&nbsp; * Remove vector&lt;bool&gt;.<br>
-&nbsp;&nbsp;&nbsp;&nbsp; * Add a new category of container requirements which
-vector&lt;bool&gt; would meet.<br>
-&nbsp;&nbsp;&nbsp;&nbsp; * Rename vector&lt;bool&gt;.<br>
-<br>
-No alternative had strong, wide-spread, support and every alternative
-had at least one "over my dead body" response.<br>
-<br>
-There was also mention of a transition scheme something like (1) add
-vector_bool and deprecate vector&lt;bool&gt; in the next standard. (2)
-Remove vector&lt;bool&gt; in the following standard.]</i></p>
-
-
-<p><i>[Modifying container requirements to permit returning proxies
-(thus allowing container requirements conforming vector&lt;bool&gt;)
-was also discussed.]</i></p>
-
-
-<p><i>[It was also noted that there is a partial but ugly workaround in
-that vector&lt;bool&gt; may be further specialized with a customer
-allocator.]</i></p>
-
-
-<p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
-vector&lt;bool&gt;: More Problems, Better Solutions. Much discussion
-of a two step approach: a) deprecate, b) provide replacement under a
-new name.  LWG straw vote on that: 1-favor, 11-could live with, 2-over
-my dead body.  This resolution was mentioned in the LWG report to the
-full committee, where several additional committee members indicated
-over-my-dead-body positions.]</i></p>
-
-
-<p>Discussed at Lillehammer.  General agreement that we should
-  deprecate vector&lt;bool&gt; and introduce this functionality under
-  a different name, e.g. bit_vector.  This might make it possible to
-  remove the vector&lt;bool&gt; specialization in the standard that comes
-  after C++0x. There was also a suggestion that
-  in C++0x we could additional say that it's implementation defined
-  whether vector&lt;bool&gt; refers to the specialization or to the
-  primary template, but there wasn't general agreement that this was a
-  good idea.</p>
-
-<p>We need a paper for the new bit_vector class.</p>
-
-<p><i>[
-Batavia:
-]</i></p>
-
-<blockquote>
-The LWG feels we need something closer to SGI's <tt>bitvector</tt> to ease migration
-from <tt>vector&lt;bool&gt;</tt>.  Although some of the funcitonality from
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
-could well be used in such a template.  The concern is easing the API migration for those
-users who want to continue using a bit-packed container.  Alan and Beman to work.
-</blockquote>
+<p>The synopsis of the header <tt>&lt;utility&gt;</tt> in 20.3 [utility]
+lists the complete set of equality and relational operators for <tt>pair</tt>
+but the section describing the template and the operators only describes
+<tt>operator==()</tt> and <tt>operator&lt;()</tt>, and it fails to mention
+any requirements on the template arguments. The remaining operators are
+not mentioned at all.
+</p>
 
 <p><i>[
-Post Summit Alisdair adds:
+2009-09-27 Alisdair reopens.
 ]</i></p>
 
 
 <blockquote>
 <p>
-<tt>vector&lt;bool&gt;</tt> is now a conforming container under the revised terms of C++0x,
-which supports containers of proxies.
+The issue is a lack of wording specifying the semantics of <tt>std::pair</tt>
+relational operators.  The rationale is that this is covered by
+catch-all wording in the relops component, and that as relops directly
+precedes <tt>pair</tt> in the document this is an easy connection to make.
 </p>
+
 <p>
-Recommend NAD.
+Reading the current working paper I make two observations:
 </p>
+
+<ol type="i">
+<li>
+relops no longer immediately precedes <tt>pair</tt> in the order of
+specification.  However, even if it did, there is a lot of <tt>pair</tt>
+specification itself between the (apparently) unrelated relops and the
+relational operators for <tt>pair</tt>.  (The catch-all still requires
+<tt>operator==</tt> and <tt>operator&lt;</tt> to be specified
+explicitly)
+</li>
+
+<li>
+No other library component relies on the catch-all clause. The following
+all explicitly document all six relational operators, usually in a
+manner that could have deferred to the relops clause.
+</li>
+</ol>
+
+<blockquote><pre>tuple
+unique_ptr
+duration
+time_point
+basic_string
+queue
+stack
+move_iterator
+reverse_iterator 
+regex submatch
+thread::id
+</pre></blockquote>
+
 <p>
-Two issues remain:
+The container components provide their own (equivalent) definition in
+23.2.1 [container.requirements.general] Table 90 -- Container
+requirements and do so do not defer to relops.
 </p>
+
 <p>
-i/ premature optimization in the specification.
-There is still some sentiment that deprecation is the correct way to go,
-although it is still not clear what it would mean to deprecate a single
-specialization of a template.
+<tt>Shared_ptr</tt> explicitly documents <tt>operator!=</tt> and does
+not supply the other 3 missing operators
+(<tt>&gt;</tt>,<tt>&gt;=</tt>,<tt>&lt;=</tt>) so does not meet the
+reqirements of the relops clause.
 </p>
+
 <p>
-Recommend: Create a new issue for the discussion, leave as Open.
+<tt>Weak_ptr</tt> only supports <tt>operator&lt;</tt> so would not be
+covered by relops.
 </p>
+
 <p>
-ii/ Request for a new bitvector class to guarantee the optimization, perhaps
-with a better tuned interface.
+At the very least I would request a note pointing to the relops clause
+we rely on to provide this definition.  If this route is taken, I would
+recommend reducing many of the above listed clauses to a similar note
+rather than providing redundant specification.
 </p>
+
 <p>
-This is a clear extension request that may be handled via a future TR.
+My preference would be to supply the 4 missing specifications consistent
+with the rest of the library.
 </p>
+
 </blockquote>
 
 <p><i>[
-Batavia (2009-05):
+2009-10-11 Daniel opens <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1233">1233</a> which deals with the same issue as
+it pertains to <tt>unique_ptr</tt>.
 ]</i></p>
 
-<blockquote>
-We note that most of this issue has become moot over time,
-and agree with Alisdair's recommendations.
-Move to NAD Future for reconsideration of part (ii).
-</blockquote>
 
 <p><i>[
-2009-07-29 Alisdair reopens:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-<p>
-This infamous issue was closed as NAD Future when concepts introduced
-support for proxy iterators, so the only remaining requirement was to
-provide a better type to support bitsets of dynamic length.  I fear we
-must re-open this issue until the post-concept form of iterators is
-available, and hopefully will support the necessary proxy functionality
-to allow us to close this issue as NAD.
-</p>
-
-<p>
-I recommend we spawn a separate issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1184">1184</a>) requesting a dynamic length bitset
-and pre-emptively file it as NAD Future.  It is difficult to resolve #96
-when it effectively contains two separate sub-issues.
-</p>
+Move to Ready
 </blockquote>
 
 
+
 <p><b>Proposed resolution:</b></p>
 <p>
-We now have:
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
-and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html">N2160</a>.
+After p20 20.3.4 [pairs] add:
 </p>
 
-
-
-
-
-
-<hr>
-<h3><a name="149"></a>149. Insert should return iterator to first element inserted</h3>
-<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-06-28  <b>Last modified:</b> 2009-07-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Suppose that c and c1 are sequential containers and i is an
-iterator that refers to an element of c.  Then I can insert a copy of
-c1's elements into c ahead of element i by executing </p>
+<blockquote><pre>template &lt;class T1, class T2&gt;
+bool operator!=(const pair&lt;T1,T2&gt;&amp; x, const pair&lt;T1,T2&gt;&amp; y);
+</pre>
 
 <blockquote>
-
-<pre>c.insert(i, c1.begin(), c1.end());</pre>
-
+<i>Returns:</i> <tt>!(x==y)</tt>
 </blockquote>
 
-<p>If c is a vector, it is fairly easy for me to find out where the
-newly inserted elements are, even though i is now invalid: </p>
+<pre>template &lt;class T1, class T2&gt;
+bool operator&gt; (const pair&lt;T1,T2&gt;&amp; x, const pair&lt;T1,T2&gt;&amp; y);
+</pre>
 
 <blockquote>
-
-<pre>size_t i_loc = i - c.begin();
-c.insert(i, c1.begin(), c1.end());</pre>
-
+<i>Returns:</i> <tt>y &lt; x</tt>
 </blockquote>
 
-<p>and now the first inserted element is at c.begin()+i_loc and one
-past the last is at c.begin()+i_loc+c1.size().<br>
-<br>
-But what if c is a list? I can still find the location of one past the
-last inserted element, because i is still valid. To find the location
-of the first inserted element, though, I must execute something like </p>
+<pre>template &lt;class T1, class T2&gt;
+bool operator&gt;=(const pair&lt;T1,T2&gt;&amp; x, const pair&lt;T1,T2&gt;&amp; y);
+</pre>
 
 <blockquote>
-
-<pre>for (size_t n = c1.size(); n; --n)
-   --i;</pre>
-
+<i>Returns:</i> <tt>!(x &lt; y)</tt>
 </blockquote>
 
-<p>because i is now no longer a random-access iterator.<br>
-<br>
-Alternatively, I might write something like </p>
+<pre>template &lt;class T1, class T2&gt;
+bool operator&lt;=(const pair&lt;T1,T2&gt;&amp; x, const pair&lt;T1,T2&gt;&amp; y);
+</pre>
 
 <blockquote>
-
-<pre>bool first = i == c.begin();
-list&lt;T&gt;::iterator j = i;
-if (!first) --j;
-c.insert(i, c1.begin(), c1.end());
-if (first)
-   j = c.begin();
-else
-   ++j;</pre>
-
+<i>Returns:</i> <tt>!(y &lt; x)</tt>
+</blockquote>
 </blockquote>
 
-<p>which, although wretched, requires less overhead.<br>
-<br>
-But I think the right solution is to change the definition of insert
-so that instead of returning void, it returns an iterator that refers
-to the first element inserted, if any, and otherwise is a copy of its
-first argument.&nbsp; </p>
 
-<p><i>[
-Summit:
-]</i></p>
+<p><b>Rationale:</b></p>
+<p>20.3.1 [operators] paragraph 10 already specifies the semantics.
+That paragraph says that, if declarations of operator!=, operator&gt;,
+operator&lt;=, and operator&gt;= appear without definitions, they are
+defined as specified in 20.3.1 [operators].  There should be no user
+confusion, since that paragraph happens to immediately precede the
+specification of <tt>pair</tt>.</p>
 
 
-<blockquote>
-Reopened by Alisdair.
-</blockquote>
 
-<p><i>[
-Post Summit Alisdair adds:
-]</i></p>
 
 
-<blockquote>
+<hr>
+<h3><a name="299"></a>299. Incorrect return types for iterator dereference</h3>
+<p><b>Section:</b> 24.2.4 [bidirectional.iterators], 24.2.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> John Potter <b>Opened:</b> 2001-01-22  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bidirectional.iterators">issues</a> in [bidirectional.iterators].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-In addition to the original rationale for C++03, this change also gives a
-consistent interface for all container insert operations i.e. they all
-return an iterator to the (first) inserted item.
+In section 24.2.4 [bidirectional.iterators],
+Table 75 gives the return type of *r-- as convertible to T.  This is
+not consistent with Table 74 which gives the return type of *r++ as
+T&amp;.  *r++ = t is valid while *r-- = t is invalid.
 </p>
 
 <p>
-Proposed wording provided.
+In section 24.2.5 [random.access.iterators],
+Table 76 gives the return type of a[n] as convertible to T.  This is
+not consistent with the semantics of *(a + n) which returns T&amp; by
+Table 74.  *(a + n) = t is valid while a[n] = t is invalid.
 </p>
-</blockquote>
-
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
 
-
-<blockquote>
 <p>
-Q: why isn't this change also proposed for associative containers?
+Discussion from the Copenhagen meeting: the first part is
+uncontroversial.  The second part, operator[] for Random Access
+Iterators, requires more thought.  There are reasonable arguments on
+both sides.  Return by value from operator[] enables some potentially
+useful iterators, e.g. a random access "iota iterator" (a.k.a
+"counting iterator" or "int iterator").  There isn't any obvious way
+to do this with return-by-reference, since the reference would be to a
+temporary.  On the other hand, <tt>reverse_iterator</tt> takes an
+arbitrary Random Access Iterator as template argument, and its
+operator[] returns by reference.  If we decided that the return type
+in Table 76 was correct, we would have to change
+<tt>reverse_iterator</tt>.  This change would probably affect user
+code.
 </p>
 
 <p>
-A: The returned iterator wouldn't necessarily point to a contiguous range.
+History: the contradiction between <tt>reverse_iterator</tt> and the
+Random Access Iterator requirements has been present from an early
+stage.  In both the STL proposal adopted by the committee
+(N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
+Stepanov and Lee), the Random Access Iterator requirements say that
+operator[]'s return value is "convertible to T".  In N0527
+reverse_iterator's operator[] returns by value, but in HPL-95-11
+(R.1), and in the STL implementation that HP released to the public,
+reverse_iterator's operator[] returns by reference.  In 1995, the
+standard was amended to reflect the contents of HPL-95-11 (R.1).  The
+original intent for operator[] is unclear.
 </p>
 
 <p>
-Moved to Ready.
+In the long term it may be desirable to add more fine-grained 
+iterator requirements, so that access method and traversal strategy
+can be decoupled.  (See "Improved Iterator Categories and
+Requirements", N1297 = 01-0011, by Jeremy Siek.)  Any decisions
+about issue 299 should keep this possibility in mind.
 </p>
-</blockquote>
-
 
+<p>Further discussion: I propose a compromise between John Potter's
+resolution, which requires <tt>T&amp;</tt> as the return type of
+<tt>a[n]</tt>, and the current wording, which requires convertible to
+<tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt>
+for the return type of the expression <tt>a[n]</tt>, but to also add
+<tt>a[n] = t</tt> as a valid expression. This compromise "saves" the
+common case uses of random access iterators, while at the same time
+allowing iterators such as counting iterator and caching file
+iterators to remain random access iterators (iterators where the
+lifetime of the object returned by <tt>operator*()</tt> is tied to the
+lifetime of the iterator).
+</p>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-<sef ref="[sequence.reqmts]"> Table 83
-change return type from <tt>void</tt> to <tt>iterator</tt> for the following rows:
-</sef></p>
-
-<blockquote>
-<table border="1">
-<caption>Table 83 -- Sequence container requirements (in addition to container)</caption>
-<tbody><tr>
-<th>Expression</th>
-<th>Return type</th>
-<th>Assertion/note pre-/post-condition</th>
-</tr>
-<tr>
-<td>
-<tt>a.insert(p,n,t)</tt>
-</td>
-<td>
-<tt><del>void</del> <ins>iterator</ins></tt>
-</td>
-<td>
-Inserts <tt>n</tt> copies of <tt>t</tt> before <tt>p</tt>.
-</td>
-</tr>
-
-<tr>
-<td>
-<tt>a.insert(p,i,j)</tt>
-</td>
-<td>
-<tt><del>void</del> <ins>iterator</ins></tt>
-</td>
-<td>
-Each iterator in the range <tt>[i,j)</tt> shall be 
-dereferenced exactly once. 
-pre: <tt>i</tt> and <tt>j</tt> are not iterators into <tt>a</tt>. 
-Inserts copies of elements in <tt>[i, j)</tt> before <tt>p</tt>
-</td>
-</tr>
-
-<tr>
-<td>
-<tt>a.insert(p,il)</tt>
-</td>
-<td>
-<tt><del>void</del> <ins>iterator</ins></tt>
-</td>
-<td>
-<tt>a.insert(p, il.begin(), il.end())</tt>.
-</td>
-</tr>
-</tbody></table>
-</blockquote>
+Note that the compromise resolution necessitates a change to
+<tt>reverse_iterator</tt>. It would need to use a proxy to support
+<tt>a[n] = t</tt>.
+</p>
 
 <p>
-Add after p6 23.2.3 [sequence.reqmts]:
+Note also there is one kind of mutable random access iterator that
+will no longer meet the new requirements. Currently, iterators that
+return an r-value from <tt>operator[]</tt> meet the requirements for a
+mutable random access iterartor, even though the expression <tt>a[n] =
+t</tt> will only modify a temporary that goes away. With this proposed
+resolution, <tt>a[n] = t</tt> will be required to have the same
+operational semantics as <tt>*(a + n) = t</tt>.
 </p>
 
-<blockquote>
-<p>-6- ...</p>
-
-<p><ins>
-The iterator returned from <tt>a.insert(p,n,t)</tt> points to the copy of the
-first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>n == 0</tt>.
-</ins></p>
+<p><i>[
+2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
+]</i></p>
 
-<p><ins>
-The iterator returned from <tt>a.insert(p,i,j)</tt> points to the copy of the
-first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>i == j</tt>.
-</ins></p>
 
-<p><ins>
-The iterator returned from <tt>a.insert(p,il)</tt> points to the copy of the
-first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>il</tt> is empty.
-</ins></p>
+<p><i>[
+2009-09-18 Alisdair adds:
+]</i></p>
 
-</blockquote>
 
+<blockquote>
 <p>
-p2 23.3.2 [deque] Update class definition, change return type
-from <tt>void</tt> to <tt>iterator</tt>:
+Why can't we write through the reference returned from operator[] on a
+random access iterator?
 </p>
 
-<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
-template &lt;class InputIterator&gt;
-  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
-  <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;T&gt;);
-</pre></blockquote>
-
 <p>
-23.3.2.3 [deque.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
+Recommended solution:
 </p>
 
-<blockquote><pre>  <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
-template &lt;class InputIterator&gt;
-  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
-</pre></blockquote>
-
 <p>
-Add the following (missing) declaration
+In table Table 104 -- Random access iterator requirements, replace
 </p>
 
-<blockquote><pre><ins>iterator insert(const_iterator position, initializer_list&lt;T&gt;);</ins>
-</pre></blockquote>
+<blockquote>
+a[n] : convertible to <del><tt>const T &amp;</tt></del>
+<ins><tt>T&amp;</tt> if <tt>X</tt> is mutable, otherwise convertible to <tt>const T&amp;</tt></ins>
+</blockquote>
+</blockquote>
 
-<p>
-23.3.3 [forwardlist] Update class definition, change return type
-from <tt>void</tt> to <tt>iterator</tt>:
-</p>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
-<blockquote><pre><del>void</del> <ins>iterator</ins> insert_after(const_iterator position, initializer_list&lt;T&gt; il);
-<del>void</del> <ins>iterator</ins> insert_after(const_iterator position, size_type n, const T&amp; x);
-template &lt;class InputIterator&gt;
-  <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, InputIterator first, InputIterator last);
-</pre></blockquote>
-
-<p>
-p8 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt>:
-</p>
-
-<blockquote><pre><del>void</del> <ins>iterator</ins> insert_after(const_iterator position, size_type n, const T&amp; x);
-</pre></blockquote>
-
-<p>
-Add paragraph:
-</p>
-
-<blockquote>
-Returns: position.
-</blockquote>
-
-<p>
-p10 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt>:
-</p>
-
-<blockquote><pre>template &lt;class InputIterator&gt;
-  <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, InputIterator first, InputIterator last);
-</pre></blockquote>
-
-<p>
-Add paragraph:
-</p>
-
-<blockquote>
-Returns: position.
-</blockquote>
-
-<p>
-p12 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
-</p>
-
-<blockquote><pre><del>void</del> <ins>iterator</ins> insert_after(const_iterator position, initializer_list&lt;T&gt; il);
-</pre></blockquote>
-
-<p>
-change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
-</p>
-
-<p>
-p2 23.3.4 [list] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
-</p>
-
-<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
-
-template &lt;class InputIterator&gt;
-<del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
-
-<del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;T&gt;);
-</pre></blockquote>
-
-<p>
-23.3.4.3 [list.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
-</p>
-
-<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
-
-template &lt;class InputIterator&gt;
-  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
-</pre></blockquote>
-
-<p>
-Add the following (missing) declaration
-</p>
-
-<blockquote><pre>iterator insert(const_iterator position, initializer_list&lt;T&gt;);
-</pre></blockquote>
-
-<p>
-p2 23.3.6 [vector]
-</p>
-
-<p>
-Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
-</p>
-
-<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, T&amp;&amp; x);
-
-<del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
-
-template &lt;class InputIterator&gt;
-  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
-
-<del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;T&gt;);
-</pre></blockquote>
-
-<p>
-23.3.6.4 [vector.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
-</p>
-
-<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
-
-template &lt;class InputIterator&gt;
-  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
-</pre></blockquote>
-
-<p>
-Add the following (missing) declaration
-</p>
-
-<blockquote><pre>iterator insert(const_iterator position, initializer_list&lt;T&gt;);
-</pre></blockquote>
-
-
-<p>
-p1 23.3.7 [vector.bool] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
-</p>
-
-<blockquote><pre><del>void</del> <ins>iterator</ins> insert (const_iterator position, size_type n, const bool&amp; x);
-
-template &lt;class InputIterator&gt;
-  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
-
-  <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;bool&gt; il);
-</pre></blockquote>
-
-<p>
-p5 21.4 [basic.string] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
-</p>
-
-<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, size_type n, charT c);
-
-template&lt;class InputIterator&gt;
-  <del>void</del> <ins>iterator</ins> insert(const_iterator p, InputIterator first, InputIterator last);
-
-<del>void</del> <ins>iterator</ins> insert(const_iterator p, initializer_list&lt;charT&gt;);
-</pre></blockquote>
-
-<p>
-p13 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
-</p>
-
-<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, size_type n, charT c);
-</pre></blockquote>
-
-<p>
-Add paragraph:
-</p>
-
-<blockquote>
-<i>Returns:</i> an iterator which refers to the copy of the first inserted
-character, or <tt>p</tt> if <tt>n == 0</tt>.
-</blockquote>
-
-<p>
-p15 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
-</p>
-
-<blockquote><pre>template&lt;class InputIterator&gt;
-  <del>void</del> <ins>iterator</ins> insert(const_iterator p, InputIterator first, InputIterator last);
-</pre></blockquote>
-
-<p>
-Add paragraph:
-</p>
-
-<blockquote>
-<i>Returns:</i> an iterator which refers to the copy of the first inserted
-character, or <tt>p</tt> if <tt>first == last</tt>.
-</blockquote>
-
-<p>
-p17 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
-</p>
-
-<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, initializer_list&lt;charT&gt; il);
-</pre></blockquote>
-
-<p>
-Add paragraph:
-</p>
-
-<blockquote>
-<i>Returns:</i> an iterator which refers to the copy of the first inserted
-character, or <tt>p</tt> if <tt>il</tt> is empty.
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-
-<p><i>[
-The following was the C++98/03 rationale and does not necessarily apply to the
-proposed resolution in the C++0X time frame:
-]</i></p>
-
-
-<blockquote>
-<p>The LWG believes this was an intentional design decision and so is
-not a defect. It may be worth revisiting for the next standard.</p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="299"></a>299. Incorrect return types for iterator dereference</h3>
-<p><b>Section:</b> 24.2.5 [bidirectional.iterators], 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> John Potter <b>Opened:</b> 2001-01-22  <b>Last modified:</b> 2009-07-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bidirectional.iterators">issues</a> in [bidirectional.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In section 24.2.5 [bidirectional.iterators],
-Table 75 gives the return type of *r-- as convertible to T.  This is
-not consistent with Table 74 which gives the return type of *r++ as
-T&amp;.  *r++ = t is valid while *r-- = t is invalid.
-</p>
-
-<p>
-In section 24.2.6 [random.access.iterators],
-Table 76 gives the return type of a[n] as convertible to T.  This is
-not consistent with the semantics of *(a + n) which returns T&amp; by
-Table 74.  *(a + n) = t is valid while a[n] = t is invalid.
-</p>
-
-<p>
-Discussion from the Copenhagen meeting: the first part is
-uncontroversial.  The second part, operator[] for Random Access
-Iterators, requires more thought.  There are reasonable arguments on
-both sides.  Return by value from operator[] enables some potentially
-useful iterators, e.g. a random access "iota iterator" (a.k.a
-"counting iterator" or "int iterator").  There isn't any obvious way
-to do this with return-by-reference, since the reference would be to a
-temporary.  On the other hand, <tt>reverse_iterator</tt> takes an
-arbitrary Random Access Iterator as template argument, and its
-operator[] returns by reference.  If we decided that the return type
-in Table 76 was correct, we would have to change
-<tt>reverse_iterator</tt>.  This change would probably affect user
-code.
-</p>
-
-<p>
-History: the contradiction between <tt>reverse_iterator</tt> and the
-Random Access Iterator requirements has been present from an early
-stage.  In both the STL proposal adopted by the committee
-(N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
-Stepanov and Lee), the Random Access Iterator requirements say that
-operator[]'s return value is "convertible to T".  In N0527
-reverse_iterator's operator[] returns by value, but in HPL-95-11
-(R.1), and in the STL implementation that HP released to the public,
-reverse_iterator's operator[] returns by reference.  In 1995, the
-standard was amended to reflect the contents of HPL-95-11 (R.1).  The
-original intent for operator[] is unclear.
-</p>
-
-<p>
-In the long term it may be desirable to add more fine-grained 
-iterator requirements, so that access method and traversal strategy
-can be decoupled.  (See "Improved Iterator Categories and
-Requirements", N1297 = 01-0011, by Jeremy Siek.)  Any decisions
-about issue 299 should keep this possibility in mind.
-</p>
-
-<p>Further discussion: I propose a compromise between John Potter's
-resolution, which requires <tt>T&amp;</tt> as the return type of
-<tt>a[n]</tt>, and the current wording, which requires convertible to
-<tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt>
-for the return type of the expression <tt>a[n]</tt>, but to also add
-<tt>a[n] = t</tt> as a valid expression. This compromise "saves" the
-common case uses of random access iterators, while at the same time
-allowing iterators such as counting iterator and caching file
-iterators to remain random access iterators (iterators where the
-lifetime of the object returned by <tt>operator*()</tt> is tied to the
-lifetime of the iterator).
-</p>
-
-<p>
-Note that the compromise resolution necessitates a change to
-<tt>reverse_iterator</tt>. It would need to use a proxy to support
-<tt>a[n] = t</tt>.
-</p>
-
-<p>
-Note also there is one kind of mutable random access iterator that
-will no longer meet the new requirements. Currently, iterators that
-return an r-value from <tt>operator[]</tt> meet the requirements for a
-mutable random access iterartor, even though the expression <tt>a[n] =
-t</tt> will only modify a temporary that goes away. With this proposed
-resolution, <tt>a[n] = t</tt> will be required to have the same
-operational semantics as <tt>*(a + n) = t</tt>.
-</p>
-
-<p><i>[
-2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
-]</i></p>
 
+<blockquote>
+Leave Open. Alisdair to spearhead a paper on revivification.
+</blockquote>
 
 
 
@@ -1725,7 +1467,7 @@ San Francisco:
 
 <blockquote>
 Solved by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2758.pdf">N2758</a>.
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2758.pdf">N2758</a>.
 </blockquote>
 
 
@@ -1736,10 +1478,10 @@ Solved by
 
 <hr>
 <h3><a name="397"></a>397. ostream::sentry dtor throws exceptions</h3>
-<p><b>Section:</b> 27.7.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05  <b>Last modified:</b> 2009-07-14</p>
+<p><b>Section:</b> 27.7.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05  <b>Last modified:</b> 2009-10-20</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
     <p>
 17.4.4.8, p3 prohibits library dtors from throwing exceptions.
@@ -1788,6 +1530,25 @@ Move to Review. Add "Throws: nothing" to the specification of ostream::sentry::~
 </p>
 </blockquote>
 
+<p><i>[
+2009-10-13 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+The proposed resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a> is written to match the outcome
+of this issue.
+</blockquote>
+
+<p><i>[
+2009 Santa Cruz:
+]</i></p>
+
+
+<blockquote>
+Move to Open.  Our intent is to solve this issue with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>.
+</blockquote>
+
 
 
 <p><b>Proposed resolution:</b></p>
@@ -1816,11 +1577,11 @@ is <tt>true</tt>, calls <tt>os.flush()</tt>.
 
 <hr>
 <h3><a name="408"></a>408. Is vector&lt;reverse_iterator&lt;char*&gt; &gt; forbidden?</h3>
-<p><b>Section:</b> 24.2 [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2003-06-03  <b>Last modified:</b> 2009-07-31</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Section:</b> 24.2 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2003-06-03  <b>Last modified:</b> 2009-11-03</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 I've been discussing iterator semantics with Dave Abrahams, and a 
@@ -1828,7 +1589,7 @@ surprise has popped up.  I don't think this has been discussed before.
 </p>
 
 <p>
-24.2 [iterator.concepts] says that the only operation that can be performed on "singular"
+X [iterator.concepts] says that the only operation that can be performed on "singular"
 iterator values is to assign a non-singular value to them.  (It 
 doesn't say they can be destroyed, and that's probably a defect.)  
 Some implementations have taken this to imply that there is no need 
@@ -1926,7 +1687,7 @@ are default-initialized, and it should explicitly allow destroying any
 iterator value, singular or not, default-initialized or not.
 </p>
 
-<p>Related issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a></p>
+<p>Related issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a></p>
 <p><i>[
 We don't want to require all singular iterators to be copyable,
 because that is not the case for pointers.  However, default
@@ -1955,18 +1716,18 @@ resolved.  That just leaves copying (with moving implied).
 
 <blockquote>
 <p>
-This is related to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>.
+This is related to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>.
 </p>
 <p>
-Note that there is a bug in the proposed resolution to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>. The
+Note that there is a bug in the proposed resolution to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>. The
 change to  [reverse.iter.con] should be modified so that the word
 "default" in the second sentence of the Effects clause is replaced by
 "value."
 </p>
 <p>
-We believe that the proposed fix to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a> (now corrected) is
+We believe that the proposed fix to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a> (now corrected) is
 sufficient to solve the problem for reverse_iterator. However, Alisdair
-pointed out that LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a> does not solve the general problem for authors
+pointed out that LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a> does not solve the general problem for authors
 of iterator adaptors.
 </p>
 <p>
@@ -1984,12 +1745,38 @@ Move to Review after Alisdair updates the wording.
 ]</i></p>
 
 
+<p><i>[
+2009-08-17 Alisdair and Daniel collaborate on slightly revised wording.
+This issue depends upon <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>
+]</i></p>
+
+
+<p><i>[
+2009-10-14 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+There is a clear dependency on <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1213">1213</a>, because the term "singular",
+which is used as part of the resolution, is not properly defined yet.
+</blockquote>
+
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
+
+<blockquote>
+Moved to Open. Alisdair will provide improved wording to make
+this have "value semantics" and otherwise behave like a valid iterator.
+</blockquote>
+
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add a new paragrpah to Iterator concepts 24.2 [iterator.concepts] after para 5 (the one
-describing singular iterators)
+Add a new paragrpah to Iterator concepts 24.2 [iterator.requirements] after para 5 (the one describing
+singular iterators)
 </p>
 <blockquote>
 <p>
@@ -2011,8 +1798,9 @@ Dereferenceable values are always non-singular.
 </p>
 <p><ins>
 After value-initialization, any iterator that satisfies the
-<tt>DefaultConstructible</tt> concept shall not introduce undefined behaviour
-when used the source of a copy or move operation, even if it would
+<tt>DefaultConstructible</tt> requirements ([defaultconstructible]) shall not introduce undefined behaviour
+when used <ins>as</ins> the
+source of a copy or move operation, even if it would
 otherwise be singular. [<i>Note:</i> This guarantee is not offered for
 default-initialization (8.5 [dcl.init]), although the distinction only
 matters for types with trivial default constructors such as pointers. &#8212;
@@ -2028,127 +1816,9 @@ matters for types with trivial default constructors such as pointers. &#8212;
 
 
 <hr>
-<h3><a name="419"></a>419. 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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2009-07-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-        <p>
-
-27.7.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good()
-is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to
-true if the stream state is good after any preparation. 27.7.1.2.1 [istream.formatted.reqmts], p1 then
-says that a formatted input function endeavors to obtain the requested input
-if the sentry's operator bool() returns true.
-
-Given these requirements, no formatted extractor should ever set failbit if
-the initial stream rdstate() == eofbit. That is contrary to the behavior of
-all implementations I tested. The program below prints out
-
-eof = 1, fail = 0
-eof = 1, fail = 1
-
-on all of them.
-        </p>
-<pre>
-#include &lt;sstream&gt;
-#include &lt;cstdio&gt;
-
-int main()
-{
-    std::istringstream strm ("1");
-
-    int i = 0;
-
-    strm &gt;&gt; i;
-
-    std::printf ("eof = %d, fail = %d\n",
-                 !!strm.eof (), !!strm.fail ());
-
-    strm &gt;&gt; i;
-
-    std::printf ("eof = %d, fail = %d\n",
-                 !!strm.eof (), !!strm.fail ());
-}
-
-</pre>
-        <p>
-<br>
-
-Comments from Jerry Schwarz (c++std-lib-11373):
-<br>
-
-Jerry Schwarz wrote:
-<br>
-
-I don't know where (if anywhere) it says it in the standard, but the
-formatted extractors are supposed to set failbit if they don't extract
-any characters. If they didn't then simple loops like
-<br>
-
-while (cin &gt;&gt; x);
-<br>
-
-would loop forever.
-<br>
-
-Further comments from Martin Sebor:
-<br>
-
-The question is which part of the extraction should prevent this from happening
-by setting failbit when eofbit is already set. It could either be the sentry
-object or the extractor. It seems that most implementations have chosen to
-set failbit in the sentry [...] so that's the text that will need to be
-corrected. 
-
-        </p>
-<p>
-Pre Berlin:  This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a>.  If the sentry
-sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
-you can never seek away from the end of stream.
-</p>
-<p>Kona: Possibly NAD.  If eofbit is set then good() will return false.  We
-  then set <i>ok</i> to false.  We believe that the sentry's
-  constructor should always set failbit when <i>ok</i> is false, and
-  we also think the standard already says that.  Possibly it could be
-  clearer.</p> 
-
-
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
-
-
-<blockquote>
-Moved to Ready.
-</blockquote>
-
-    
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 27.7.1.1.3 [istream::sentry], p2 to:
-</p>
-
-<blockquote>
-<pre>explicit sentry(basic_istream&lt;charT,traits&gt;&amp; <i>is</i> , bool <i>noskipws</i> = false);</pre>
-<p>
--2- <i>Effects:</i> If <tt>is.good()</tt> is <del><tt>true</tt></del>
-<ins><tt>false</tt></ins>, <ins>calls <tt>is.setstate(failbit)</tt>. 
-Otherwise</ins> prepares for formatted or unformatted input. ...
-</p>
-</blockquote>
-
-
-
-
-
-
-<hr>
 <h3><a name="427"></a>427. stage 2 and rationale of DR 221</h3>
 <p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2009-07-14</p>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2009-10-26</p>
 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
@@ -2233,18 +1903,311 @@ Daniel volunteered to provide wording.
 </p>
 </blockquote>
 
+<p><i>[
+2009-09-19 Daniel provided wording.
+]</i></p>
+
+
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
+
+<blockquote>
+Leave as Open. Alisdair and/or Tom will provide wording based on discussions.
+We want to clearly state that streams and locales work just on <tt>char</tt>
+and <tt>wchar_t</tt> (except where otherwise specified).
+</blockquote>
+
 
 
 <p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>
+Change 22.3.1.1.1 [locale.category]/6:
+</p>
+
+<blockquote>
+[..] A template formal parameter with name <tt>C</tt> represents the set of all possible
+specializations on a <ins><tt>char</tt> or <tt>wchar_t</tt></ins> parameter<del> that satisfies
+the requirements for a character on which any of the iostream components
+can be instantiated</del>. [..]
+</blockquote>
+</li>
+
+<li>
+<p>
+Add the following sentence to the end of 22.4.2 [category.numeric]/2:
+</p>
+
+<blockquote>
+[..] These specializations refer to [..], and also for the <tt>ctype&lt;&gt;</tt> facet to
+perform character classification. <ins>Implementations are encouraged
+but not required to use the <tt>char_traits&lt;charT&gt;</tt> functions for all
+comparisons and assignments of characters of type <tt>charT</tt> that do
+not belong to the set of required specializations.</ins>
+</blockquote>
+</li>
+
+<li>
+<p>
+Change 22.4.2.1.2 [facet.num.get.virtuals]/3:
+</p>
+
+<blockquote>
+<p>
+Stage 2: If <tt>in==end</tt> then stage 2 terminates. Otherwise a <tt>charT</tt> is taken
+from <tt>in</tt> and local variables are initialized as if by
+</p>
+
+<blockquote><pre>char_type ct = *in;
+<ins>using tr = char_traits&lt;char_type&gt;;
+const char_type* pos = tr::find(atoms, sizeof(src) - 1, ct);</ins>
+char c = src[<del>find(atoms, atoms + sizeof(src) - 1, ct) - atoms</del>
+             <ins>pos ? pos - atoms : sizeof(src) - 1</ins>];
+if (<ins>tr::eq(ct, </ins><del>ct == </del>use_facet&lt;numpunct&lt;charT&gt;(loc).decimal_point()<ins>)</ins>)
+    c = '.';
+bool discard =
+    <ins>tr::eq(ct, </ins><del>ct == </del>use_facet&lt;numpunct&lt;charT&gt;(loc).thousands_sep()<ins>)</ins>
+    &amp;&amp; use_facet&lt;numpunct&lt;charT&gt; &gt;(loc).grouping().length() != 0;
+</pre></blockquote>
+
+<p>
+where the values <tt>src</tt> and <tt>atoms</tt> are defined as if by: [..]
+</p>
+</blockquote>
+
+<p>
+[Remark of the author: I considered to replace the initialization
+"<tt>char_type ct = *in;</tt>"
+by the sequence "<tt>char_type ct; tr::assign(ct, *in);</tt>", but decided
+against it, because
+it is a copy-initialization context, not an assignment]
+</p>
+</li>
+
+<li>
+<p>
+Add the following sentence to the end of 22.4.5 [category.time]/1:
+</p>
+
+<blockquote>
+[..] Their members use [..] , to determine formatting details.
+<ins>Implementations are encouraged but not required to use the
+<tt>char_traits&lt;charT&gt;</tt> functions for all comparisons and assignments
+of characters of type <tt>charT</tt> that do
+not belong to the set of required specializations.</ins>
+</blockquote>
+</li>
+
+<li>
+<p>
+Change 22.4.5.1.1 [locale.time.get.members]/8 bullet 4:
+</p>
+
+<ul>
+<li>
+<del>The next element of <tt>fmt</tt> is equal to <tt>'%'</tt></del> <ins>For the next element <tt>c</tt>
+of <tt>fmt char_traits&lt;char_type&gt;::eq(c, use_facet&lt;ctype&lt;char_type&gt;&gt;(f.getloc()).widen('%')) == true</tt></ins>,
+[..]
+</li>
+</ul>
+</li>
+
+<li>
+<p>
+Add the following sentence to the end of 22.4.6 [category.monetary]/2:
+</p>
+
+<blockquote>
+Their members use [..] to determine formatting details.
+<ins>Implementations are encouraged but not required to use the
+<tt>char_traits&lt;charT&gt;</tt> functions for all comparisons and assignments
+of characters of type <tt>charT</tt> that do
+not belong to the set of required specializations.</ins>
+</blockquote>
+</li>
+
+<li>
+<p>
+Change 22.4.6.1.2 [locale.money.get.virtuals]/4:
+</p>
+
+<blockquote>
+<p>
+[..] The value <tt>units</tt> is produced as if by:
+</p>
+
+<blockquote><pre>for (int i = 0; i &lt; n; ++i)
+  buf2[i] = src[<ins>char_traits&lt;charT&gt;::</ins>find(atoms, <del>atoms+</del>sizeof(src), buf1[i]) - atoms];
+buf2[n] = 0;
+sscanf(buf2, "%Lf", &amp;units);
+</pre></blockquote>
+</blockquote>
+</li>
+
+<li>
+<p>
+Change 22.4.6.2.2 [locale.money.put.virtuals]/1:
+</p>
+
+<blockquote>
+[..] for character buffers <tt>buf1</tt> and <tt>buf2</tt>. If <ins>for</ins> the first
+character <ins><tt>c</tt></ins>
+in <tt>digits</tt> or <tt>buf2</tt> <del>is equal to
+<tt>ct.widen('-')</tt></del><ins><tt>char_traits&lt;charT&gt;::eq(c,
+ct.widen('-')) == true</tt></ins>, [..]
+</blockquote>
+</li>
+
+<li>
+<p>
+Add a footnote to the first sentence of 27.7.1.2.2 [istream.formatted.arithmetic]/1:
+</p>
+
+<blockquote>
+<p>
+As in the case of the inserters, these extractors depend on the locale's
+<tt>num_get&lt;&gt;</tt> (22.4.2.1) object to perform parsing the input stream
+data.<ins><sup>(footnote)</sup></ins> [..]
+</p>
+
+<p>
+<ins>
+<sup>footnote)</sup> If the traits of the input stream has different semantics for <tt>lt()</tt>,
+<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
+results.
+</ins>
+</p>
+</blockquote>
+</li>
+
+<li>
+<p>
+Add a footnote to the second sentence of 27.7.2.6.2 [ostream.inserters.arithmetic]/1:
+</p>
+
+<blockquote>
+<p>
+<i>Effects:</i> The classes <tt>num_get&lt;&gt;</tt> and
+<tt>num_put&lt;&gt;</tt> handle locale-dependent numeric formatting and
+parsing. These inserter functions use the imbued locale value to perform
+numeric formatting.<ins><sup>(footnote)</sup></ins> [..]
+</p>
+
+<p>
+<ins>
+<sup>footnote)</sup> If the traits of the output stream has different semantics for <tt>lt()</tt>,
+<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
+results.
+</ins>
+</p>
+</blockquote>
+</li>
+
+<li>
+<p>
+Add a footnote after the first sentence of 27.7.4 [ext.manip]/4:
+</p>
+
+<blockquote>
+<p>
+<i>Returns:</i> An object of unspecified type such that if in is an object of type
+<tt>basic_istream&lt;charT, traits&gt;</tt> then the expression <tt>in &gt;&gt; get_money(mon, intl)</tt>
+behaves as if it called <tt>f(in, mon, intl)</tt>, where the function <tt>f</tt> is defined
+as:<ins><sup>(footnote)</sup></ins> [..]
+</p>
+
+<p>
+<ins>
+<sup>footnote)</sup> If the traits of the input stream has different semantics for <tt>lt()</tt>,
+<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
+results.
+</ins>
+</p>
+</blockquote>
+</li>
+
+<li>
+<p>
+Add a footnote after the first sentence of 27.7.4 [ext.manip]/5:
+</p>
+
+<blockquote>
+<p>
+<i>Returns:</i> An object of unspecified type such that if <tt>out</tt> is an object of type
+<tt>basic_ostream&lt;charT, traits&gt;</tt> then the expression <tt>out &lt;&lt; put_money(mon, intl)</tt>
+behaves as a formatted input function that calls <tt>f(out, mon, intl)</tt>, where the
+function <tt>f</tt> is defined as:<ins><sup>(footnote)</sup></ins> [..]
+</p>
+
+<p>
+<ins>
+<sup>footnote)</sup> If the traits of the output stream has different semantics for <tt>lt()</tt>,
+<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
+results.
+</ins>
+</p>
+</blockquote>
+</li>
+
+<li>
+<p>
+13) Add a footnote after the first sentence of 27.7.4 [ext.manip]/8:
+</p>
+
+<blockquote>
+<p>
+<i>Returns:</i> An object of unspecified type such that if <tt>in</tt> is an
+object of type b<tt>asic_istream&lt;charT, traits&gt;</tt> then the expression
+<tt>in &gt;&gt;get_time(tmb, fmt)</tt> behaves as if it called <tt>f(in, tmb, fmt)</tt>,
+where the function <tt>f</tt> is defined as:<ins><sup>(footnote)</sup></ins> [..]
+</p>
+
+<p>
+<ins>
+<sup>footnote)</sup> If the traits of the input stream has different semantics for <tt>lt()</tt>,
+<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
+results.
+</ins>
+</p>
+</blockquote>
+</li>
+
+<li>
+<p>
+Add a footnote after the first sentence of 27.7.4 [ext.manip]/10:
+</p>
+
+<blockquote>
+<p>
+Returns: An object of unspecified type such that if <tt>out</tt> is an object of type
+<tt>basic_ostream&lt;charT, traits&gt;</tt> then the expression <tt>out &lt;&lt;put_time(tmb, fmt)</tt>
+behaves as if it called <tt>f(out, tmb, fmt)</tt>, where the function <tt>f</tt> is defined
+as:<ins><sup>(footnote)</sup></ins> [..]
+</p>
+
+<p>
+<ins>
+<sup>footnote)</sup> If the traits of the output stream has different semantics for <tt>lt()</tt>,
+<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
+results.
+</ins>
+</p>
+</blockquote>
+</li>
+</ol>
+
 
 
 
 
 <hr>
 <h3><a name="430"></a>430. valarray subset operations</h3>
-<p><b>Section:</b> 26.6.2.4 [valarray.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2009-07-14</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Section:</b> 26.6.2.4 [valarray.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2009-11-04</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 The standard fails to specify the behavior of valarray::operator[](slice)
@@ -2286,6 +2249,16 @@ Move to Ready.
 </p>
 </blockquote>
 
+<p><i>[
+2009-11-04 Pete opens:
+]</i></p>
+
+
+<blockquote>
+The resolution to LWG issue 430 has not been applied --- there have been
+changes to the underlying text, and the resolution needs to be reworked.
+</blockquote>
+
 
 
 <p><b>Proposed resolution:</b></p>
@@ -2425,119 +2398,19 @@ const size_t vi[] = {7, 5, 2, 3, 8};
 
 
 <hr>
-<h3><a name="431"></a>431. Swapping containers with unequal allocators</h3>
-<p><b>Section:</b> X [allocator.requirements], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-09-20  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
+<h3><a name="446"></a>446. Iterator equality between different containers</h3>
+<p><b>Section:</b> 24.2 [iterator.requirements], 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Andy Koenig <b>Opened:</b> 2003-12-16  <b>Last modified:</b> 2009-11-03</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>Clause X [allocator.requirements] paragraph 4 says that implementations
-  are permitted to supply containers that are unable to cope with
-  allocator instances and that container implementations may assume
-  that all instances of an allocator type compare equal.  We gave
-  implementers this latitude as a temporary hack, and eventually we
-  want to get rid of it.  What happens when we're dealing with
-  allocators that <i>don't</i> compare equal?
-</p>
-
-<p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
-  objects of type <tt>vector&lt;int, my_alloc&gt;</tt> and that
-  <tt>v1.get_allocator() != v2.get_allocator()</tt>.  What happens if
-  we write <tt>v1.swap(v2)</tt>?  Informally, three possibilities:</p>
-
-<p>1. This operation is illegal.  Perhaps we could say that an
-  implementation is required to check and to throw an exception, or
-  perhaps we could say it's undefined behavior.</p>
-<p>2. The operation performs a slow swap (i.e. using three
-  invocations of <tt>operator=</tt>, leaving each allocator with its
-  original container.  This would be an O(N) operation.</p>
-<p>3. The operation swaps both the vectors' contents and their
-  allocators.  This would be an O(1) operation. That is:</p>
-  <blockquote>
-  <pre>    my_alloc a1(...);
-    my_alloc a2(...);
-    assert(a1 != a2);
-
-    vector&lt;int, my_alloc&gt; v1(a1);
-    vector&lt;int, my_alloc&gt; v2(a2);
-    assert(a1 == v1.get_allocator());
-    assert(a2 == v2.get_allocator());
-
-    v1.swap(v2);
-    assert(a1 == v2.get_allocator());
-    assert(a2 == v1.get_allocator());
-  </pre>
-  </blockquote>
-
-<p><i>[Kona: This is part of a general problem.  We need a paper
-  saying how to deal with unequal allocators in general.]</i></p>
-
-
-<p><i>[pre-Sydney: Howard argues for option 3 in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html">N1599</a>.
-]</i></p>
-
-
-<p><i>[
-2007-01-12, Howard:  This issue will now tend to come up more often with move constructors
-and move assignment operators.  For containers, these members transfer resources (i.e.
-the allocated memory) just like swap.
-]</i></p>
-
-
-<p><i>[
-Batavia:  There is agreement to overload the container <tt>swap</tt> on the allocator's Swappable
-requirement using concepts.  If the allocator supports Swappable, then container's swap will
-swap allocators, else it will perform a "slow swap" using copy construction and copy assignment.
-]</i></p>
-
-
-<p><i>[
-2009-04-28 Pablo adds:
-]</i></p>
-
-<blockquote>
-Fixed in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>.
-I argued for marking this Tentatively-Ready right after Bellevue,
-but there was a concern that
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
-would break in the presence of the RVO. (That breakage had nothing to do with
-swap, but never-the-less). I addressed that breakage in in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>
-(Summit) by means of a non-normative reference:
-
-<blockquote>
-[<i>Note:</i> in situations where the copy constructor for a container is elided,
-this function is not called. The behavior in these cases is as if
-<tt>select_on_container_copy_construction</tt> returned <tt>x</tt> &#8212; <i>end note</i>]
-</blockquote>
-
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="446"></a>446. Iterator equality between different containers</h3>
-<p><b>Section:</b> 24.2 [iterator.concepts], 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Andy Koenig <b>Opened:</b> 2003-12-16  <b>Last modified:</b> 2009-07-14</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-What requirements does the standard place on equality comparisons between
-iterators that refer to elements of different containers.  For example, if
-v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true?
-Is it allowed to throw an exception?
-</p>
+<p>
+What requirements does the standard place on equality comparisons between
+iterators that refer to elements of different containers.  For example, if
+v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true?
+Is it allowed to throw an exception?
+</p>
 
 <p>
 The standard appears to be silent on both questions.
@@ -2562,97 +2435,42 @@ reachability.
 Daniel volunteered to work on this.
 </blockquote>
 
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="458"></a>458. 24.1.5 contains unintended limitation for operator-</h3>
-<p><b>Section:</b> 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Frey <b>Opened:</b> 2004-02-27  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#random.access.iterators">active issues</a> in [random.access.iterators].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 24.1.5 [lib.random.access.iterators], table 76 the operational
-semantics for the expression "r -= n" are defined as "return r += -n".
-This means, that the expression -n must be valid, which is not the case
-for unsigned types.
-</p>
-
 <p><i>[
-Sydney: Possibly not a real problem, since difference type is required
-to be a signed integer type. However, the wording in the standard may
-be less clear than we would like.
+2009-09-20 Daniel provided wording.
 ]</i></p>
 
 
 <p><i>[
-Post Summit Alisdair adds:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-<p>
-This issue refers to a requirements table we have removed.
-</p>
-<p>
-The issue might now relate to 24.2.6 [random.access.iterators] p5.
-However, the rationale in the issue already recognises that the
-<tt>difference_type</tt> must be signed, so this really looks NAD.
-</p>
+Leave as Open. Alisdair has volunteered to refine the wording.
 </blockquote>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
 
-<blockquote>
-<p>
-We agree with Alisdair's observations.
-</p>
+
+<p><b>Proposed resolution:</b></p>
 <p>
-Move to NAD.
+Insert a new paragraph between 24.2 [iterator.requirements]/7+8:
 </p>
-</blockquote>
-
-<p><i>[
-2009-07 Frankfurt:
-]</i></p>
-
 
 <blockquote>
 <p>
-Need to look at again without concepts.
-</p>
-<p>
-There was a question about this phrase in the discussion: "the
-expression -n must be valid, which is not the case for unsigned types."
-If n is an object ofthe iterator difference_type (eg ptrdiff_t), then it
-is never unsigned.
+[..] The result of the application of functions in the library to invalid
+ranges is undefined.
 </p>
-</blockquote>
 
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-To remove this limitation, I suggest to change the
-operational semantics for this column to:
+<p><ins>The result of directly or indirectly evaluating any comparison function
+or the binary - operator with two iterator values as arguments that
+were obtained
+from two different ranges <tt>r1</tt> and <tt>r2</tt> (including their past-the-end values) which
+are not subranges of one common range is undefined, unless explicitly
+described otherwise.</ins>
 </p>
-<blockquote><pre>    { Distance m = n;
-      if (m &gt;= 0)
-        while (m--) --r;
-      else
-        while (m++) ++r;
-      return r; }
-</pre></blockquote>
+
+</blockquote>
 
 
 
@@ -2660,573 +2478,212 @@ operational semantics for this column to:
 
 
 <hr>
-<h3><a name="463"></a>463. auto_ptr usability issues</h3>
-<p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Rani Sharoni <b>Opened:</b> 2003-12-07  <b>Last modified:</b> 2009-07-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="471"></a>471. result of what() implementation-defined</h3>
+<p><b>Section:</b> 18.8.1 [exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 
-<p>
-TC1 CWG DR #84 effectively made the template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;()
-member of auto_ptr (20.4.5.3/4) obsolete.
-</p>
-
-<p>
-The sole purpose of this obsolete conversion member is to enable copy
-initialization base from r-value derived (or any convertible types like
-cv-types) case:
-</p>
-<pre>#include &lt;memory&gt;
-using std::auto_ptr;
-
-struct B {};
-struct D : B {};
-
-auto_ptr&lt;D&gt; source();
-int sink(auto_ptr&lt;B&gt;);
-int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
-</pre>
-
-<p>
-The excellent analysis of conversion operations that was given in the final
-auto_ptr proposal
-(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
-explicitly specifies this case analysis (case 4). DR #84 makes the analysis
-wrong and actually comes to forbid the loophole that was exploited by the
-auto_ptr designers.
-</p>
-
-<p>
-I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
-ever allowed this case. This is probably because it requires 3 user defined
-conversions and in fact current compilers conform to DR #84.
-</p>
+<p>[lib.exception] specifies the following:</p>
+<pre>    exception (const exception&amp;) throw();
+    exception&amp; operator= (const exception&amp;) throw();
 
-<p>
-I was surprised to discover that the obsolete conversion member actually has
-negative impact of the copy initialization base from l-value derived
-case:</p>
-<pre>auto_ptr&lt;D&gt; dp;
-int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
+    -4- Effects: Copies an exception object.
+    -5- Notes: The effects of calling what() after assignment
+        are implementation-defined.
 </pre>
 
 <p>
-I'm sure that the original intention was allowing this initialization using
-the template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;&amp; a) constructor (20.4.5.1/4) but
-since in this copy initialization it's merely user defined conversion (UDC)
-and the obsolete conversion member is UDC with the same rank (for the early
-overloading stage) there is an ambiguity between them.
+First, does the Note only apply to the assignment operator? If so,
+what are the effects of calling what() on a copy of an object? Is
+the returned pointer supposed to point to an identical copy of
+the NTBS returned by what() called on the original object or not?
 </p>
 
 <p>
-Removing the obsolete member will have impact on code that explicitly
-invokes it:
+Second, is this Note intended to extend to all the derived classes
+in section 19? I.e., does the standard provide any guarantee for
+the effects of what() called on a copy of any of the derived class
+described in section 19?
 </p>
-<pre>int y = sink(source().operator auto_ptr&lt;B&gt;());
-</pre>
 
 <p>
-IMHO no one ever wrote such awkward code and the reasonable workaround for
-#1 is:
+Finally, if the answer to the first question is no, I believe it
+constitutes a defect since throwing an exception object typically
+implies invoking the copy ctor on the object. If the answer is yes,
+then I believe the standard ought to be clarified to spell out
+exactly what the effects are on the copy (i.e., after the copy
+ctor was called).
 </p>
-<pre>int y = sink( auto_ptr&lt;B&gt;(source()) );
-</pre>
 
-<p>
-I was even more surprised to find out that after removing the obsolete
-conversion member the initialization was still ill-formed:
-int x3 = sink(dp); // #3 EDG - no suitable copy constructor
-</p>
+<p><i>[Redmond: Yes, this is fuzzy.  The issue of derived classes is
+  fuzzy too.]</i></p>
 
-<p>
-This copy initialization semantically requires copy constructor which means
-that both template conversion constructor and the auto_ptr_ref conversion
-member (20.4.5.3/3) are required which is what was explicitly forbidden in
-DR #84. This is a bit amusing case in which removing ambiguity results with
-no candidates.
-</p>
 
-<p>
-I also found exception safety issue with auto_ptr related to auto_ptr_ref:
-</p>
-<pre>int f(auto_ptr&lt;B&gt;, std::string);
-auto_ptr&lt;B&gt; source2();
+<p><i>[
+Batavia: Howard provided wording.
+]</i></p>
 
-// string constructor throws while auto_ptr_ref
-// "holds" the pointer
-int x4 = f(source2(), "xyz"); // #4
-</pre>
 
-<p>
-The theoretic execution sequence that will cause a leak:
-</p>
-<ol>
-<li>call auto_ptr&lt;B&gt;::operator auto_ptr_ref&lt;B&gt;()</li>
-<li>call string::string(char const*) and throw</li>
-</ol>
+<p><i>[
+Bellevue:
+]</i></p>
 
-<p>
-According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
-returns auto_ptr_ref&lt;Y&gt; that holds *this and this is another defect since
-the type of *this is auto_ptr&lt;X&gt; where X might be different from Y. Several
-library vendors (e.g. SGI) implement auto_ptr_ref&lt;Y&gt; with Y* as member which
-is much more reasonable. Other vendor implemented auto_ptr_ref as
-defectively required and it results with awkward and catastrophic code:
-int oops = sink(auto_ptr&lt;B&gt;(source())); // warning recursive on all control
-paths
-</p>
 
+<blockquote>
 <p>
-Dave Abrahams noticed that there is no specification saying that
-auto_ptr_ref copy constructor can't throw.
+Eric concerned this is unimplementable, due to nothrow guarantees.
+Suggested implementation would involve reference counting.
 </p>
-
 <p>
-My proposal comes to solve all the above issues and significantly simplify
-auto_ptr implementation. One of the fundamental requirements from auto_ptr
-is that it can be constructed in an intuitive manner (i.e. like ordinary
-pointers) but with strict ownership semantics which yield that source
-auto_ptr in initialization must be non-const. My idea is to add additional
-constructor template with sole propose to generate ill-formed, diagnostic
-required, instance for const auto_ptr arguments during instantiation of
-declaration. This special constructor will not be instantiated for other
-types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
-in hand makes the constructor template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;)
-legitimate since the actual argument can't be const yet non const r-value
-are acceptable.
+Is the implied reference counting subtle enough to call out a note on
+implementation? Probably not.
 </p>
-
 <p>
-This implementation technique makes the "private auxiliary class"
-auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
-GCC and VC) consume the new implementation as expected and allow all
-intuitive initialization and assignment cases while rejecting illegal cases
-that involve const auto_ptr arguments.
+If reference counting required, could we tighten specification further
+to require same pointer value? Probably an overspecification, especially
+if exception classes defer evalutation of final string to calls to
+what().
 </p>
-
-<p>The proposed auto_ptr interface:</p>
-
-<pre>namespace std {
-    template&lt;class X&gt; class auto_ptr {
-    public:
-        typedef X element_type;
-
-        // 20.4.5.1 construct/copy/destroy:
-        explicit auto_ptr(X* p=0) throw();
-        auto_ptr(auto_ptr&amp;) throw();
-        template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;) throw();
-        auto_ptr&amp; operator=(auto_ptr&amp;) throw();
-        template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;) throw();
-        ~auto_ptr() throw();
-
-        // 20.4.5.2 members:
-        X&amp; operator*() const throw();
-        X* operator-&gt;() const throw();
-        X* get() const throw();
-        X* release() throw();
-        void reset(X* p=0) throw();
-
-    private:
-        template&lt;class U&gt;
-        auto_ptr(U&amp; rhs, typename
-unspecified_error_on_const_auto_ptr&lt;U&gt;::type = 0);
-    };
-}
-</pre>
-
 <p>
-One compliant technique to implement the unspecified_error_on_const_auto_ptr
-helper class is using additional private auto_ptr member class template like
-the following:
+Remember issue moved open and not resolved at Batavia, but cannot
+remember who objected to canvas a disenting opinion - please speak up if
+you disagree while reading these minutes!
 </p>
-<pre>template&lt;typename T&gt; struct unspecified_error_on_const_auto_ptr;
-
-template&lt;typename T&gt;
-struct unspecified_error_on_const_auto_ptr&lt;auto_ptr&lt;T&gt; const&gt;
-{ typedef typename auto_ptr&lt;T&gt;::const_auto_ptr_is_not_allowed type; };
-</pre>
-
 <p>
-There are other techniques to implement this helper class that might work
-better for different compliers (i.e. better diagnostics) and therefore I
-suggest defining its semantic behavior without mandating any specific
-implementation. IMO, and I didn't found any compiler that thinks otherwise,
-14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
-verifying this with core language experts.
+Move to Ready as we are accepting words unmodified.
 </p>
+</blockquote>
 
-<p><b>Further changes in standard text:</b></p>
-<p>Remove section 20.4.5.3</p>
-
-<p>Change 20.4.5/2 to read something like:
-Initializing auto_ptr&lt;X&gt; from const auto_ptr&lt;Y&gt; will result with unspecified
-ill-formed declaration that will require unspecified diagnostic.</p>
-
-<p>Change 20.4.5.1/4,5,6 to read:</p>
-
-<pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp; a) throw();</pre>
-<p> 4 Requires: Y* can be implicitly converted to X*.</p>
-<p> 5 Effects: Calls const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(a).release().</p>
-<p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
+<p><i>[
+Sophia Antipolis:
+]</i></p>
 
-<p>Change 20.4.5.1/10</p>
-<pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt; a) throw();
-</pre>
-<p>
-10 Requires: Y* can be implicitly converted to X*. The expression delete
-get() is well formed.
-</p>
 
-<p>LWG TC DR #127 is obsolete.</p>
+<blockquote>
+The issue was pulled from Ready.  It needs to make clear that only homogenous copying
+is intended to be supported, not coping from a derived to a base.
+</blockquote>
 
-<p>
-Notice that the copy constructor and copy assignment operator should remain
-as before and accept non-const auto_ptr&amp; since they have effect on the form
-of the implicitly declared copy constructor and copy assignment operator of
-class that contains auto_ptr as member per 12.8/5,10:
-</p>
-<pre>struct X {
-    // implicit X(X&amp;)
-    // implicit X&amp; operator=(X&amp;)
-    auto_ptr&lt;D&gt; aptr_;
-};
-</pre>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
+<blockquote>
 <p>
-In most cases this indicates about sloppy programming but preserves the
-current auto_ptr behavior.
+Howard supplied the following replacement wording
+for paragraph 7 of the proposed resolution:
 </p>
-
+<blockquote>
+<ins>-7- <i>Postcondition:</i> <tt>what()</tt> shall return the same NTBS
+  as would be obtained by using <tt>static_cast</tt>
+  to cast the rhs to the same types as the lhs
+  and then calling <tt>what()</tt> on that possibly sliced object.</ins>
+</blockquote>
 <p>
-Dave Abrahams encouraged me to suggest fallback implementation in case that
-my suggestion that involves removing of auto_ptr_ref will not be accepted.
-In this case removing the obsolete conversion member to auto_ptr&lt;Y&gt; and
-20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
-cases. The two constructors that I suggested will co exist with the current
-members but will make auto_ptr_ref obsolete in initialization contexts.
-auto_ptr_ref will be effective in assignment contexts as suggested in DR
-#127 and I can't see any serious exception safety issues in those cases
-(although it's possible to synthesize such). auto_ptr_ref&lt;X&gt; semantics will
-have to be revised to say that it strictly holds pointer of type X and not
-reference to an auto_ptr for the favor of cases in which auto_ptr_ref&lt;Y&gt; is
-constructed from auto_ptr&lt;X&gt; in which X is different from Y (i.e. assignment
-from r-value derived to base).
+Pete asks what "the same NTBS" means.
 </p>
-
-<p><i>[Redmond: punt for the moment. We haven't decided yet whether we
-  want to fix auto_ptr for C++-0x, or remove it and replace it with
-  move_ptr and unique_ptr.]</i></p>
-
+</blockquote>
 
 <p><i>[
-Oxford 2007: Recommend NAD.  We're just going to deprecate it.  It still works for simple use cases
-and people know how to deal with it.  Going forward <tt>unique_ptr</tt> is the recommended
-tool.
+2009-07-30 Niels adds:
 ]</i></p>
 
 
-<p><i>[
-2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis.
-]</i></p>
-
+<blockquote>
+Further discussion in the thread starting with c++std-lib-24512.
+</blockquote>
 
 <p><i>[
-2009-07 Frankfurt
+2009-09-24 Niels provided updated wording:
 ]</i></p>
 
 
 <blockquote>
-This is a complicated issue, so we agreed to defer discussion until
-later in the week so that interested parties can read up on it.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Change the synopsis in D.9.1 [auto.ptr]:
+I think the resolution should at least guarantee
+that the result of <tt>what()</tt> is independent of whether the compiler does
+copy-elision. And for any class derived from <tt>std::excepion</tt> that has a
+constructor that allows specifying a <tt>what_arg</tt>, it should make sure that
+the text of a user-provided <tt>what_arg</tt> is preserved, when the object is
+copied. Note that all the implementations I've tested already appear to
+satisfy the proposed resolution, including MSVC 2008 SP1, Apache
+stdcxx-4.2.1, GCC 4.1.2, GCC 4.3.2, and CodeGear C++ 6.13.
 </p>
+<p>
+The proposed resolution was updated with help from Daniel Krügler;
+the update aims to clarify that the proposed postcondition only
+applies to homogeneous copying.
+</p>
+</blockquote>
 
-<blockquote><pre>namespace std { 
-  <del>template &lt;class Y&gt; struct auto_ptr_ref {};</del>
-
-  <ins>// exposition only</ins>
-  <ins>template &lt;class T&gt; struct constant_object;</ins>
-
-  <ins>// exposition only</ins>
-  <ins>template &lt;class T&gt;</ins>
-  <ins>struct cannot_transfer_ownership_from</ins>
-    <ins>: constant_object&lt;T&gt; {};</ins>
-
-  template &lt;class X&gt; class auto_ptr { 
-  public: 
-    typedef X element_type; 
-
-    // D.9.1.1 construct/copy/destroy: 
-    explicit auto_ptr(X* p =0) throw(); 
-    auto_ptr(auto_ptr&amp;) throw(); 
-    template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp;) throw(); 
-    auto_ptr&amp; operator=(auto_ptr&amp;) throw(); 
-    template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del>) throw();
-    <del>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</del>
-    ~auto_ptr() throw(); 
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
-    // D.9.1.2 members: 
-    X&amp; operator*() const throw();
-    X* operator-&gt;() const throw();
-    X* get() const throw();
-    X* release() throw();
-    void reset(X* p =0) throw();
 
-    <del>// D.9.1.3 conversions:</del>
-    <del>auto_ptr(auto_ptr_ref&lt;X&gt;) throw();</del>
-    <del>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() throw();</del>
-    <del>template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;() throw();</del>
+<blockquote>
+Moved to Ready after inserting "publicly accessible" in two places.
+</blockquote>
 
-    <ins>// exposition only</ins>
-    <ins>template&lt;class U&gt;</ins>
-    <ins>auto_ptr(U&amp; rhs, typename cannot_transfer_ownership_from&lt;U&gt;::error = 0);</ins>
-  }; 
 
-  template &lt;&gt; class auto_ptr&lt;void&gt; 
-  { 
-  public: 
-    typedef void element_type; 
-  }; 
 
-}
-</pre></blockquote>
+<p><b>Proposed resolution:</b></p>
 
 <p>
-Remove D.9.1.3 [auto.ptr.conv].
+Change 18.8.1 [exception] to:
 </p>
 
+<blockquote>
 <p>
-Change D.9.1 [auto.ptr], p3:
+-1- The class <tt>exception</tt> defines the base class for the types of
+objects thrown as exceptions by C++ standard library components, and
+certain expressions, to report errors detected during program execution.
 </p>
-
-<blockquote>
-The <tt>auto_ptr</tt> provides a semantics of strict ownership. An
-<tt>auto_ptr</tt> owns the object it holds a pointer to. Copying an
-<tt>auto_ptr</tt> copies the pointer and transfers ownership to the
-destination. If more than one <tt>auto_ptr</tt> owns the same object at
-the same time the behavior of the program is undefined. <ins>Templates
-<tt>constant_object</tt> and <tt>cannot_transfer_ownership_from</tt>,
-and the final constructor of <tt>auto_ptr</tt> are for exposition only.
-For any types <tt>X</tt> and <tt>Y</tt>, initializing
-<tt>auto_ptr&lt;X&gt;</tt> from <tt>const auto_ptr&lt;Y&gt;</tt> is
-ill-formed, diagnostic required.</ins> [<i>Note:</i> The uses of
-<tt>auto_ptr</tt> include providing temporary exception-safety for
-dynamically allocated memory, passing ownership of dynamically allocated
-memory to a function, and returning dynamically allocated memory from a
-function. <tt>auto_ptr</tt> does not meet the <tt>CopyConstructible</tt>
-and <tt>Assignable</tt> requirements for Standard Library container
-elements and thus instantiating a Standard Library container with an
-<tt>auto_ptr</tt> results in undefined behavior. <i>-- end note</i>]
-</blockquote>
-
+<p><ins>
+Each standard library class <tt>T</tt> that derives from class
+<tt>exception</tt> shall have a publicly accessible copy constructor and a publicly accessible copy assignment
+operator that do not exit with an exception. These member functions
+shall preserve the following postcondition: If two objects <i>lhs</i>
+and <i>rhs</i> both have dynamic type <tt>T</tt>, and <i>lhs</i> is a
+copy of <i>rhs</i>, then <tt>strcmp(<i>lhs</i>.what(),
+<i>rhs</i>.what()) == 0</tt>.
+</ins></p>
 <p>
-Change D.9.1.1 [auto.ptr.cons], p5:
+ ...
 </p>
 
-<blockquote>
-<pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp; a) throw();
-</pre>
+<pre>exception(const exception&amp; <ins>rhs</ins>) throw();
+exception&amp; operator=(const exception&amp; <ins>rhs</ins>) throw();</pre>
+
 <blockquote>
 <p>
-<i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
+-4- <i>Effects:</i> Copies an exception object.
 </p>
 <p>
-<i>Effects:</i> Calls <ins><tt>const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(</tt></ins><tt>a</tt><ins><tt>)</tt></ins><tt>.release()</tt>.
+<del> -5- <i>Remarks:</i> The effects of calling <tt>what()</tt> after assignment
+are implementation-defined.</del>
 </p>
 <p>
-<i>Postconditions:</i> <tt>*this</tt> holds the pointer returned from <tt>a.release()</tt>.
+<ins>-5- <i>Postcondition:</i>
+       If <tt>*this</tt>
+       and <i>rhs</i> both have dynamic type <tt>exception</tt>
+       then <tt>strcmp(what(), <i>rhs</i>.what()) == 0</tt>.</ins>
 </p>
+
 </blockquote>
+
 </blockquote>
 
-<p>
-Change D.9.1.1 [auto.ptr.cons], p10:
-</p>
-
-<blockquote>
-<pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del> a) throw();
-</pre>
-<blockquote>
-<p>
-<i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
-The expression <tt>delete get()</tt> is well formed.
-</p>
-<p>
-<i>Effects:</i> Calls <tt>reset(a.release())</tt>.
-</p>
-<p>
-<i>Returns:</i> <tt>*this</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="471"></a>471. result of what() implementation-defined</h3>
-<p><b>Section:</b> 18.8.1 [exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28  <b>Last modified:</b> 2009-07-30</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>[lib.exception] specifies the following:</p>
-<pre>    exception (const exception&amp;) throw();
-    exception&amp; operator= (const exception&amp;) throw();
-
-    -4- Effects: Copies an exception object.
-    -5- Notes: The effects of calling what() after assignment
-        are implementation-defined.
-</pre>
-
-<p>
-First, does the Note only apply to the assignment operator? If so,
-what are the effects of calling what() on a copy of an object? Is
-the returned pointer supposed to point to an identical copy of
-the NTBS returned by what() called on the original object or not?
-</p>
-
-<p>
-Second, is this Note intended to extend to all the derived classes
-in section 19? I.e., does the standard provide any guarantee for
-the effects of what() called on a copy of any of the derived class
-described in section 19?
-</p>
-
-<p>
-Finally, if the answer to the first question is no, I believe it
-constitutes a defect since throwing an exception object typically
-implies invoking the copy ctor on the object. If the answer is yes,
-then I believe the standard ought to be clarified to spell out
-exactly what the effects are on the copy (i.e., after the copy
-ctor was called).
-</p>
-
-<p><i>[Redmond: Yes, this is fuzzy.  The issue of derived classes is
-  fuzzy too.]</i></p>
-
-
-<p><i>[
-Batavia: Howard provided wording.
-]</i></p>
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Eric concerned this is unimplementable, due to nothrow guarantees.
-Suggested implementation would involve reference counting.
-</p>
-<p>
-Is the implied reference counting subtle enough to call out a note on
-implementation? Probably not.
-</p>
-<p>
-If reference counting required, could we tighten specification further
-to require same pointer value? Probably an overspecification, especially
-if exception classes defer evalutation of final string to calls to
-what().
-</p>
-<p>
-Remember issue moved open and not resolved at Batavia, but cannot
-remember who objected to canvas a disenting opinion - please speak up if
-you disagree while reading these minutes!
-</p>
-<p>
-Move to Ready as we are accepting words unmodified.
-</p>
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-The issue was pulled from Ready.  It needs to make clear that only homogenous copying
-is intended to be supported, not coping from a derived to a base.
-</blockquote>
-
-<p><i>[
-Batavia (2009-05):
-]</i></p>
-
-<blockquote>
-<p>
-Howard supplied the following replacement wording
-for paragraph 7 of the proposed resolution:
-</p>
-<blockquote>
-<ins>-7- <i>Postcondition:</i> <tt>what()</tt> shall return the same NTBS
-  as would be obtained by using <tt>static_cast</tt>
-  to cast the rhs to the same types as the lhs
-  and then calling <tt>what()</tt> on that possibly sliced object.</ins>
-</blockquote>
-<p>
-Pete asks what "the same NTBS" means.
-</p>
-</blockquote>
-
-<p><i>[
-2009-07-30 Niels adds:
-]</i></p>
-
-
-<blockquote>
-Further discussion in the thread starting with c++std-lib-24512.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change 18.8.1 [exception] to:
-</p>
-
-<blockquote>
-<pre>exception(const exception&amp; <ins><i>e</i></ins>) throw();
-exception&amp; operator=(const exception&amp; <ins><i>e</i></ins>) throw();</pre>
-<blockquote>
-<p>
--4- <i>Effects:</i> Copies an exception object.
-</p>
-<p>
-<del> -5- <i>Remarks:</i> The effects of calling what() after assignment are implementation-defined.</del>
-</p>
-<p>
-<ins>-5- <i>Throws:</i> Nothing.  This also applies
-to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
-</p>
-<p>
-<ins>-7- <i>Postcondition:</i> <tt>strcmp(what(), <i>e</i>.what()) == 0</tt>.  This also applies
-to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
-</p>
-
-</blockquote>
-</blockquote>
 
 
 
 
 <hr>
 <h3><a name="473"></a>473. underspecified ctype calls</h3>
-<p><b>Section:</b> 22.4.1.1 [locale.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-07-01  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Section:</b> 22.4.1.1 [locale.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-07-01  <b>Last modified:</b> 2009-10-21</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 Most ctype member functions come in two forms: one that operates
@@ -3305,6 +2762,15 @@ provide wording.</p>
 ]</i></p>
 
 
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
+
+<blockquote>
+Move to Ready.
+</blockquote>
+
 
 
 <p><b>Proposed resolution:</b></p>
@@ -3319,91 +2785,22 @@ virtual function.
 
 
 
-
-
-<hr>
-<h3><a name="484"></a>484. Convertible to T</h3>
-<p><b>Section:</b> 24.2.2 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-09-16  <b>Last modified:</b> 2009-07-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>From comp.std.c++:</p>
-
+<p><b>Rationale:</b></p>
 <p>
-I note that given an input iterator a for type T, 
-then *a only has to be "convertable to T", not actually of type T.
+We are explicitly not addressing bullet
+item #2, thus giving implementors more latitude. Users will have to
+override both virtual functions, not just one.
 </p>
 
-<p>Firstly, I can't seem to find an exact definition of "convertable to T". 
-While I assume it is the obvious definition (an implicit conversion), I 
-can't find an exact definition. Is there one?</p>
-
-<p>Slightly more worryingly, there doesn't seem to be any restriction on 
-the this type, other than it is "convertable to T". Consider two input 
-iterators a and b. I would personally assume that most people would 
-expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that 
-the standard requires that, and that whatever type *a is (call it U) 
-could have == defined on it with totally different symantics and still 
-be a valid inputer iterator.</p>
-
-<p>Is this a correct reading? When using input iterators should I write 
-T(*a) all over the place to be sure that the object i'm using is the 
-class I expect?</p>
-
-<p>This is especially a nuisance for operations that are defined to be
-  "convertible to bool".  (This is probably allowed so that
-  implementations could return say an int and avoid an unnessary
-  conversion. However all implementations I have seen simply return a
-  bool anyway.  Typical implemtations of STL algorithms just write
-  things like <tt>while(a!=b &amp;&amp; *a!=0)</tt>.  But strictly
-  speaking, there are lots of types that are convertible to T but
-  that also overload the appropriate operators so this doesn't behave
-  as expected.</p>
-
-<p>If we want to make code like this legal (which most people seem to
-  expect), then we'll need to tighten up what we mean by "convertible
-  to T".</p>
-
-<p><i>[Lillehammer: The first part is NAD, since "convertible" is
- well-defined in core. The second part is basically about pathological
- overloads. It's a minor problem but a real one. So leave open for
- now, hope we solve it as part of iterator redesign.]</i></p>
-
-
-<p><i>[
-2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p><i>[
-San Francisco:
-]</i></p>
-
-
-<blockquote>
-Solved by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2758.pdf">N2758</a>.
-</blockquote>
-
-
-
-
 
 
 
 <hr>
 <h3><a name="485"></a>485. output iterator insufficiently constrained</h3>
-<p><b>Section:</b> 24.2.3 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-10-13  <b>Last modified:</b> 2009-07-21</p>
+<p><b>Section:</b> 24.2.2 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-10-13  <b>Last modified:</b> 2009-10-26</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 The note on 24.1.2 Output iterators insufficiently limits what can be
@@ -3446,16 +2843,34 @@ Bill provided wording according to consensus.
 </blockquote>
 
 <p><i>[
-2009-07-21 Alsidair requests change from Review to Open.  See thread starting
+2009-07-21 Alisdair requests change from Review to Open.  See thread starting
 with c++std-lib-24459 for discussion.
 ]</i></p>
 
 
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
+
+<blockquote>
+Modified wording.  Set to Review.
+</blockquote>
+
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
+
+<blockquote>
+Move to Ready after looking at again in a larger group in Santa Cruz.
+</blockquote>
+
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change Table 101 &#8212; Output iterator requirements in 24.2.3 [output.iterators]:
+Change Table 101 &#8212; Output iterator requirements in 24.2.2 [output.iterators]:
 </p>
 <blockquote>
 <table border="1">
@@ -3499,62 +2914,69 @@ Change Table 101 &#8212; Output iterator requirements in 24.2.3 [output.iterator
 </tr>
 
 <tr>
-<td><del>
+<td>
 <tt>*r = o</tt>
-</del></td>
-<td><del>
+</td>
+<td>
 result is not used
-</del></td>
+</td>
 <td>
 &nbsp;
 </td>
 <td>
-&nbsp;
+<ins>
+Post: <tt>r</tt> is not required to be dereferenceable.  <tt>r</tt> is incrementable.
+</ins>
 </td>
 </tr>
 
 <tr>
-<td><del>
+<td>
 <tt>++r</tt>
-</del></td>
-<td><del>
+</td>
+<td>
 <tt>X&amp;</tt>
-</del></td>
+</td>
 <td>
 &nbsp;
 </td>
-<td><del>
+<td>
 <tt>&amp;r == &amp;++r</tt>
-</del></td>
+<ins>
+Post: <tt>r</tt> is dereferenceable, unless otherwise specified.  <tt>r</tt> is not required to be incrementable.
+</ins>
+</td>
 </tr>
 
 <tr>
-<td><del>
+<td>
 <tt>r++</tt>
-</del></td>
-<td><del>
+</td>
+<td>
 convertible to <tt>const X&amp;</tt>
-</del></td>
-<td><del>
+</td>
+<td>
 <tt>{X tmp = r;<br>++r;<br>return tmp;}</tt>
-</del></td>
+</td>
 <td>
-&nbsp;
+<ins>
+Post: <tt>r</tt> is dereferenceable, unless otherwise specified. <tt>r</tt> is not required to be incrementable.
+</ins>
 </td>
 </tr>
 
 <tr>
 <td>
-<tt>*r++ = o<br>*r = o, ++r<br>*r = o, r++</tt>
+<tt>*r++ = o;</tt>
 </td>
 <td>
-result is not <del>used</del> <ins>usable</ins>
+result is not used
 </td>
 <td>
 &nbsp;
 </td>
 <td>
-<ins>Note: only these forms permitted</ins>
+
 </td>
 </tr>
 
@@ -3566,258 +2988,20 @@ result is not <del>used</del> <ins>usable</ins>
 
 
 <hr>
-<h3><a name="498"></a>498. Requirements for partition() and stable_partition() too strong</h3>
-<p><b>Section:</b> 25.4.13 [alg.partitions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Sean Parent, Joe Gottman <b>Opened:</b> 2005-05-04  <b>Last modified:</b> 2009-07-15</p>
+<h3><a name="539"></a>539. partial_sum and adjacent_difference should mention requirements</h3>
+<p><b>Section:</b> 26.7.3 [partial.sum] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Marc Schoolderman <b>Opened:</b> 2006-02-06  <b>Last modified:</b> 2009-10-24</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Problem:
-The iterator requirements for partition() and stable_partition() [25.2.12]
-are listed as BidirectionalIterator, however, there are efficient algorithms
-for these functions that only require ForwardIterator that have been known
-since before the standard existed. The SGI implementation includes these (see
-<a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a>
-and
-<a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>).
+There are some problems in the definition of partial_sum and
+adjacent_difference in 26.4 [lib.numeric.ops]
 </p>
 
-<p><i>[
-2009-04-30 Alisdair adds:
-]</i></p>
-
-
-<blockquote>
-<p>
-Now we have concepts this is easier to express!
-</p>
-<p>
-Proposed resolution:
-</p>
 <p>
-Add the following signature to:
-</p>
-<p>
-Header <tt>&lt;algorithm&gt;</tt> synopsis 25.2 [algorithms.syn]<br>
-p3 Partitions 25.4.13 [alg.partitions]
-</p>
-<blockquote><pre> template&lt;ForwardIterator Iter, Predicate&lt;auto, Iter::value_type&gt; Pred&gt;
-   requires ShuffleIterator&lt;Iter&gt;
-         &amp;&amp; CopyConstructible&lt;Pred&gt;
-   Iter partition(Iter first, Iter last, Pred pred);
-</pre></blockquote>
-
-<p>
-Update p3 Partitions 25.4.13 [alg.partitions]:
-</p>
-
-<blockquote>
-<p>
-<i>Complexity:</i> <del>At most <tt>(last - first)/2</tt> swaps. Exactly <tt>last - first</tt>
-applications of the predicate
-are done.</del>
-<ins>
-If <tt>Iter</tt> satisfies <tt>BidirectionalIterator</tt>, at most <tt>(last -
-first)/2</tt> swaps. Exactly <tt>last - first</tt> applications of the predicate
-are done.
-</ins>
-</p>
-<p><ins>
-If <tt>Iter</tt> merely satisfied <tt>ForwardIterator</tt> at most <tt>(last - first)</tt> swaps
-are done. Exactly <tt>(last - first)</tt> applications of the predicate are done.
-</ins></p>
-</blockquote>
-
-<p>
-[Editorial note: I looked for existing precedent in how we might call out
-distinct overloads overloads from a set of constrained templates, but there
-is not much existing practice to lean on.   advance/distance were the only
-algorithms I could find, and that wording is no clearer.]
-</p>
-
-</blockquote>
-
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
-
-
-<blockquote>
-<p>
-Hinnant: if you want to partition your std::forward_list, you'll need
-partition() to accept ForwardIterators.
-</p>
-<p>
-No objection to Ready.
-</p>
-<p>
-Move to Ready.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 25.2.12 from </p>
-<blockquote><pre>template&lt;class BidirectionalIterator, class Predicate&gt; 
-BidirectionalIterator partition(BidirectionalIterato r first, 
-                                BidirectionalIterator last, 
-                                Predicate pred); 
-</pre></blockquote>
-<p>to </p>
-<blockquote><pre>template&lt;class ForwardIterator, class Predicate&gt; 
-ForwardIterator partition(ForwardIterator first, 
-                          ForwardIterator last, 
-                          Predicate pred); 
-</pre></blockquote>
-<p>Change the complexity from </p>
-
-<blockquote><p>
-At most (last - first)/2 swaps are done. Exactly (last - first) 
-applications of the predicate are done. 
-</p></blockquote>
-
-<p>to </p>
-
-<blockquote><p>
-If ForwardIterator is a bidirectional_iterator, at most (last - first)/2 
-swaps are done; otherwise at most (last - first) swaps are done. Exactly 
-(last - first) applications of the predicate are done. 
-</p></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-Partition is a "foundation" algorithm useful in many contexts (like sorting
-as just one example) - my motivation for extending it to include forward
-iterators is foward_list - without this extension you can't partition an foward_list
-(without writing your own partition). Holes like this in the standard
-library weaken the argument for generic programming (ideally I'd be able
-to provide a library that would refine std::partition() to other concepts
-without fear of conflicting with other libraries doing the same - but
-that is a digression). I consider the fact that partition isn't defined
-to work for ForwardIterator a minor embarrassment.
-</p>
-
-<p><i>[Mont Tremblant: Moved to Open, request motivation and use cases
-by next meeting. Sean provided further rationale by post-meeting
-mailing.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="532"></a>532. Tuple comparison</h3>
-<p><b>Section:</b> 20.5.2.5 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> David Abrahams <b>Opened:</b> 2005-11-29  <b>Last modified:</b> 2009-07-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.rel">issues</a> in [tuple.rel].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a></p>
-<p><b>Discussion:</b></p>
-<p>
-Where possible, tuple comparison operators &lt;,&lt;=,=&gt;, and &gt; ought to be
-defined in terms of std::less rather than operator&lt;, in order to
-support comparison of tuples of pointers.  
-</p>
-
-<p><i>[
-2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-change 6.1.3.5/5 from:
-</p>
-
-<blockquote><p>
-  Returns: The result of a lexicographical comparison between t and
-  u. The result is defined as: (bool)(get&lt;0&gt;(t) &lt; get&lt;0&gt;(u)) ||
-  (!(bool)(get&lt;0&gt;(u) &lt; get&lt;0&gt;(t)) &amp;&amp; ttail &lt; utail), where rtail for
-  some tuple r is a tuple containing all but the first element of
-  r. For any two zero-length tuples e and f, e &lt; f returns false.
-</p></blockquote>
-
-<p>
-to:
-</p>
-
-<blockquote>
-<p>
-  Returns: The result of a lexicographical comparison between t and
-  u. For any two zero-length tuples e and f, e &lt; f returns false.
-  Otherwise, the result is defined as: cmp( get&lt;0&gt;(t), get&lt;0&gt;(u)) ||
-  (!cmp(get&lt;0&gt;(u), get&lt;0&gt;(t)) &amp;&amp; ttail &lt; utail), where rtail for some
-  tuple r is a tuple containing all but the first element of r, and
-  cmp(x,y) is an unspecified function template defined as follows.
-</p>
-<p>
-  Where T is the type of x and U is the type of y:
-</p>
-
-<p>
-     if T and U are pointer types and T is convertible to U, returns
-     less&lt;U&gt;()(x,y)
-</p>
-
-<p>
-     otherwise, if T and U are pointer types, returns less&lt;T&gt;()(x,y)
-</p>
-
-<p>
-     otherwise, returns (bool)(x &lt; y)
-</p>
-</blockquote>
-
-<p><i>[
-Berlin: This issue is much bigger than just tuple (pair, containers,
-algorithms). Dietmar will survey and work up proposed wording.
-]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-Recommend NAD.  This will be fixed with the next revision of concepts.
-</p>
-
-<p><i>[
-San Francisco:
-]</i></p>
-
-
-<blockquote>
-Solved by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="539"></a>539. partial_sum and adjacent_difference should mention requirements</h3>
-<p><b>Section:</b> 26.7.3 [partial.sum] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Marc Schoolderman <b>Opened:</b> 2006-02-06  <b>Last modified:</b> 2009-07-30</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-There are some problems in the definition of partial_sum and
-adjacent_difference in 26.4 [lib.numeric.ops]
-</p>
-
-<p>
-Unlike <tt>accumulate</tt> and <tt>inner_product</tt>, these functions are not
-parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply
-specifies the effects clause as;
+Unlike <tt>accumulate</tt> and <tt>inner_product</tt>, these functions are not
+parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply
+specifies the effects clause as;
 </p>
 
 <blockquote><p>
@@ -4020,6 +3204,16 @@ volunteered to correct the wording.
 ]</i></p>
 
 
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
+
+<blockquote>
+Move to Ready.
+</blockquote>
+
+
 
 <p><b>Proposed resolution:</b></p>
 
@@ -4159,10 +3353,10 @@ of <del><tt>binary_op</tt></del><ins>the binary operation</ins>.
 
 <hr>
 <h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3>
-<p><b>Section:</b> 25.5 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-05  <b>Last modified:</b> 2009-07-28</p>
+<p><b>Section:</b> 25.4 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-05  <b>Last modified:</b> 2009-10-25</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.sorting">issues</a> in [alg.sorting].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 In 25, p8 we allow BinaryPredicates to return a type that's convertible
@@ -4193,13 +3387,43 @@ is here:
 </p></blockquote>
 
 <p><i>[
+Portland:  Jack to define "convertible to bool" such that short circuiting isn't
+destroyed.
+]</i></p>
+
+
+<p><i>[
 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
 ]</i></p>
 
 
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
 
-<p><b>Proposed resolution:</b></p>
+<blockquote>
+Move to Review once wording received. Stefanus to send proposed wording.
+</blockquote>
+
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
+
+<blockquote>
+Move to Review once wording received. Stefanus to send proposed wording.
+</blockquote>
+
+<p><i>[
+2009-10-24 Stefanus supplied wording.
+]</i></p>
+
+
+<blockquote>
+Move to Review once wording received. Stefanus to send proposed wording.
+Current proposed wording proposed here:
+<blockquote>
 <p>
 I think we could fix this by rewording 25.3, p2 to read somthing like:
 </p>
@@ -4213,12 +3437,25 @@ if the first argument of the call</ins> is less than the second, and
 algorithms assuming an ordering relation. It is assumed that <tt><i>comp</i></tt>
 will not apply any non-constant function through the dereferenced iterator.
 </p></blockquote>
+</blockquote>
+</blockquote>
 
 
-<p><i>[
-Portland:  Jack to define "convertible to bool" such that short circuiting isn't
-destroyed.
-]</i></p>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 25.4 [alg.sorting] p2:
+</p>
+<blockquote>
+<tt>Compare</tt> is used as a function object<ins>. The return value of
+the function call operator applied to an object of type Compare, when
+converted to type bool, yields true if the first argument of the
+call</ins> <del>which returns <tt>true</tt> if the first argument</del>
+is less than the second, and <tt>false</tt> otherwise. <tt>Compare
+comp</tt> is used throughout for algorithms assuming an ordering
+relation. It is assumed that <tt>comp</tt> will not apply any
+non-constant function through the dereferenced iterator.
+</blockquote>
 
 
 <p><b>Rationale:</b></p>
@@ -4238,567 +3475,52 @@ Solved by
 
 
 <hr>
-<h3><a name="564"></a>564. stringbuf seekpos underspecified</h3>
-<p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23  <b>Last modified:</b> 2009-07-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="594"></a>594. Disadvantages of defining Swappable in terms of CopyConstructible and Assignable</h3>
+<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2006-11-02  <b>Last modified:</b> 2009-11-08</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The   effects  of  the   <code>seekpos()</code>  member   function  of
-<code>basic_stringbuf</code>  simply say  that the  function positions
-the  input and/or  output  sequences  but fail  to  spell out  exactly
-how. This is in contrast  to the detail in which <code>seekoff()</code>
-is described.
+It seems undesirable to define the Swappable requirement in terms of
+CopyConstructible and Assignable requirements. And likewise, once the
+MoveConstructible and MoveAssignable requirements (N1860) have made it
+into the Working Draft, it seems undesirable to define the Swappable
+requirement in terms of those requirements. Instead, it appears
+preferable to have the Swappable requirement defined exclusively in
+terms of the existence of an appropriate swap function.
 </p>
-
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
-
-
-<blockquote>
-Move to Ready.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-        <p>
-
-Change 27.7.1.3, p13 to read:
-
-        </p>
-<blockquote>
 <p>
--13- <i>Effects:</i> <ins>Equivalent to <tt>seekoff(off_type(<i>sp</i>), ios_base::beg,
-<i>which</i>)</tt>.</ins> <del>Alters the stream position within the controlled sequences,
-if possible, to correspond to the stream position stored in <tt><i>sp</i></tt>
-(as described below).</del>
+Section 20.1.4 [lib.swappable] of the current Working Draft (N2009)
+says:
 </p>
+<blockquote><p>
+The Swappable requirement is met by satisfying one or more of the
+following conditions:</p>
 <ul>
-<li><del>If <tt>(<i>which</i> &amp; ios_base::in) != 0</tt>, positions the input sequence.</del></li>
-<li><del>If <tt>(<i>which</i> &amp; ios_base::out) != 0</tt>, positions the output sequence.</del></li>
-<li><del>If <tt><i>sp</i></tt> is an invalid stream position, or if the function
-positions neither sequence, the positioning operation fails. If <tt><i>sp</i></tt>
-has not been obtained by a previous successful call to one of the positioning
-functions (<tt>seekoff</tt>, <tt>seekpos</tt>, <tt>tellg</tt>, <tt>tellp</tt>)
-the effect is undefined.</del></li>
+<li>
+T is Swappable if T satisfies the CopyConstructible requirements
+(20.1.3) and the Assignable requirements (23.1);
+</li>
+<li>
+T is Swappable if a namespace scope function named swap exists in the
+same namespace as the definition of T, such that the expression
+swap(t,u) is valid and has the semantics described in Table 33.
+</li>
 </ul>
 </blockquote>
-
-
-<p><i>[
-Kona (2007): A <tt>pos_type</tt> is a position in a stream by
-definition, so there is no ambiguity as to what it means. Proposed
-Disposition: NAD
-]</i></p>
-
-
-<p><i>[
-Post-Kona Martin adds:
-I'm afraid I disagree
-with the Kona '07 rationale for marking it NAD. The only text
-that describes precisely what it means to position the input
-or output sequence is in <tt>seekoff()</tt>. The <tt>seekpos()</tt> Effects
-clause is inadequate in comparison and the proposed resolution
-plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="565"></a>565. xsputn inefficient</h3>
-<p><b>Section:</b> 27.6.2.4.5 [streambuf.virt.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23  <b>Last modified:</b> 2009-07-15</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-        <p>
-
-<tt>streambuf::xsputn()</tt>  is  specified  to  have  the  effect  of
-"writing up to  <tt>n</tt> characters to the output  sequence as if by
-repeated calls to <tt>sputc(c)</tt>."
-
-        </p>
-        <p>
-
-Since  <tt>sputc()</tt> is required  to call  <tt>overflow()</tt> when
-<tt>(pptr()    ==   epptr())</tt>    is   true,    strictly   speaking
-<tt>xsputn()</tt>  should do  the same.   However, doing  so  would be
-suboptimal in  some interesting cases,  such as in unbuffered  mode or
-when the buffer is <tt>basic_stringbuf</tt>.
-
-        </p>
-        <p>
-
-Assuming  calling <tt>overflow()</tt>  is  not really  intended to  be
-required  and the  wording is  simply  meant to  describe the  general
-effect of appending to the end  of the sequence it would be worthwhile
-to  mention in  <tt>xsputn()</tt> that  the function  is  not actually
-required to cause a call to <tt>overflow()</tt>.
-
-        </p>
-
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
-
-
-<blockquote>
-Move to Ready.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-        <p>
-
-Add the following sentence  to the <tt>xsputn()</tt> Effects clause in
-27.5.2.4.5, p1 (N1804):
-
-        </p>
-        <blockquote>    
-            <p>
--1- <i>Effects:</i> Writes up to <tt><i>n</i></tt> characters to the output
-sequence as if by repeated calls to <tt>sputc(<i>c</i>)</tt>. The characters 
-written are obtained from successive elements of the array whose first element
-is designated by <tt><i>s</i></tt>. Writing stops when either <tt><i>n</i></tt>
-characters have been written or a call to <tt>sputc(<i>c</i>)</tt> would return
-<tt>traits::eof()</tt>. <ins>It is  uspecified whether the function  calls
-<tt>overflow()</tt> when <tt>(pptr() ==  epptr())</tt> becomes true or whether
-it achieves the same effects by other means.</ins>
-            </p>
-        </blockquote>    
-        <p>
-
-In addition,  I suggest to  add a footnote  to this function  with the
-same text as Footnote 292 to  make it extra clear that derived classes
-are permitted to override <tt>xsputn()</tt> for efficiency.
-
-        </p>
-
-
-<p><i>[
-Kona (2007): We want to permit a <tt>streambuf</tt> that streams output directly
-to a device without making calls to <tt>sputc</tt> or <tt>overflow</tt>. We believe that
-has always been the intention of the committee. We believe that the
-proposed wording doesn't accomplish that. Proposed Disposition: Open
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="580"></a>580. unused allocator members</h3>
-<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-14  <b>Last modified:</b> 2009-07-15</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a></p>
-<p><b>Discussion:</b></p>
-        <p>
-
-C++ Standard Library  templates that take an allocator  as an argument
-are    required    to    call    the    <code>allocate()</code>    and
-<code>deallocate()</code>  members of the  allocator object  to obtain
-storage.  However, they do not appear to be required to call any other
-allocator      members      such     as      <code>construct()</code>,
-<code>destroy()</code>,           <code>address()</code>,          and
-<code>max_size()</code>.  This makes these allocator members less than
-useful in portable programs.
-
-        </p>
-        <p>
-
-It's unclear to me whether the absence of the requirement to use these
-allocator  members  is  an  unintentional  omission  or  a  deliberate
-choice. However,  since the functions exist in  the standard allocator
-and  since  they are  required  to  be  provided by  any  user-defined
-allocator I  believe the standard  ought to be clarified  to explictly
-specify  whether programs  should or  should not  be able  to  rely on
-standard containers calling the functions.
-
-        </p>
-        <p>
-
-I  propose  that all  containers  be required  to  make  use of  these
-functions.
-
-        </p>
-<p><i>[
-Batavia:  We support this resolution.  Martin to provide wording.
-]</i></p>
-
-<p><i>[
-pre-Oxford:  Martin provided wording.
-]</i></p>
-
-
-<p><i>[
-2009-04-28 Pablo adds:
-]</i></p>
-
-
-<blockquote>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2554.pdf">N2554</a>
-(scoped allocators),
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>
-(allocator concepts), and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2810.pdf">N2810</a>
-(allocator defects), address all of these points EXCEPT <tt>max_size()</tt>.
-So, I would add a note to that affect and re-class the defect as belonging
-to section 23.2.1 [container.requirements.general].
-</blockquote>
-
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
-
-
-<blockquote>
-The comment in the description of this issue that this "would be"
-rendered editorial by the adoption of N2257 is confusing. It appears
-that N2257 was never adopted.
-</blockquote>
-
-
-
-    <p><b>Proposed resolution:</b></p>
-       <p>
-
-Specifically, I propose to change 23.2 [container.requirements],
-p9 as follows:
-
-       </p>
-           <blockquote>
-<p>
--9- Copy constructors  for all container types defined  in this clause
-<ins>that   are  parametrized  on   <code>Allocator</code></ins>  copy
-<del>an</del><ins>the</ins>  allocator argument from  their respective
-first parameters.
-
-All other  constructors for  these container types  take a<del>n</del>
-<ins>const</ins>  <code>Allocator&amp;</code>  argument  (20.1.6),  an
-allocator whose <code>value_type</code> is the same as the container's
-<code>value_type</code>.
-
-A copy of this  argument <del>is</del><ins>shall be</ins> used for any
-memory  allocation <ins> and  deallocation</ins> performed<del>,</del>
-by these  constructors and by all  member functions<del>,</del> during
-the  lifetime  of each  container  object.   <ins>Allocation shall  be
-performed  "as  if"  by  calling  the  <code>allocate()</code>  member
-function on  a copy  of the allocator  object of the  appropriate type
-<sup>New  Footnote)</sup>,   and  deallocation  "as   if"  by  calling
-<code>deallocate()</code> on  a copy of  the same allocator  object of
-the corresponding type.</ins>
-
-<ins>A  copy of  this argument  shall also  be used  to  construct and
-destroy objects whose lifetime  is managed by the container, including
-but not  limited to those of  the container's <code>value_type</code>,
-and  to  obtain  their  address.   All  objects  residing  in  storage
-allocated by a  container's allocator shall be constructed  "as if" by
-calling the <code>construct()</code> member  function on a copy of the
-allocator object of  the appropriate type.  The same  objects shall be
-destroyed "as if"  by calling <code>destroy()</code> on a  copy of the
-same allocator object  of the same type.  The  address of such objects
-shall be obtained "as if" by calling the <code>address()</code> member
-function  on  a  copy  of  the allocator  object  of  the  appropriate
-type.</ins>
-
-<ins>Finally, a copy  of this argument shall be  used by its container
-object to determine  the maximum number of objects  of the container's
-<code>value_type</code> the container may  store at the same time. The
-container  member function <code>max_size()</code> obtains  this number
-from      the      value      returned      by     a      call      to
-<code>get_allocator().max_size()</code>.</ins>
-
-In   all  container   types  defined   in  this   clause <ins>that  are
-parametrized     on    <code>Allocator</code></ins>,     the    member
-<code>get_allocator()</code>     returns     a     copy     of     the
-<code>Allocator</code>     object     used     to    construct     the
-container.<sup>258)</sup>
-</p>
-<p>
-New Footnote: This type  may be different from <code>Allocator</code>:
-it     may    be     derived    from     <code>Allocator</code>    via
-<code>Allocator::rebind&lt;U&gt;::other</code>   for  the  appropriate
-type <code>U</code>.
-</p>
-           </blockquote>
-       <p>
-
-The proposed wording seems cumbersome but I couldn't think of a better
-way   to  describe   the   requirement  that   containers  use   their
-<code>Allocator</code>  to manage  only objects  (regardless  of their
-type)  that  persist  over  their  lifetimes  and  not,  for  example,
-temporaries  created on the  stack. That  is, containers  shouldn't be
-required  to  call  <code>Allocator::construct(Allocator::allocate(1),
-elem)</code>  just to  construct a  temporary copy  of an  element, or
-<code>Allocator::destroy(Allocator::address(temp),     1)</code>    to
-destroy temporaries.
-
-       </p>
-
-
-<p><i>[
-Howard: This same paragraph will need some work to accommodate <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
-]</i></p>
-
-
-<p><i>[
-post Oxford:  This would be rendered NAD Editorial by acceptance of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="588"></a>588. requirements on zero sized tr1::arrays and other details</h3>
-<p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
- <b>Submitter:</b> Gennaro Prota <b>Opened:</b> 2006-07-18  <b>Last modified:</b> 2009-07-15</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The wording used for section 23.2.1 [lib.array] seems to be subtly
-ambiguous about zero sized arrays (N==0). Specifically:
-</p>
-<p>
-* "An instance of array&lt;T, N&gt; stores N elements of type T, so that
-[...]"
-</p>
-<p>
-Does this imply that a zero sized array object stores 0 elements, i.e.
-that it cannot store any element of type T? The next point clarifies
-the rationale behind this question, basically how to implement begin()
-and end():
-</p>
-<p>
-* 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==
-end() == unique value."
-</p>
-<p>
-What does "unique" mean in this context? Let's consider the following
-possible implementations, all relying on a partial specialization:
-</p>
-<blockquote><pre>a)
-    template&lt; typename T &gt;
-    class array&lt; T, 0 &gt; {
-    
-        ....
-
-        iterator begin()
-        { return iterator( reinterpret_cast&lt; T * &gt;( this ) ); }
-        ....
-
-    };
-</pre></blockquote>
-<p>
-This has been used in boost, probably intending that the return value
-had to be unique to the specific array object and that array couldn't
-store any T. Note that, besides relying on a reinterpret_cast, has
-(more than potential) alignment problems.
-</p>
-<blockquote><pre>b)
-    template&lt; typename T &gt;
-    class array&lt; T, 0 &gt; {
-    
-        T t;
-
-        iterator begin()
-        { return iterator( &amp;t ); }
-        ....
-
-    };
-</pre></blockquote>
-<p>
-This provides a value which is unique to the object and to the type of
-the array, but requires storing a T. Also, it would allow the user to
-mistakenly provide an initializer list with one element.
-</p>
-<p>
-A slight variant could be returning *the* null pointer of type T
-</p>
-<blockquote><pre>    return static_cast&lt;T*&gt;(0);
-</pre></blockquote>
-<p>
-In this case the value would be unique to the type array&lt;T, 0&gt; but not
-to the objects (all objects of type array&lt;T, 0&gt; with the same value
-for T would yield the same pointer value).
-</p>
-<p>
-Furthermore this is inconsistent with what the standard requires from
-allocation functions (see library issue 9).
-</p>
-<p>
-c) same as above but with t being a static data member; again, the
-value would be unique to the type, not to the object.
-</p>
-<p>
-d) to avoid storing a T *directly* while disallowing the possibility
-to use a one-element initializer list a non-aggregate nested class
-could be defined
-</p>
-<blockquote><pre>    struct holder { holder() {} T t; } h;
-</pre></blockquote>
-<p>
-and then begin be defined as
-</p>
-<blockquote><pre> iterator begin() { return &amp;h.t; }
-</pre></blockquote>
-<p>
-But then, it's arguable whether the array stores a T or not.
-Indirectly it does.
-</p>
-<p>
------------------------------------------------------
-</p>
-<p>
-Now, on different issues:
-</p>
-<p>
-* what's the effect of calling assign(T&amp;) on a zero-sized array? There
-seems to be only mention of front() and back(), in 23.2.1 [lib.array]
-p4 (I would also suggest to move that bullet to section 23.2.1.5
-[lib.array.zero], for locality of reference)
-</p>
-<p>
-* (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit
-inconsistent with that of other sequences: that's not a problem in
-itself, but compare it for instance with "A vector is a kind of
-sequence that supports random access iterators"; though the intent is
-obvious one might argue that the wording used for arrays doesn't tell
-what an array is, and relies on the reader to infer that it is what
-the &lt;array&gt; header defines.
-</p>
-<p>
-* it would be desiderable to have a static const data member of type
-std::size_t, with value N, for usage as integral constant expression
-</p>
-<p>
-* section 23.1 [lib.container.requirements] seem not to consider
-fixed-size containers at all, as it says: "[containers] control
-allocation and deallocation of these objects [the contained objects]
-through constructors, destructors, *insert and erase* operations"
-</p>
-<p>
-* max_size() isn't specified: the result is obvious but, technically,
-it relies on table 80: "size() of the largest possible container"
-which, again, doesn't seem to consider fixed size containers
-</p>
-
-<p><i>[
-2009-05-29 Daniel adds:
-]</i></p>
-
-
-<blockquote>
-<ol type="a">
-<li>
-<p>
-star bullet 1 ("what's the effect of calling <tt>assign(T&amp;)</tt> on a
-zero-sized array?[..]");
-</p>
-<blockquote>
-<tt>assign</tt> has been renamed to <tt>fill</tt> and the semantic of <tt>fill</tt> is now
-defined in terms of
-the free algorithm <tt>fill_n</tt>, which is well-defined for this situation.
-</blockquote>
-</li>
-<li>
-<p>
-star bullet 3 ("it would be desiderable to have a static const data
-member..."):
-</p>
-<blockquote>
-It seems that <tt>tuple_size&lt;array&lt;T, N&gt; &gt;::value</tt> as of 23.3.1.7 [array.tuple] does
-provide this functionality now.
-</blockquote>
-</li>
-</ol>
-</blockquote>
-
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
-
-
-<blockquote>
-<p>
-Alisdair to address by the next meeting, or declare NAD.
-</p>
-<p>
-Moved to Tentatively NAD.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-<p><i>[
-Kona (2007): requirements on zero sized <tt>tr1::array</tt>s and other details
-Issue 617: <tt>std::array</tt> is a sequence that doesn't satisfy the sequence
-requirements? Alisdair will prepare a paper. Proposed Disposition: Open
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="594"></a>594. Disadvantages of defining Swappable in terms of CopyConstructible and Assignable</h3>
-<p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2006-11-02  <b>Last modified:</b> 2009-07-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-It seems undesirable to define the Swappable requirement in terms of
-CopyConstructible and Assignable requirements. And likewise, once the
-MoveConstructible and MoveAssignable requirements (N1860) have made it
-into the Working Draft, it seems undesirable to define the Swappable
-requirement in terms of those requirements. Instead, it appears
-preferable to have the Swappable requirement defined exclusively in
-terms of the existence of an appropriate swap function.
-</p>
 <p>
-Section 20.1.4 [lib.swappable] of the current Working Draft (N2009)
-says:
-</p>
-<blockquote><p>
-The Swappable requirement is met by satisfying one or more of the
-following conditions:</p>
-<ul>
-<li>
-T is Swappable if T satisfies the CopyConstructible requirements
-(20.1.3) and the Assignable requirements (23.1);
-</li>
-<li>
-T is Swappable if a namespace scope function named swap exists in the
-same namespace as the definition of T, such that the expression
-swap(t,u) is valid and has the semantics described in Table 33.
-</li>
-</ul>
-</blockquote>
 I can think of three disadvantages of this definition:
+</p>
 <ol>
 <li>
+<p>
 If a client's type T satisfies the first condition (T is both
 CopyConstructible and Assignable), the client cannot stop T from
 satisfying the Swappable requirement without stopping T from
 satisfying the first condition.
+</p>
 <p>
 A client might want to stop T from satisfying the Swappable
 requirement, because swapping by means of copy construction and
@@ -4815,8 +3537,10 @@ stopping T from satisfying the Swappable requirement.
 </p>
 </li>
 <li>
+<p>
 A client's type T that does not satisfy the first condition can not be
 made Swappable by providing a specialization of std::swap for T.
+</p>
 <p>
 While I'm aware about the fact that people have mixed feelings about
 providing a specialization of std::swap, it is well-defined to do so.
@@ -4827,11 +3551,13 @@ effect as satisfying the Swappable requirement.
 </p>
 </li>
 <li>
+<p>
 For a client's type T that satisfies both conditions of the Swappable
 requirement, it is not specified which of the two conditions prevails.
 After reading section 20.1.4 [lib.swappable], one might wonder whether
 objects of T will be swapped by doing copy construction and
 assignments, or by calling the swap function of T.
+</p>
 <p>
 I'm aware that the intention of the Draft is to prefer calling the
 swap function of T over doing copy construction and assignments. Still
@@ -4878,6 +3604,15 @@ Recommend NAD.  Solved by
 Moved to Open.  Waiting for non-concepts draft.
 </blockquote>
 
+<p><i>[
+2009-11-08 Howard adds:
+]</i></p>
+
+
+<blockquote>
+This issue is very closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>.
+</blockquote>
+
 
 <p><b>Proposed resolution:</b></p>
 <p>
@@ -4910,144 +3645,25 @@ within the namespace std, and has the semantics described in Table 33.
 
 
 <hr>
-<h3><a name="617"></a>617. std::array is a sequence that doesn't satisfy the sequence requirements?</h3>
-<p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
- <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-30  <b>Last modified:</b> 2009-07-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
+<h3><a name="625"></a>625. mixed up <i>Effects</i> and <i>Returns</i> clauses</h3>
+<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#895">895</a></p>
 <p><b>Discussion:</b></p>
-<p>
-The <tt>&lt;array&gt;</tt> header is given under 23.3 [sequences].
-23.3.1 [array]/paragraph 3 says:
-</p>
-<blockquote><p>
-"Unless otherwise specified, all array operations are as described in
-23.2 [container.requirements]".
-</p></blockquote>
-<p>
-However, array isn't mentioned at all in section 23.2 [container.requirements].
-In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear) 
-that std::array does not have in 23.3.1 [array].
-</p>
-<p>
-Also, Table 83 "Optional sequence operations" lists several operations that 
-std::array does have, but array isn't mentioned.
-</p>
-
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
-
-
-<blockquote>
-<p>
-The real issue seems to be different than what is described here.
-Non-normative text says that std::array is a sequence container, but
-there is disagreement about what that really means. There are two
-possible interpretations:
-</p>
-<ol>
-<li>
-a sequence container is one that satisfies all sequence container requirements
-</li>
-<li>
-a sequence container is one that satisfies some of the sequence
-container requirements. Any operation that the container supports is
-specified by one or more sequence container requirements, unless that
-operation is specifically singled out and defined alongside the
-description of the container itself.
-</li>
-</ol>
-<p>
-Move to Tentatively NAD.
-</p>
-</blockquote>
-
-<p><i>[
-2009-07-15 Loïc Joly adds:
-]</i></p>
-
-
-<blockquote>
-<p>
-The section 23.2.3 [sequence.reqmts]/1 states that array is a sequence. 23.2.3 [sequence.reqmts]/3
-introduces table 83, named Sequence container requirements. This seems
-to me to be defining the requirements for all sequences. However, array
-does not follow all of this requirements (this can be read in the array
-specific section, for the standard is currently inconsistent).
-</p>
-
-<p>
-Proposed resolution 1 (minimal change): 
-</p>
-<blockquote>
-<p>
-Say that array is a container, that in addition follows only some of the
-sequence requirements, as described in the array section:
-</p>
-
-<blockquote>
-The library provides <del>five</del> <ins>three</ins> basic kinds of sequence containers: <del><tt>array</tt></del>,
-<tt>vector</tt>, 
-<del><tt>forward_list</tt></del>, <tt>list</tt>, and <tt>deque</tt>. <ins>In addition, <tt>array</tt>
-and <tt>forward_list</tt> follows some of the requirements 
-of sequences, as described in their respective sections.</ins>
-</blockquote>
-
-</blockquote>
-
-<p>
-Proposed resolution 2 (most descriptive description, no full wording provided): 
-</p>
-<blockquote>
-Introduce the notion of a Fixed Size Sequence, with it requirement table
-that would be a subset of the current Sequence container. array would be
-the only Fixed Size Sequence (but dynarray is in the queue for TR2).
-Sequence requirements would now be requirements in addition to Fixed
-Size Sequence requirements (it is currently in addition to container).
-</blockquote>
-</blockquote>
-
-<p><i>[
-2009-07 Frankfurt:
-]</i></p>
-
-
-<blockquote>
-Move to NAD Editorial
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="625"></a>625. mixed up <i>Effects</i> and <i>Returns</i> clauses</h3>
-<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20  <b>Last modified:</b> 2009-07-15</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#895">895</a></p>
-<p><b>Discussion:</b></p>
- <p>
-
-Many member functions of <code>basic_string</code> are overloaded,
-with some of the overloads taking a <code>string</code> argument,
-others <code>value_type*</code>, others <code>size_type</code>, and
-others still <code>iterators</code>. Often, the requirements on one of
-the overloads are expressed in the form of <i>Effects</i>,
-<i>Throws</i>, and in the Working Paper
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
-also <i>Remark</i> clauses, while those on the rest of the overloads
-via a reference to this overload and using a <i>Returns</i> clause.
+ <p>
+
+Many member functions of <code>basic_string</code> are overloaded,
+with some of the overloads taking a <code>string</code> argument,
+others <code>value_type*</code>, others <code>size_type</code>, and
+others still <code>iterators</code>. Often, the requirements on one of
+the overloads are expressed in the form of <i>Effects</i>,
+<i>Throws</i>, and in the Working Paper
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
+also <i>Remark</i> clauses, while those on the rest of the overloads
+via a reference to this overload and using a <i>Returns</i> clause.
 </p>
 
 <p>
@@ -5167,187 +3783,20 @@ is confusing, especially now that <tt>requires</tt> is a new keyword.
 Move to Tentatively NAD.
 </blockquote>
 
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="630"></a>630. arrays of valarray</h3>
-<p><b>Section:</b> 26.6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-28  <b>Last modified:</b> 2009-07-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-        <p>
-
-Section 26.2 [numeric.requirements], p1     suggests     that     a
-<code>valarray</code>  specialization on  a  type <code>T</code>  that
-satisfies  the requirements enumerated  in the  paragraph is  itself a
-valid  type   on  which  <code>valarray</code>   may  be  instantiated
-(Footnote       269        makes       this       clear).        I.e.,
-<code>valarray&lt;valarray&lt;T&gt;  &gt;</code> is  valid as  long as
-<code>T</code>   is   valid.    However,  since   implementations   of
-<code>valarray</code> are permitted to initialize storage allocated by
-the class by  invoking the default ctor of  <code>T</code> followed by
-the    copy    assignment    operator,   such    implementations    of
-<code>valarray</code>   wouldn't  work  with   (perhaps  user-defined)
-specializations of <code>valarray</code> whose assignment operator had
-undefined behavior when the size of its argument didn't match the size
-of <code>*this</code>.  By <i>"wouldn't work"</i> I mean that it would
-be  impossible  to resize  such  an array  of  arrays  by calling  the
-<code>resize()</code> member  function on it if the  function used the
-copy  assignment operator  after constructing  all elements  using the
-default  ctor (e.g.,  by invoking  <code>new  value_type[N]</code>) to
-obtain default-initialized storage) as it's permitted to do.
-
-        </p>
-        <p>
-
-Stated      more     generally,      the      problem     is      that
-<code>valarray&lt;valarray&lt;T&gt;  &gt;::resize(size_t)</code> isn't
-required or  guaranteed to have well-defined semantics  for every type
-<code>T</code>     that      satisfies     all     requirements     in
-26.2 [numeric.requirements].
-
-        </p>
-        <p>
-
-I  believe  this  problem  was  introduced  by  the  adoption  of  the
-resolution                outlined                in                <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0857.asc">N0857</a>,
-<i>Assignment  of  valarrays</i>,  from  1996.   The  copy  assignment
-operator  of  the original  numerical  array  classes  proposed in  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0280.pdf">N0280</a>,
-as      well       as      the      one       proposed      in      <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>
-(both  from 1993), had  well-defined semantics  for arrays  of unequal
-size (the  latter explicitly  only when <code>*this</code>  was empty;
-assignment of non empty arrays of unequal size was a runtime error).
-
-        </p>
-        <p>
-
-The  justification for  the  change given  in  N0857 was the "loss  of
-performance [deemed]  only significant  for very simple  operations on
-small arrays or for architectures with very few registers."
-
-        </p>
-        <p>
-
-Since tiny  arrays on a  limited subset of hardware  architectures are
-likely  to  be  an   exceedingly  rare  case  (despite  the  continued
-popularity of  x86) I  propose to revert  the resolution and  make the
-behavior    of   all   <code>valarray</code>    assignment   operators
-well-defined even  for non-conformal  arrays (i.e., arrays  of unequal
-size).   I have implemented  this change  and measured  no significant
-degradation  in performance in  the common  case (non-empty  arrays of
-equal size).  I  have measured a 50% (and in  some cases even greater)
-speedup  in the  case of  assignments to  empty arrays  versus calling
-<code>resize()</code>  first followed  by  an invocation  of the  copy
-assignment operator.
-
-        </p>
-
 <p><i>[
-Bellevue:
+2009 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-If no proposed wording by June meeting, this issue should be closed NAD.
+Move to Open.  Martin will work on proposed wording.
 </blockquote>
 
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
 
 
-<blockquote>
-<p>
-Move resolution 1 to Ready.
-</p>
+<p><b>Proposed resolution:</b></p>
 <p>
-Howard: second resolution has been commented out (made invisible).
-Can be brought back on demand.
 </p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-        <p>
-
-Change 26.6.2.2 [valarray.assign], p1 as follows:
-
-        </p>
-        <blockquote>
-            <p>
-                <code>
-
-valarray&lt;T&gt;&amp; operator=(const valarray&lt;T&gt;&amp;<ins> x</ins>);
-
-                </code>
-            </p>
-            <p>
-
--1- Each element of the <code>*this</code> array is assigned the value
-of  the  corresponding  element   of  the  argument  array.   <del>The
-resulting behavior is undefined if </del><ins>When </ins>the length of
-the  argument  array  is  not   equal  to  the  length  of  the  *this
-array<del>.</del><ins>  resizes  <code>*this</code>  to make  the  two
-arrays     the      same     length,     as      if     by     calling
-<code>resize(x.size())</code>, before performing the assignment.</ins>
-
-            </p>
-        </blockquote>
-        <p>
-
-And  add a new  paragraph just  below paragraph  1 with  the following
-text:
-
-        </p>
-        <blockquote>
-            <p>
-
-<ins>-2- <i>Postcondition</i>: <code>size() == x.size()</code>.</ins>
-
-            </p>
-        </blockquote>
-        <p>
-
-Also add the following paragraph to 26.6.2.2 [valarray.assign], immediately after p4:
-
-        </p>
-        <blockquote>
-            <p>
-
-<ins>-?- When the length,  <i><code>N</code></i> of the array referred
-to by the  argument is not equal to  the length of <code>*this</code>,
-the  operator resizes <code>*this</code>  to make  the two  arrays the
-same  length, as if  by calling  <code>resize(<i>N</i>)</code>, before
-performing the assignment.</ins>
-
-            </p>
-        </blockquote>
-
-<p><i>[
-pre-Sophia Antipolis, Martin adds the following compromise wording, but
-prefers the original proposed resolution:
-]</i></p>
-
-
-
-
-
-
-<p><i>[
-Kona (2007): Gaby to propose wording for an alternative resolution in
-which you can assign to a <tt>valarray</tt> of size 0, but not to any other
-<tt>valarray</tt> whose size is unequal to the right hand side of the assignment.
-]</i></p>
 
 
 
@@ -5355,11 +3804,11 @@ which you can assign to a <tt>valarray</tt> of size 0, but not to any other
 
 <hr>
 <h3><a name="631"></a>631. conflicting requirements for <tt>BinaryPredicate</tt></h3>
-<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> James Kanze <b>Opened:</b> 2007-01-31  <b>Last modified:</b> 2009-07-28</p>
+<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> James Kanze <b>Opened:</b> 2007-01-31  <b>Last modified:</b> 2009-10-24</p>
 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#algorithms">active issues</a> in [algorithms].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 The general requirements for <tt><tt>BinaryPredicate</tt></tt> (in 25 [algorithms]/8) contradict the implied specific requirements for
@@ -5378,7 +3827,7 @@ part of the signature, it should work correctly in the context of <tt>if
 </p></blockquote>
 
 <p>
-In the description of <tt>upper_bound</tt> (25.5.3.2 [upper.bound]/2), however, the use is described as
+In the description of <tt>upper_bound</tt> (25.4.3.2 [upper.bound]/2), however, the use is described as
 "<tt>!comp(<i>value</i>, <i>e</i>)</tt>", where <tt><i>e</i></tt> is an
 element of the sequence (a result of dereferencing
 <tt>*<i>first</i></tt>).
@@ -5403,6 +3852,19 @@ and <tt>upper_bound</tt> to work withoutt these changes.
 ]</i></p>
 
 
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
+
+<blockquote>
+Move to Review. The small problem with the "iterator type"
+will be fixed. The cited functions (<tt>lower_bound</tt>, <tt>uppwer_bound</tt>,
+<tt>equal_range</tt>) don't actually use <tt>BinaryPredicate</tt> , and where it is used,
+it is consistent with  [algorithm]/8, so the main complaint of the issue
+is moot.
+</blockquote>
+
 
 
 <p><b>Proposed resolution:</b></p>
@@ -5450,7 +3912,7 @@ post San Francisco:
 
 <blockquote>
 Solved by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2759.pdf">N2759</a>.
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2759.pdf">N2759</a>.
 </blockquote>
 
 
@@ -5459,1286 +3921,1175 @@ Solved by
 
 
 <hr>
-<h3><a name="635"></a>635. domain of <tt>allocator::address</tt></h3>
-<p><b>Section:</b> X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-02-08  <b>Last modified:</b> 2009-07-28</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="671"></a>671. precision of hexfloat</h3>
+<p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> John Salmon <b>Opened:</b> 2007-04-20  <b>Last modified:</b> 2009-10-21</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.put.virtuals">active issues</a> in [facet.num.put.virtuals].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The table of allocator requirements in X [allocator.requirements] describes
-<tt>allocator::address</tt> as:
+I am trying to understand how TR1 supports hex float (%a) output.
 </p>
-<blockquote><pre>a.address(r)
-a.address(s)
-</pre></blockquote>
 <p>
-where <tt>r</tt> and <tt>s</tt> are described as:
+As far as I can tell, it does so via the following:
 </p>
-<blockquote><p>
-a value of type <tt>X::reference</tt> obtained by the expression <tt>*p</tt>. 
-</p></blockquote>
-
 <p>
-and <tt>p</tt> is 
+8.15 Additions to header &lt;locale&gt; [tr.c99.locale]
 </p>
-
-<blockquote><p>
-a value of type <tt>X::pointer</tt>, obtained by calling <tt>a1.allocate</tt>, 
-where <tt>a1 == a</tt>
-</p></blockquote>
-
 <p>
-This all implies that to get the address of some value of type <tt>T</tt> that
-value must have been allocated by this allocator or a copy of it.
+In subclause 22.4.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
+the line:
+floatfield == ios_base::scientific %E
 </p>
-
 <p>
-However sometimes container code needs to compare the address of an external value of
-type <tt>T</tt> with an internal value.  For example <tt>list::remove(const T&amp; t)</tt>
-may want to compare the address of the external value <tt>t</tt> with that of a value
-stored within the list.  Similarly <tt>vector</tt> or <tt>deque insert</tt> may
-want to make similar comparisons (to check for self-referencing calls).
+add the two lines:
+</p>
+<blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific &amp;&amp; !uppercase %a
+floatfield == ios_base::fixed | ios_base::scientific %A 2
+</pre></blockquote>
+<p>
+[Note: The additional requirements on print and scan functions, later
+in this clause, ensure that the print functions generate hexadecimal
+floating-point fields with a %a or %A conversion specifier, and that
+the scan functions match hexadecimal floating-point fields with a %g
+conversion specifier.  end note]
+</p>
+<p>
+Following the thread, in 22.4.2.2.2 [facet.num.put.virtuals], we find:
+</p>
+<p>
+For conversion from a floating-point type, if (flags &amp; fixed) != 0 or
+if str.precision() &gt; 0, then str.precision() is specified in the
+conversion specification.
 </p>
-
 <p>
-Mandating that <tt>allocator::address</tt> can only be called for values which the
-allocator allocated seems overly restrictive.
+This would seem to imply that when floatfield == fixed|scientific, the
+precision of the conversion specifier is to be taken from
+str.precision().  Is this really what's intended?  I sincerely hope
+that I'm either missing something or this is an oversight.  Please
+tell me that the committee did not intend to mandate that hex floats
+(and doubles) should by default be printed as if by %.6a.
 </p>
 
 <p><i>[
-post San Francisco:
+Howard: I think the fundamental issue we overlooked was that with %f,
+%e, %g, the default precision was always 6.  With %a the default
+precision is not 6, it is infinity.  So for the first time, we need to
+distinguish between the default value of precision, and the precision
+value 6.
 ]</i></p>
 
 
-<blockquote>
-Pablo recommends NAD Editorial, solved by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>.
-</blockquote>
-
 <p><i>[
-2009-04-28 Pablo adds:
+2009-07 Frankfurt
 ]</i></p>
 
 
 <blockquote>
-Tentatively-ready NAD Editorial as fixed by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>.
-</blockquote>
+<p>
+Leave this open for Robert and Daniel to work on.
+</p>
+<p>
+Straw poll: Disposition?
+</p>
+<ul>
+<li>Default is %.6a (i.e. NAD): 2</li>
+<li>Always %a (no precision): 6</li>
+<li>precision(-1) == %a: 3</li>
+</ul>
+<p>
+Daniel and Robert have direction to write up wording for the "always %a" solution.
+</p>
 
 <p><i>[
-2009-07 Frankfurt
+2009-07-15 Robert provided wording.
 ]</i></p>
 
-
-<blockquote>
-Fixed by N2768.
 </blockquote>
 
 <p><i>[
-2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
+2009-10 Santa Cruz:
 ]</i></p>
 
 
+<blockquote>
+Move to Ready.
+</blockquote>
+
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change X [allocator.requirements]:
+Change 22.4.2.2.2 [facet.num.put.virtuals], Stage 1, under p5 (near the end
+of Stage 1):
 </p>
 
 <blockquote>
-<p>
-<tt>r</tt> : a value of type <tt>X::reference</tt> <del>obtained by the expression *p</del>.
-</p>
-<p>
-<tt>s</tt> : a value of type <tt>X::const_reference</tt> <del>obtained by the 
-expression <tt>*q</tt> or by conversion from a value <tt>r</tt></del>.
-</p>
+For conversion from a floating-point type, <tt>str.precision()</tt> is specified
+<ins>as precision</ins> in the conversion specification
+<ins>if <tt>floatfield != (ios_base::fixed | ios_base::scientific)</tt>, else no
+precision is specified</ins>.
 </blockquote>
 
-<p><i>[
-post Oxford:  This would be rendered NAD Editorial by acceptance of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
-]</i></p>
 
 
 <p><i>[
-Kona (2007):  This issue is section 8 of N2387.  There was some discussion of it but
-no resolution to this issue was recorded.  Moved to Open.
+Kona (2007): Robert volunteers to propose wording.
 ]</i></p>
 
 
 
 
 
-
-
 <hr>
-<h3><a name="659"></a>659. istreambuf_iterator should have an operator-&gt;()</h3>
-<p><b>Section:</b> 24.6.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2007-03-25  <b>Last modified:</b> 2009-07-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="676"></a>676. Moving the unordered containers</h3>
+<p><b>Section:</b> 23.5 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-05  <b>Last modified:</b> 2009-10-29</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Greg Herlihy has clearly demonstrated that a user defined input
-iterator should have an operator-&gt;(), even if its
-value type is a built-in type (comp.std.c++, "Re: Should any iterator
-have an operator-&gt;() in C++0x?", March 2007).  And as Howard
-Hinnant remarked in the same thread that the input iterator
-<tt>istreambuf_iterator</tt> doesn't have one, this must be a
-defect!
-</p>
-<p>
-Based on Greg's example, the following code demonstrates the issue:
-</p><pre> #include &lt;iostream&gt; 
- #include &lt;fstream&gt;
- #include &lt;streambuf&gt; 
-
- typedef char C;
- int main ()
- {
-   std::ifstream s("filename", std::ios::in);
-   std::istreambuf_iterator&lt;char&gt; i(s);
-
-   (*i).~C();  // This is well-formed...
-   i-&gt;~C();  // ... so this should be supported!
- }
-</pre>
+Move semantics are missing from the <tt>unordered</tt> containers.  The proposed
+resolution below adds move-support consistent with
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html">N1858</a>
+and the current working draft.
+</p>
 
 <p>
-Of course, operator-&gt; is also needed when the value_type of
-istreambuf_iterator is a class.
-</p>
-<p>
-The operator-&gt; could be implemented in various ways.  For instance,
-by storing the current value inside the iterator, and returning its
-address.  Or by returning a proxy, like operator_arrow_proxy, from
-<a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a>
-</p>
-<p>
-I hope that the resolution of this issue will contribute to getting a
-clear and consistent definition of iterator concepts.
+The current proposed resolution simply lists the requirements for each function.
+These might better be hoisted into the requirements table for unordered associative containers.
+Futhermore a mild reorganization of the container requirements could well be in order.
+This defect report is purposefully ignoring these larger issues and just focusing
+on getting the unordered containers "moved".
 </p>
 
 <p><i>[
-Kona (2007): The proposed resolution is inconsistent because the return
-type of <tt>istreambuf_iterator::operator-&gt;()</tt> is specified to be <tt>pointer</tt>,
-but the proposed text also states that "<tt>operator-&gt;</tt> may return a proxy."
+2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
 ]</i></p>
 
 
 <p><i>[
-Niels Dekker (mailed to Howard Hinnant):
+2009-10-17 Removed rvalue-swaps from wording.
 ]</i></p>
 
-<blockquote>
-<p>
-The proposed resolution does
-not seem inconsistent to me. <tt>istreambuf_iterator::operator-&gt;()</tt> should
-have <tt>istreambuf_iterator::pointer</tt> as return type, and this return type
-may in fact be a proxy.
-</p>
-<p>
-AFAIK, the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a> ("<tt>iterator_traits::reference</tt>
-unspecified for some iterator categories") implies that for any iterator
-class <tt>Iter</tt>, the return type of <tt>operator-&gt;()</tt> is <tt>Iter::pointer</tt>, by
-definition.  I don't think <tt>Iter::pointer</tt> needs to be a raw pointer.
-</p>
-<p>
-Still I wouldn't mind if the text "<tt>operator-&gt;</tt> may return a proxy" would
-be removed from the resolution. I think it's up to the library
-implementation, how to implement <tt>istreambuf_iterator::operator-&gt;()</tt>.  As
-longs as it behaves as expected: <tt>i-&gt;m</tt> should have the same effect as
-<tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i-&gt;~C()</tt>.  The main issue
-is just: <tt>istreambuf_iterator</tt> should have an <tt>operator-&gt;()</tt>!
-</p>
-</blockquote>
 
 <p><i>[
-2009-04-30 Alisdair adds:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Note that operator-&gt; is now a requirement in the <tt>InputIterator</tt> concept, so
-this issue cannot be ignored or existing valid programs will break when
-compiled with an 0x library.
+Move to Review. Alisdair will review proposed wording.
 </blockquote>
 
 <p><i>[
-2009-05-29 Alisdair adds:
+2009-10-29 Daniel updates wording.
 ]</i></p>
 
 
-<blockquote>
-<p>
-I agree with the observation that in principle the type 'pointer' may be a
-proxy, and the words highlighting this are redundant.
-</p>
-<p>
-However, in the current draught <tt>pointer</tt> is required to be exactly '<tt>charT *</tt>'
-by the derivation from <tt>std::iterator</tt>.  At a minimum, the 4th parameter of
-this base class template should become unspecified.  That permits the
-introduction of a proxy as a nested class in some further undocumented (not
-even exposition-only) base.
-</p>
-<p>
-It also permits the <tt>istream_iterator</tt> approach where the cached value is
-stored in the iterator itself, and the iterator serves as its own proxy for
-post-increment <tt>operator++</tt> - removing the need for the existing
-exposition-only nested class <tt>proxy</tt>.
-</p>
-<p>
-Note that the current <tt>proxy</tt> class also has exactly the right properties to
-serve as the pointer <tt>proxy</tt> too.  This is likely to be a common case where an
-<tt>InputIterator</tt> does not hold internal state but delegates to another class.
-</p>
-<p>
-Proposed Resolution:
-</p>
-<p>
-In addition to the current proposal:
-</p>
-<p>
-24.6.3 [istreambuf.iterator]
-</p>
-<blockquote><pre>template&lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
-class istreambuf_iterator
-  : public iterator&lt;input_iterator_tag, charT,
-                    typename traits::off_type, <del>charT*</del> <ins><i>unspecified</i></ins>, charT&gt; {
-</pre></blockquote>
-</blockquote>
 
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
 
+<p><b>Proposed resolution:</b></p>
 
-<blockquote>
-<p>
-Move the additional part into the proposed resolution, and wrap the
-descriptive text in a Note.
-</p>
-<p><i>[Howard: done.]</i></p>
+<p><b><tt>unordered_map</tt></b></p>
 
 <p>
-Move to Ready.
+Change 23.5.1 [unord.map]:
 </p>
-</blockquote>
 
+<blockquote><pre>class unordered_map
+{
+    ...
+    unordered_map(const unordered_map&amp;);
+    <ins>unordered_map(unordered_map&amp;&amp;);</ins>
+    ~unordered_map();
+    unordered_map&amp; operator=(const unordered_map&amp;);
+    <ins>unordered_map&amp; operator=(unordered_map&amp;&amp;);</ins>
+    ...
+    // modifiers 
+    <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj); 
+    <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);</ins>
+    iterator       insert(const_iterator hint, const value_type&amp; obj);
+    <ins>template &lt;class P&gt; iterator       insert(const_iterator hint, P&amp;&amp; obj);</ins>
+    ...
+    mapped_type&amp; operator[](const key_type&amp; k);
+    <ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins>
+    ...
+};
 
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Add to the synopsis in 24.6.3 [istreambuf.iterator]:
+Add to 23.5.1.1 [unord.map.cnstr]:
 </p>
 
-<blockquote><pre>charT operator*() const;
-<ins>pointer operator-&gt;() const;</ins>
-istreambuf_iterator&lt;charT,traits&gt;&amp; operator++();
-</pre></blockquote>
+<blockquote>
+<pre>template &lt;class InputIterator&gt;
+  unordered_map(InputIterator f, InputIterator l, 
+                size_type n = <i>implementation-defined</i>, 
+                const hasher&amp; hf = hasher(), 
+                const key_equal&amp; eql = key_equal(), 
+                const allocator_type&amp; a = allocator_type());
+</pre>
+
+<blockquote><p>
+<ins>
+<i>Requires:</i> If the iterator's dereference operator returns an
+lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
+then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
+<tt>CopyConstructible</tt>.
+</ins>
+</p></blockquote>
+</blockquote>
 
 <p>
-24.6.3 [istreambuf.iterator]
+Add to 23.5.1.2 [unord.map.elem]:
 </p>
 
-<blockquote><pre>template&lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
-class istreambuf_iterator
-  : public iterator&lt;input_iterator_tag, charT,
-                    typename traits::off_type, <del>charT*</del> <ins><i>unspecified</i></ins>, charT&gt; {
-</pre></blockquote>
+<blockquote>
 
-<p>
-Change 24.6.3 [istreambuf.iterator], p1:
-</p>
+<pre>mapped_type&amp; operator[](const key_type&amp; k);</pre>
 
-<blockquote><p>
-The class template <tt>istreambuf_iterator</tt> reads successive
-characters from the <tt>streambuf</tt> for which it was constructed.
-<tt>operator*</tt> provides access to the current input character, if
-any. <ins>[<i>Note:</i> <tt>operator-&gt;</tt> may return a proxy. &#8212;
-<i>end note</i>]</ins> Each time
-<tt>operator++</tt> is evaluated, the iterator advances to the next
-input character. If the end of stream is reached
-(<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the
-iterator becomes equal to the end of stream iterator value. The default
-constructor <tt>istreambuf_iterator()</tt> and the constructor
-<tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator
-object suitable for use as an end-of-range.
-</p></blockquote>
+<blockquote>
+<p>...</p>
+<p><ins>
+<i>Requires:</i> <tt>key_type</tt> shall be <tt>CopyConstructible</tt>
+and <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
+</ins></p>
+</blockquote>
 
+<pre><ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins></pre>
 
+<blockquote>
+<p><ins>
+<i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an
+element whose key is equivalent to <tt>k</tt> , inserts the value
+<tt>std::pair&lt;const key_type, mapped_type&gt;(std::move(k), mapped_type())</tt>.
+</ins></p>
 
+<p><ins>
+<i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
+</ins></p>
 
+<p><ins>
+<i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the
+(unique) element whose key is equivalent to <tt>k</tt>.
+</ins></p>
 
+</blockquote>
 
+</blockquote>
 
-<hr>
-<h3><a name="668"></a>668. <tt>money_get</tt>'s empty minus sign</h3>
-<p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16  <b>Last modified:</b> 2009-07-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-22.4.6.1.2 [locale.money.get.virtuals], para 3 says:
+Add new section [unord.map.modifiers]:
 </p>
 
-<blockquote><p>
-If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
-optional, and if no sign is detected, the result is given the sign
-that corresponds to the source of the empty string.
-</p></blockquote>
+<blockquote>
+<pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
+<ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);</ins>
+<ins>iterator       insert(const_iterator hint, const value_type&amp; x);</ins>
+<ins>template &lt;class P&gt; iterator       insert(const_iterator hint, P&amp;&amp; x);</ins>
+<ins>template &lt;class InputIterator&gt;
+  void insert(InputIterator first, InputIterator last);</ins>
+</pre>
 
-<p>
-The following objection has been raised:
-</p>
+<blockquote>
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
+requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
+<tt>CopyConstructible</tt>.
+ If <tt>P</tt> is instantiated as a reference
+type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
+is considered to be an rvalue as it is converted to <tt>value_type</tt>
+and inserted into the <tt>unordered_map</tt>. Specifically, in such
+cases <tt>CopyConstructible</tt> is not required for <tt>key_type</tt> or
+<tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
+requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
+mapped_type&gt;</tt>, then <tt>key_type</tt> must be
+<tt>CopyConstructible</tt>).
+</ins></p>
 
-<blockquote><p>
-A <tt>negative_sign</tt> of "" means "there is no
-way to write a negative sign" not "any null sequence is a negative
-sign, so it's always there when you look for it".
-</p></blockquote>
+<p><ins>
+The signature taking <tt>InputIterator</tt>
+parameters requires <tt>CopyConstructible</tt> of both
+<tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
+<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
+<tt>value_type</tt>.
+</ins></p>
 
-<p>
-[Plum ref _222612Y32]
-</p>
+</blockquote>
 
-<p><i>[
-Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
-]</i></p>
+</blockquote>
 
+<p><b><tt>unordered_multimap</tt></b></p>
 
 <p>
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>.
+Change 23.5.2 [unord.multimap]:
 </p>
 
-<p><i>[
-2009-05-17 Howard adds:
-]</i></p>
+<blockquote><pre>class unordered_multimap
+{
+    ...
+    unordered_multimap(const unordered_multimap&amp;);
+    <ins>unordered_multimap(unordered_multimap&amp;&amp;);</ins>
+    ~unordered_multimap();
+    unordered_multimap&amp; operator=(const unordered_multimap&amp;);
+    <ins>unordered_multimap&amp; operator=(unordered_multimap&amp;&amp;);</ins>
+    ...
+    // modifiers 
+    iterator insert(const value_type&amp; obj); 
+    <ins>template &lt;class P&gt; iterator insert(P&amp;&amp; obj);</ins>
+    iterator       insert(const_iterator hint, const value_type&amp; obj);
+    <ins>template &lt;class P&gt; iterator       insert(const_iterator hint, P&amp;&amp; obj);</ins>
+    ...
+};
 
+</pre></blockquote>
 
-<blockquote>
 <p>
-I disagree that a <tt>negative_sign</tt> of "" means "there is no
-way to
-write a negative sign". The meaning requires the sentences of
-22.4.6.1.2 [locale.money.get.virtuals] p3 following that quoted above
-to be
-taken into account:
+Add to 23.5.2.1 [unord.multimap.cnstr]:
 </p>
 
 <blockquote>
--3- ... If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
-optional, and if no sign is detected, the result is given the sign that
-corresponds to the source of the empty string. Otherwise, the character
-in the indicated position must match the first character of <tt>pos</tt>
-or <tt>neg</tt>, and the result is given the corresponding sign. If the
-first character of <tt>pos</tt> is equal to the first character of
-<tt>neg</tt>, or if both strings are empty, the result is given a
-positive sign.
+<pre>template &lt;class InputIterator&gt;
+  unordered_multimap(InputIterator f, InputIterator l, 
+                size_type n = <i>implementation-defined</i>, 
+                const hasher&amp; hf = hasher(), 
+                const key_equal&amp; eql = key_equal(), 
+                const allocator_type&amp; a = allocator_type());
+</pre>
+
+<blockquote><p>
+<ins>
+<i>Requires:</i> If the iterator's dereference operator returns an
+lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
+then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
+<tt>CopyConstructible</tt>.
+</ins>
+</p></blockquote>
 </blockquote>
 
 <p>
-So a <tt>negative_sign</tt> of "" means "there is no way to write a
-negative sign" only when <tt>positive_sign</tt> is also "".  However
-when <tt>negative_sign</tt> is "" and <tt>postive_sign.size() &gt;
-0</tt>, then one writes a negative value by not writing the
-<tt>postive_sign</tt> in the position indicated by
-<tt>money_base::sign</tt>.
-For example:
+Add new section [unord.multimap.modifiers]:
 </p>
 
-<blockquote><pre>pattern = {symbol, sign, value, none}
-positive_sign = "+"
-negative_sign = ""
-$123   // a negative value, using optional sign
-$+123  // a positive value
-$-123  // a parse error
-</pre></blockquote>
+<blockquote>
+<pre><ins>iterator insert(const value_type&amp; x);</ins>
+<ins>template &lt;class P&gt; iterator       insert(P&amp;&amp; x);</ins>
+<ins>iterator       insert(const_iterator hint, const value_type&amp; x);</ins>
+<ins>template &lt;class P&gt; iterator       insert(const_iterator hint, P&amp;&amp; x);</ins>
+<ins>template &lt;class InputIterator&gt;
+  void insert(InputIterator first, InputIterator last);</ins>
+</pre>
 
-<p>
-And:
-</p>
+<blockquote>
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
+requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
+<tt>CopyConstructible</tt>.
+If <tt>P</tt> is instantiated as a reference
+type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
+is considered to be an rvalue as it is converted to <tt>value_type</tt>
+and inserted into the <tt>unordered_multimap</tt>. Specifically, in such
+cases <tt>CopyConstructible</tt> is not required for <tt>key_type</tt> or
+<tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
+requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
+mapped_type&gt;</tt>, then <tt>key_type</tt> must be
+<tt>CopyConstructible</tt>).
+</ins></p>
 
-<blockquote><pre>pattern = {symbol, sign, value, none}
-positive_sign = ""
-negative_sign = ""
-$123   // a positive value, no sign possible
-$+123  // a parse error
-$-123  // a parse error
-</pre></blockquote>
+<p><ins>
+The signature taking <tt>InputIterator</tt>
+parameters requires <tt>CopyConstructible</tt> of both
+<tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
+<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
+<tt>value_type</tt>.
+</ins></p>
+</blockquote>
 
+</blockquote>
+
+<p><b><tt>unordered_set</tt></b></p>
 
 <p>
-And (regarding <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>):
+Change 23.5.3 [unord.set]:
 </p>
 
-<blockquote><pre>pattern = {symbol, sign, value, none}
-positive_sign = "-"
-negative_sign = "-"
-$123   // a parse error, sign is mandatory
-$+123  // a parse error
-$-123  // a positive value
+<blockquote><pre>class unordered_set
+{
+    ...
+    unordered_set(const unordered_set&amp;);
+    <ins>unordered_set(unordered_set&amp;&amp;);</ins>
+    ~unordered_set();
+    unordered_set&amp; operator=(const unordered_set&amp;);
+    <ins>unordered_set&amp; operator=(unordered_set&amp;&amp;);</ins>
+    ...
+    // modifiers 
+    <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj); 
+    <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; obj);</ins>
+    iterator       insert(const_iterator hint, const value_type&amp; obj);
+    <ins>iterator       insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
+    ...
+};
 </pre></blockquote>
 
-
 <p>
-The text seems both unambiguous and clear to me.  I recommend NAD for
-both this issue and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>.  However I would have no
-objection to adding examples such as those above.
+Add to 23.5.3.1 [unord.set.cnstr]:
 </p>
-</blockquote>
-
-<p><i>[
-Batavia (2009-05):
-]</i></p>
 
 <blockquote>
-<p>
-This discussion applies equally to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a> (q.v.).
-Howard has added examples above,
-and recommends either NAD or a resolution that adds his (or similar) examples
-to the Working Paper.
-</p>
-<p>
-Alan would like to rewrite paragraph 3.
-</p>
-<p>
-We recommend moving to NAD.
-Anyone who feels strongly about adding the examples
-is invited to submit corresponding wording.
-We further recommend issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a> be handled identically.
-</p>
-</blockquote>
-
-<p><i>[
-2009-07-14 Alan reopens with improved wording.
-]</i></p>
-
-
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
-
+<pre>template &lt;class InputIterator&gt;
+  unordered_set(InputIterator f, InputIterator l, 
+                size_type n = <i>implementation-defined</i>, 
+                const hasher&amp; hf = hasher(), 
+                const key_equal&amp; eql = key_equal(), 
+                const allocator_type&amp; a = allocator_type());
+</pre>
 
-<blockquote>
-No consensus for closing as NAD.  Leave in Review.
+<blockquote><p>
+<ins>
+<i>Requires:</i> If the iterator's dereference operator returns an
+lvalue or a const rvalue <tt>value_type</tt>, then the
+<tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
+</ins>
+</p></blockquote>
 </blockquote>
 
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 22.4.6.1.2 [locale.money.get.virtuals] p3:
+Add new section [unord.set.modifiers]:
 </p>
 
 <blockquote>
--3- <del>If the first character (if any) in the string pos returned by
-<tt>mp.positive_sign()</tt> or the string <tt>neg</tt> returned by
-<tt>mp.negative_sign()</tt> is recognized in the position indicated by
-sign in the format pattern, it is consumed and any remaining characters
-in the string are required after all the other format components.
-[<i>Example:</i> If <tt>showbase</tt> is off&#65533;, then for a <tt>neg</tt>
-value of "()" and a currency symbol of "L", in "(100 L)" the "L" is
-consumed; but if <tt>neg</tt> is "-", the "L" in "-100 L" is not
-consumed. -- <i>end example</i>] If <tt>pos</tt> or <tt>neg</tt> is
-empty, the sign component is optional, and if no sign is detected, the
-result is given the sign that corresponds to the source of the empty
-string. Otherwise, the character in the indicated position must match
-the first character of <tt>pos</tt> or <tt>neg</tt>, and the result is
-given the corresponding sign. If the first character of <tt>pos</tt> is
-equal to the first character of <tt>neg</tt>, or if both strings are
-empty, the result is given a positive sign.</del>
+<pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
+<ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; x);</ins>
+<ins>iterator       insert(const_iterator hint, const value_type&amp; x);</ins>
+<ins>iterator       insert(const_iterator hint, value_type&amp;&amp; x);</ins>
+<ins>template &lt;class InputIterator&gt;
+  void insert(InputIterator first, InputIterator last);</ins>
+</pre>
 
-<ins>The sign pattern strings <tt>pos</tt> and <tt>neg</tt> are returned by
-<tt>mp.positive_sign()</tt> and <tt>mp.negative_sign()</tt> respectively. A sign pattern
-is matched if its first character is recognized in <tt>s</tt> in the position
-indicated by <tt>sign</tt> in the format pattern, or if the pattern is empty and
-there is no sign recognized in <tt>s</tt>. A match is required to occur. If both
-patterns are matched, the result is given a positive sign, otherwise the
-result is given the sign corresponding to the matched pattern. 
-If the pattern contains more than one character, the characters after the first 
-must be matched in <tt>s</tt> after all other format components. 
-If any sign
-characters are matched, <tt>s</tt> is consumed up to and including those characters.
-[<i>Example:</i> If <tt>showbase</tt> is off, then for a <tt>neg</tt>
-value of "<tt>()</tt>" and a currency symbol of "<tt>L</tt>", in
-"<tt>(100 L)</tt>" the entire string is consumed; but for a <tt>neg</tt>
-value of "<tt>-</tt>", in "<tt>-100 L</tt>", the string is consumed
-through the second "<tt>0</tt>" (the space and "<tt>L</tt>" are not consumed). &#8212; <i>end
-example</i>] </ins>
-</blockquote>
+<blockquote>
 
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const
+value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
+be <tt>CopyConstructible</tt>.
+</ins></p>
 
+<p><ins>
+The signature taking <tt>InputIterator</tt> parameters requires
+<tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
+<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
+<tt>value_type</tt>.
+</ins></p>
 
+</blockquote>
 
+</blockquote>
+
+<p><b><tt>unordered_multiset</tt></b></p>
 
-<hr>
-<h3><a name="671"></a>671. precision of hexfloat</h3>
-<p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> John Salmon <b>Opened:</b> 2007-04-20  <b>Last modified:</b> 2009-07-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.put.virtuals">active issues</a> in [facet.num.put.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I am trying to understand how TR1 supports hex float (%a) output.
-</p>
-<p>
-As far as I can tell, it does so via the following:
-</p>
-<p>
-8.15 Additions to header &lt;locale&gt; [tr.c99.locale]
-</p>
-<p>
-In subclause 22.4.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
-the line:
-floatfield == ios_base::scientific %E
-</p>
 <p>
-add the two lines:
+Change 23.5.4 [unord.multiset]:
 </p>
-<blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific &amp;&amp; !uppercase %a
-floatfield == ios_base::fixed | ios_base::scientific %A 2
+
+<blockquote><pre>class unordered_multiset
+{
+    ...
+    unordered_multiset(const unordered_multiset&amp;);
+    <ins>unordered_multiset(unordered_multiset&amp;&amp;);</ins>
+    ~unordered_multiset();
+    unordered_multiset&amp; operator=(const unordered_multiset&amp;);
+    <ins>unordered_multiset&amp; operator=(unordered_multiset&amp;&amp;);</ins>
+    ...
+    // modifiers 
+    iterator insert(const value_type&amp; obj); 
+    <ins>iterator insert(value_type&amp;&amp; obj);</ins>
+    iterator       insert(const_iterator hint, const value_type&amp; obj);
+    <ins>iterator       insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
+    ...
+};
+
 </pre></blockquote>
+
 <p>
-[Note: The additional requirements on print and scan functions, later
-in this clause, ensure that the print functions generate hexadecimal
-floating-point fields with a %a or %A conversion specifier, and that
-the scan functions match hexadecimal floating-point fields with a %g
-conversion specifier.  end note]
-</p>
-<p>
-Following the thread, in 22.4.2.2.2 [facet.num.put.virtuals], we find:
-</p>
-<p>
-For conversion from a floating-point type, if (flags &amp; fixed) != 0 or
-if str.precision() &gt; 0, then str.precision() is specified in the
-conversion specification.
+Add to 23.5.4.1 [unord.multiset.cnstr]:
 </p>
+
+<blockquote>
+<pre>template &lt;class InputIterator&gt;
+  unordered_multiset(InputIterator f, InputIterator l, 
+                size_type n = <i>implementation-defined</i>, 
+                const hasher&amp; hf = hasher(), 
+                const key_equal&amp; eql = key_equal(), 
+                const allocator_type&amp; a = allocator_type());
+</pre>
+
+<blockquote><p>
+<ins>
+<i>Requires:</i> If the iterator's dereference operator returns an
+lvalue or a const rvalue <tt>value_type</tt>, then the
+<tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
+</ins>
+</p></blockquote>
+</blockquote>
+
 <p>
-This would seem to imply that when floatfield == fixed|scientific, the
-precision of the conversion specifier is to be taken from
-str.precision().  Is this really what's intended?  I sincerely hope
-that I'm either missing something or this is an oversight.  Please
-tell me that the committee did not intend to mandate that hex floats
-(and doubles) should by default be printed as if by %.6a.
+Add new section [unord.multiset.modifiers]:
 </p>
 
+<blockquote>
+<pre><ins>iterator insert(const value_type&amp; x);</ins>
+<ins>iterator insert(value_type&amp;&amp; x);</ins>
+<ins>iterator       insert(const_iterator hint, const value_type&amp; x);</ins>
+<ins>iterator       insert(const_iterator hint, value_type&amp;&amp; x);</ins>
+<ins>template &lt;class InputIterator&gt;
+  void insert(InputIterator first, InputIterator last);</ins>
+</pre>
+
+<blockquote>
+
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const
+value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
+be <tt>CopyConstructible</tt>.
+</ins></p>
+
+<p><ins>
+The signature taking <tt>InputIterator</tt> parameters requires
+<tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
+<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
+<tt>value_type</tt>.
+</ins></p>
+
+</blockquote>
+
+</blockquote>
+
+
+
 <p><i>[
-Howard: I think the fundamental issue we overlooked was that with %f,
-%e, %g, the default precision was always 6.  With %a the default
-precision is not 6, it is infinity.  So for the first time, we need to
-distinguish between the default value of precision, and the precision
-value 6.
+Voted to WP in Bellevue.
 ]</i></p>
 
 
 <p><i>[
-2009-07 Frankfurt
+post Bellevue, Pete notes:
 ]</i></p>
 
 
 <blockquote>
 <p>
-Leave this open for Robert and Daniel to work on.
-</p>
-<p>
-Straw poll: Disposition?
+Please remind people who are reviewing issues to check that the text
+modifications match the current draft. Issue 676, for example, adds two
+overloads for unordered_map::insert taking a hint. One takes a
+const_iterator and returns a const_iterator, and the other takes an
+iterator and returns an iterator. This was correct at the time the issue
+was written, but was changed in Toronto so there is only one hint
+overload, taking a const_iterator and returning an iterator.
 </p>
-<ul>
-<li>Default is %.6a (i.e. NAD): 2</li>
-<li>Always %a (no precision): 6</li>
-<li>precision(-1) == %a: 3</li>
-</ul>
 <p>
-Daniel and Robert have direction to write up wording for the "always %a" solution.
+This issue is not ready. In addition to the relatively minor signature
+problem I mentioned earlier, it puts requirements in the wrong places.
+Instead of duplicating requirements throughout the template
+specifications, it should put them in the front matter that talks about
+requirements for unordered containers in general. This presentation
+problem is editorial, but I'm not willing to do the extensive rewrite
+that it requires. Please put it back into Open status.
 </p>
+</blockquote>
 
+<p><b>Rationale:</b></p>
 <p><i>[
-2009-07-15 Robert provided wording.
+San Francisco:
 ]</i></p>
 
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 22.4.2.2.2 [facet.num.put.virtuals], Stage 1, under p5 (near the end
-of Stage 1):
-</p>
 
 <blockquote>
-For conversion from a floating-point type, <tt>str.precision()</tt> is specified
-<ins>as precision</ins> in the conversion specification
-<ins>if <tt>floatfield != (ios_base::fixed | ios_base::scientific)</tt>, else no
-precision is specified</ins>.
+Solved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
 </blockquote>
 
 
 
-<p><i>[
-Kona (2007): Robert volunteers to propose wording.
-]</i></p>
-
-
 
 
 
 <hr>
-<h3><a name="676"></a>676. Moving the unordered containers</h3>
-<p><b>Section:</b> 23.5 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-05  <b>Last modified:</b> 2009-07-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p>
+<h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</h3>
+<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-20  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Move semantics are missing from the <tt>unordered</tt> containers.  The proposed
-resolution below adds move-support consistent with
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html">N1858</a>
-and the current working draft.
-</p>
-
-<p>
-The current proposed resolution simply lists the requirements for each function.
-These might better be hoisted into the requirements table for unordered associative containers.
-Futhermore a mild reorganization of the container requirements could well be in order.
-This defect report is purposefully ignoring these larger issues and just focusing
-on getting the unordered containers "moved".
+The move-related changes inadvertently overwrote the intent of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a> removed the requirement of <tt>CopyAssignable</tt> from
+most of the member functions of node-based containers.  But the move-related changes
+unnecessarily introduced the <tt>MoveAssignable</tt> requirement for those members which used to
+require <tt>CopyAssignable</tt>.
 </p>
 
-<p><i>[
-2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
 <p>
-Add to 23.5 [unord]:
+We also discussed (c++std-lib-18722) the possibility of dropping <tt>MoveAssignable</tt>
+from some of the sequence requirements.  Additionally the <i>in-place</i> construction
+work may further reduce requirements.  For purposes of an easy reference, here are the
+minimum sequence requirements as I currently understand them.  Those items in requirements
+table in the working draft which do not appear below have been purposefully omitted for
+brevity as they do not have any requirements of this nature.  Some items which do not
+have any requirements of this nature are included below just to confirm that they were
+not omitted by mistake.
 </p>
 
-<blockquote><pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y); 
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
+<table border="1">
+<caption>Container Requirements</caption>
+<tbody><tr><td><tt>X u(a)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
+<tr><td><tt>X u(rv)</tt></td><td><tt>array</tt> and containers with a <tt>propagate_never</tt> allocator require <tt>value_type</tt> to be <tt>MoveConstructible</tt></td></tr>
+<tr><td><tt>a = u</tt></td><td>Sequences require <tt>value_type</tt> to be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
+                               Associative containers require <tt>value_type</tt> to be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a = rv</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveAssignable</tt>.
+                                Sequences and Associative containers with <tt>propagate_never</tt> and <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>swap(a,u)</tt></td><td><tt>array</tt> and containers with <tt>propagate_never</tt> and
+                  <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>Swappable</tt>.</td></tr>
+</tbody></table>
 
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
+<p>
+</p>
 
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
+<table border="1">
+<caption>Sequence Requirements</caption>
+<tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr>
+<tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
+<tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+                                 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
+<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
+                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
+<tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
+<tr><td><tt>a.insert(p, i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt> when the iterators return an lvalue.
+                                        If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
+                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt> when the iterators return an rvalue.</td></tr>
+<tr><td><tt>a.erase(p)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
+<tr><td><tt>a.erase(q1, q2)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
+<tr><td><tt>a.clear()</tt></td><td></td></tr>
+<tr><td><tt>a.assign(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
+                                        If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
+<tr><td><tt>a.assign(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.</td></tr>
+<tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>.
+                                     The sequence <tt>vector</tt> also requires the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+</tbody></table>
 
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
+<p>
+</p>
 
-...
+<table border="1">
+<caption>Optional Sequence Requirements</caption>
+<tbody><tr><td><tt>a.front()</tt></td><td></td></tr>
+<tr><td><tt>a.back()</tt></td><td></td></tr>
+<tr><td><tt>a.push_front(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a.push_front(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.push_back(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a.push_back(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.pop_front()</tt></td><td></td></tr>
+<tr><td><tt>a.pop_back()</tt></td><td></td></tr>
+<tr><td><tt>a[n]</tt></td><td></td></tr>
+<tr><td><tt>a.at[n]</tt></td><td></td></tr>
+</tbody></table>
 
-template &lt;class Value, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; y); 
+<p>
+</p>
 
-<ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
+<table border="1">
+<caption>Associative Container Requirements</caption>
+<tbody><tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+                                 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+                                        If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
+</tbody></table>
 
-<ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; y);</ins>
+<p>
+</p>
 
-template &lt;class Value, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; y);
+<table border="1">
+<caption>Unordered Associative Container Requirements</caption>
+<tbody><tr><td><tt>X(i, j, n, hf, eq)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+                                 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+                                        If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
+</tbody></table>
 
-<ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
+<p>
+</p>
 
-<ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre></blockquote>
+<table border="1">
+<caption>Miscellaneous Requirements</caption>
+<tbody><tr><td><tt>map[lvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>CopyConstructible</tt>.
+                                         The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>map[rvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>MoveConstructible</tt>.
+                                         The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
+</tbody></table>
 
-<p><b><tt>unordered_map</tt></b></p>
+<p><i>[
+Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
+]</i></p>
 
-<p>
-Change 23.5.1 [unord.map]:
-</p>
 
-<blockquote><pre>class unordered_map
-{
-    ...
-    unordered_map(const unordered_map&amp;);
-    <ins>unordered_map(unordered_map&amp;&amp;);</ins>
-    ~unordered_map();
-    unordered_map&amp; operator=(const unordered_map&amp;);
-    <ins>unordered_map&amp; operator=(unordered_map&amp;&amp;);</ins>
-    ...
-    // modifiers 
-    <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj); 
-    <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);</ins>
-    iterator       insert(iterator hint, const value_type&amp; obj);
-    <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; obj);</ins>
-    const_iterator insert(const_iterator hint, const value_type&amp; obj);
-    <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
-    ...
-    void swap(unordered_map&amp;<ins>&amp;</ins>);
-    ...
-    mapped_type&amp; operator[](const key_type&amp; k);
-    <ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins>
-    ...
-};
+<p><i>[
+Bellevue: This should be handled as part of the concepts work.
+]</i></p>
 
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
 
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
+<p><i>[
+2009-07-20 Reopened by Howard:
+]</i></p>
 
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre></blockquote>
 
+<blockquote>
 <p>
-Add to 23.5.1.1 [unord.map.cnstr]:
+This is one of the issues that was "solved by concepts" and is now no longer solved.
 </p>
 
-<blockquote>
-<pre>template &lt;class InputIterator&gt;
-  unordered_map(InputIterator f, InputIterator l, 
-                size_type n = <i>implementation-defined</i>, 
-                const hasher&amp; hf = hasher(), 
-                const key_equal&amp; eql = key_equal(), 
-                const allocator_type&amp; a = allocator_type());
-</pre>
+<p>
+In a nutshell, concepts adopted the "minimum requirements" philosophy outlined
+in the discussion of this issue, and enforced it.  My strong suggestion is that
+we translate the concepts specification into documentation for the containers.
+</p>
 
-<blockquote><p>
-<ins>
-<i>Requires:</i> If the iterator's dereference operator returns an
-lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
-then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
-<tt>CopyConstructible</tt>.
-</ins>
-</p></blockquote>
-</blockquote>
+<p>
+What this means for vendors is that they will have to implement container members
+being careful to only use those characteristics of a type that the concepts specification
+formally allowed.  Note that I <em>am not</em> talking about <tt>enable_if</tt>'ing
+everything.  I am simply suggesting that (for example) we tell the vendor he can't call <tt>T's</tt>
+copy constructor or move constructor within the <tt>emplace</tt> member function, etc.
+</p>
 
 <p>
-Add to 23.5.1.2 [unord.map.elem]:
+What this means for customers is that they will be able to use types within C++03
+containers which are sometimes not CopyConstructible, and sometimes not even
+MoveConstructible, etc.
 </p>
+</blockquote>
 
-<blockquote>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
-<pre>mapped_type&amp; operator[](const key_type&amp; k);</pre>
 
 <blockquote>
-<p>...</p>
-<p><ins>
-<i>Requires:</i> <tt>key_type</tt> shall be <tt>CopyConstructible</tt>
-and <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
-</ins></p>
+Leave open. Howard to provide wording.
 </blockquote>
 
-<pre><ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins></pre>
 
-<blockquote>
-<p><ins>
-<i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an
-element whose key is equivalent to <tt>k</tt> , inserts the value
-<tt>std::pair&lt;const key_type, mapped_type&gt;(std::move(k), mapped_type())</tt>.
-</ins></p>
 
-<p><ins>
-<i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
-</ins></p>
+<p><b>Proposed resolution:</b></p>
 
-<p><ins>
-<i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the
-(unique) element whose key is equivalent to <tt>k</tt>.
-</ins></p>
 
-</blockquote>
 
-</blockquote>
+<p><b>Rationale:</b></p>
+<p><i>[
+post San Francisco:
+]</i></p>
 
-<p>
-Add new section [unord.map.modifiers]:
-</p>
 
 <blockquote>
-<pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);</ins>
-<ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
-<ins>template &lt;class InputIterator&gt;
-  void insert(InputIterator first, InputIterator last);</ins>
-</pre>
+Solved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
+</blockquote>
 
-<blockquote>
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
-requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
-<tt>CopyConstructible</tt>.
-</ins></p>
 
-<p><ins>
-<tt>P</tt> shall be convertible to <tt>value_type</tt>.
- If <tt>P</tt> is instantiated as a reference
-type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
-is considered to be an rvalue as it is converted to <tt>value_type</tt>
-and inserted into the <tt>unordered_map</tt>. Specifically, in such
-cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
-<tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
-requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
-mapped_type&gt;</tt>, then <tt>key_type</tt> must be
-<tt>CopyConstructible</tt>).
-</ins></p>
 
-<p><ins>
-The signature taking <tt>InputIterator</tt>
-parameters requires <tt>CopyConstructible</tt> of both
-<tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
-<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
-<tt>value_type</tt>.
-</ins></p>
 
-</blockquote>
 
-</blockquote>
 
+<hr>
+<h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3>
+<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2007-09-12  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Add to 23.5.1.3 [unord.map.swap]:
+The <tt>DefaultConstructible</tt> requirement is referenced in
+several places in the August 2007 working draft
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf">N2369</a>,
+but is not defined anywhere.
 </p>
 
-<blockquote>
-<pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre>
-</blockquote>
+<p><i>[
+Bellevue:
+]</i></p>
 
-<p><b><tt>unordered_multimap</tt></b></p>
 
+<blockquote>
 <p>
-Change 23.5.2 [unord.multimap]:
+Walking into the default/value-initialization mess...
 </p>
+<p>
+Why two lines? Because we need both expressions to be valid.
+</p>
+<p>
+AJM not sure what the phrase "default constructed" means. This is
+unfortunate, as the phrase is already used 24 times in the library!
+</p>
+<p>
+Example: const int would not accept first line, but will accept the second.
+</p>
+<p>
+This is an issue that must be solved by concepts, but we might need to solve it independantly first.
+</p>
+<p>
+It seems that the requirements are the syntax in the proposed first
+column is valid, but not clear what semantics we need.
+</p>
+<p>
+A table where there is no post-condition seems odd, but appears to sum up our position best.
+</p>
+<p>
+At a minimum an object is declared and is destuctible.
+</p>
+<p>
+Move to open, as no-one happy to produce wording on the fly.
+</p>
+</blockquote>
 
-<blockquote><pre>class unordered_multimap
-{
-    ...
-    unordered_multimap(const unordered_multimap&amp;);
-    <ins>unordered_multimap(unordered_multimap&amp;&amp;);</ins>
-    ~unordered_multimap();
-    unordered_multimap&amp; operator=(const unordered_multimap&amp;);
-    <ins>unordered_multimap&amp; operator=(unordered_multimap&amp;&amp;);</ins>
-    ...
-    // modifiers 
-    iterator insert(const value_type&amp; obj); 
-    <ins>template &lt;class P&gt; iterator insert(P&amp;&amp; obj);</ins>
-    iterator       insert(iterator hint, const value_type&amp; obj);
-    <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; obj);</ins>
-    const_iterator insert(const_iterator hint, const value_type&amp; obj);
-    <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
-    ...
-    void swap(unordered_multimap&amp;<ins>&amp;</ins>);
-    ...
-};
-
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
+<p><i>[
+2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
+]</i></p>
 
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
 
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre></blockquote>
+<p><i>[
+2009-08-17 Daniel adds "[defaultconstructible]" to table title.  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>
+depends upon this issue.
+]</i></p>
 
-<p>
-Add to 23.5.2.1 [unord.multimap.cnstr]:
-</p>
 
-<blockquote>
-<pre>template &lt;class InputIterator&gt;
-  unordered_multimap(InputIterator f, InputIterator l, 
-                size_type n = <i>implementation-defined</i>, 
-                const hasher&amp; hf = hasher(), 
-                const key_equal&amp; eql = key_equal(), 
-                const allocator_type&amp; a = allocator_type());
-</pre>
+<p><i>[
+2009-08-18 Alisdair adds:
+]</i></p>
 
-<blockquote><p>
-<ins>
-<i>Requires:</i> If the iterator's dereference operator returns an
-lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
-then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
-<tt>CopyConstructible</tt>.
-</ins>
-</p></blockquote>
-</blockquote>
 
+<blockquote>
 <p>
-Add new section [unord.multimap.modifiers]:
+Looking at the proposed table in this issue, it really needs two rows:
 </p>
 
 <blockquote>
-<pre><ins>iterator insert(const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; iterator       insert(P&amp;&amp; x);</ins>
-<ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
-<ins>template &lt;class InputIterator&gt;
-  void insert(InputIterator first, InputIterator last);</ins>
-</pre>
-
-<blockquote>
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
-requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
-<tt>CopyConstructible</tt>.
-</ins></p>
-
-<p><ins>
-<tt>P</tt> shall be convertible to <tt>value_type</tt>.
- If <tt>P</tt> is instantiated as a reference
-type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
-is considered to be an rvalue as it is converted to <tt>value_type</tt>
-and inserted into the <tt>unordered_multimap</tt>. Specifically, in such
-cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
-<tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
-requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
-mapped_type&gt;</tt>, then <tt>key_type</tt> must be
-<tt>CopyConstructible</tt>).
-</ins></p>
+<table border="1">
+<caption>Table 33: <tt>DefaultConstructible</tt> requirements [defaultconstructible]</caption>
+<tbody><tr>
+<th>expression</th><th>post-condition</th>
+</tr>
 
-<p><ins>
-The signature taking <tt>InputIterator</tt>
-parameters requires <tt>CopyConstructible</tt> of both
-<tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
-<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
-<tt>value_type</tt>.
-</ins></p>
-</blockquote>
+<tr>
+<td><tt>T t;</tt></td><td><tt>t</tt> is default-initialized.</td>
+</tr>
 
+<tr>
+<td><tt>T{}</tt></td><td>Object of type <tt>T</tt> is value-initialized.</td>
+</tr>
+</tbody></table>
 </blockquote>
 
 <p>
-Add to 23.5.2.2 [unord.multimap.swap]:
+Note I am using the new brace-initialization syntax that is unambiguous
+in all use cases (no most vexing parse.)
 </p>
-
-<blockquote>
-<pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre>
 </blockquote>
 
-<p><b><tt>unordered_set</tt></b></p>
+<p><i>[
+2009-10-03 Daniel adds:
+]</i></p>
 
+
+<blockquote>
 <p>
-Change 23.5.3 [unord.set]:
+The suggested definition <tt>T{}</tt> describing it as
+value-initialization is wrong, because it belongs to list-initialization
+which would - as the current rules are - always prefer a
+initializer-list constructor over a default-constructor. I don't
+consider this as an appropriate definition of
+<tt>DefaultConstructible</tt>. My primary suggestion is to ask core,
+whether the special case <tt>T{}</tt> (which also easily leads to
+ambiguity situations for more than one initializer-list in a class)
+would always prefer a default-constructor - if any - before considering
+an initializer-list constructor or to provide another syntax form to
+prefer value-initialization over list-initialization. If that fails I
+would fall back to suggest to use the expression <tt>T()</tt> instead of
+<tt>T{}</tt> with all it's disadvantages for the meaning of the
+expression
 </p>
 
-<blockquote><pre>class unordered_set
-{
-    ...
-    unordered_set(const unordered_set&amp;);
-    <ins>unordered_set(unordered_set&amp;&amp;);</ins>
-    ~unordered_set();
-    unordered_set&amp; operator=(const unordered_set&amp;);
-    <ins>unordered_set&amp; operator=(unordered_set&amp;&amp;);</ins>
-    ...
-    // modifiers 
-    <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj); 
-    <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; obj);</ins>
-    iterator       insert(iterator hint, const value_type&amp; obj);
-    <ins>iterator       insert(iterator hint, value_type&amp;&amp; obj);</ins>
-    const_iterator insert(const_iterator hint, const value_type&amp; obj);
-    <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
-    ...
-    void swap(unordered_set&amp;<ins>&amp;</ins>);
-    ...
-};
-
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
+<blockquote><pre>T t();
 </pre></blockquote>
+</blockquote>
 
-<p>
-Add to 23.5.3.1 [unord.set.cnstr]:
-</p>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
-<blockquote>
-<pre>template &lt;class InputIterator&gt;
-  unordered_set(InputIterator f, InputIterator l, 
-                size_type n = <i>implementation-defined</i>, 
-                const hasher&amp; hf = hasher(), 
-                const key_equal&amp; eql = key_equal(), 
-                const allocator_type&amp; a = allocator_type());
-</pre>
 
-<blockquote><p>
-<ins>
-<i>Requires:</i> If the iterator's dereference operator returns an
-lvalue or a const rvalue <tt>value_type</tt>, then the
-<tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
-</ins>
-</p></blockquote>
+<blockquote>
+Leave Open. Core is looking to make Alisdair's proposed
+resolution correct.
 </blockquote>
 
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-Add new section [unord.set.modifiers]:
+In section 20.2.1 [utility.arg.requirements], before table 33, add the
+following table:
 </p>
 
-<blockquote>
-<pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
-<ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; x);</ins>
-<ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
-<ins>iterator       insert(iterator hint, value_type&amp;&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
-<ins>template &lt;class InputIterator&gt;
-  void insert(InputIterator first, InputIterator last);</ins>
-</pre>
+<p style="text-align: center;" align="center">Table 33: <tt>DefaultConstructible</tt> requirements [defaultconstructible]</p>
 
-<blockquote>
+<div align="center">
 
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const
-value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
-be <tt>CopyConstructible</tt>.
-</ins></p>
+<table style="border-collapse: collapse;" border="0" cellpadding="0" cellspacing="0">
+ <tbody><tr>
+  <td style="border-style: solid none double solid; border-color: navy -moz-use-text-color navy navy; border-width: 1pt medium 1.5pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
+  <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">expression</p>
+  </td>
+  <td style="border-style: solid solid double none; border-color: navy navy navy -moz-use-text-color; border-width: 1pt 1pt 1.5pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
+  <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">post-condition</p>
+  </td>
+ </tr>
+ <tr>
+  <td style="border-style: none none solid solid; border-color: -moz-use-text-color -moz-use-text-color navy navy; border-width: medium medium 1pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
+  <p style="margin: 0in 0in 0.0001pt;"><tt>T
+  t;</tt><br>
+  <tt>T()</tt></p>
+  </td>
+  <td style="border-style: none solid solid none; border-color: -moz-use-text-color navy navy -moz-use-text-color; border-width: medium 1pt 1pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
+  <p style="margin: 0in 0in 0.0001pt;"><tt>T</tt>
+  is <i>default constructed.</i></p>
+  </td>
+ </tr>
+</tbody></table>
 
-<p><ins>
-The signature taking <tt>InputIterator</tt> parameters requires
-<tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
-<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
-<tt>value_type</tt>.
-</ins></p>
+</div>
 
-</blockquote>
 
-</blockquote>
 
-<p>
-Add to 23.5.3.2 [unord.set.swap]:
-</p>
+<p><b>Rationale:</b></p>
+<p><i>[
+San Francisco:
+]</i></p>
 
 <blockquote>
-<pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre>
+We believe concepts will solve this problem
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>).
 </blockquote>
 
-<p><b><tt>unordered_multiset</tt></b></p>
-
-<p>
-Change 23.5.4 [unord.multiset]:
-</p>
-
-<blockquote><pre>class unordered_multiset
-{
-    ...
-    unordered_multiset(const unordered_multiset&amp;);
-    <ins>unordered_multiset(unordered_multiset&amp;&amp;);</ins>
-    ~unordered_multiset();
-    unordered_multiset&amp; operator=(const unordered_multiset&amp;);
-    <ins>unordered_multiset&amp; operator=(unordered_multiset&amp;&amp;);</ins>
-    ...
-    // modifiers 
-    iterator insert(const value_type&amp; obj); 
-    <ins>iterator insert(value_type&amp;&amp; obj);</ins>
-    iterator       insert(iterator hint, const value_type&amp; obj);
-    <ins>iterator       insert(iterator hint, value_type&amp;&amp; obj);</ins>
-    const_iterator insert(const_iterator hint, const value_type&amp; obj);
-    <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
-    ...
-    void swap(unordered_multiset&amp;<ins>&amp;</ins>);
-    ...
-};
 
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
 
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
 
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre></blockquote>
 
+<hr>
+<h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3>
+<p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-09-22  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Add to 23.5.4.1 [unord.multiset.cnstr]:
+Two overloads of <tt>regex_replace()</tt> are currently provided:
 </p>
 
-<blockquote>
-<pre>template &lt;class InputIterator&gt;
-  unordered_multiset(InputIterator f, InputIterator l, 
-                size_type n = <i>implementation-defined</i>, 
-                const hasher&amp; hf = hasher(), 
-                const key_equal&amp; eql = key_equal(), 
-                const allocator_type&amp; a = allocator_type());
-</pre>
-
-<blockquote><p>
-<ins>
-<i>Requires:</i> If the iterator's dereference operator returns an
-lvalue or a const rvalue <tt>value_type</tt>, then the
-<tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
-</ins>
-</p></blockquote>
-</blockquote>
+<blockquote><pre>template &lt;class OutputIterator, class BidirectionalIterator, 
+    class traits, class charT&gt; 
+  OutputIterator 
+  regex_replace(OutputIterator out, 
+                BidirectionalIterator first, BidirectionalIterator last, 
+                const basic_regex&lt;charT, traits&gt;&amp; e, 
+                const basic_string&lt;charT&gt;&amp; fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+ 
+template &lt;class traits, class charT&gt; 
+  basic_string&lt;charT&gt; 
+  regex_replace(const basic_string&lt;charT&gt;&amp; s, 
+                const basic_regex&lt;charT, traits&gt;&amp; e, 
+                const basic_string&lt;charT&gt;&amp; fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+</pre></blockquote>
 
-<p>
-Add new section [unord.multiset.modifiers]:
-</p>
+<ol>
+<li>Overloads taking <tt>const charT *</tt> are provided for <tt>regex_match()</tt> and
+<tt>regex_search()</tt>, but not <tt>regex_replace()</tt>.  This is inconsistent.</li>
+<li>
+<p>The absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p>
 
-<blockquote>
-<pre><ins>iterator insert(const value_type&amp; x);</ins>
-<ins>iterator insert(value_type&amp;&amp; x);</ins>
-<ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
-<ins>iterator       insert(iterator hint, value_type&amp;&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
-<ins>template &lt;class InputIterator&gt;
-  void insert(InputIterator first, InputIterator last);</ins>
-</pre>
+<blockquote><pre>const string s("kitten");
+const regex r("en");
+cout &lt;&lt; regex_replace(s, r, "y") &lt;&lt; endl;
+</pre></blockquote>
 
-<blockquote>
+<p>
+The compiler error message will be something like "could not deduce
+template argument for 'const std::basic_string&lt;_Elem&gt; &amp;' from 'const
+char[1]'".
+</p>
 
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const
-value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
-be <tt>CopyConstructible</tt>.
-</ins></p>
+<p>
+Users expect that anything taking a <tt>basic_string&lt;charT&gt;</tt> can also take a
+<tt>const charT *</tt>.  In their own code, when they write a function taking
+<tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const
+wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor.  Because the
+regex algorithms are templated on <tt>charT</tt>, they can't rely on
+<tt>basic_string</tt>'s implicit constructor (as the compiler error message
+indicates, template argument deduction fails first).
+</p>
 
-<p><ins>
-The signature taking <tt>InputIterator</tt> parameters requires
-<tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
-<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
-<tt>value_type</tt>.
-</ins></p>
+<p>
+If a user figures out what the compiler error message means, workarounds
+are available - but they are all verbose.  Explicit template arguments
+could be given to <tt>regex_replace()</tt>, allowing <tt>basic_string</tt>'s implicit
+constructor to be invoked - but <tt>charT</tt> is the last template argument, not
+the first, so this would be extremely verbose.  Therefore, constructing
+a <tt>basic_string</tt> from each C string is the simplest workaround.
+</p>
+</li>
 
-</blockquote>
+<li>
+There is an efficiency consideration: constructing <tt>basic_string</tt>s can
+impose performance costs that could be avoided by a library
+implementation taking C strings and dealing with them directly. 
+(Currently, for replacement sources, C strings can be converted into
+iterator pairs at the cost of verbosity, but for format strings, there
+is no way to avoid constructing a <tt>basic_string</tt>.)
+</li>
+</ol>
 
-</blockquote>
+<p><i>[
+Sophia Antipolis:
+]</i></p>
 
-<p>
-Add to 23.5.4.2 [unord.multiset.swap]:
-</p>
 
 <blockquote>
-<pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre>
+We note that Boost already has these overloads. However, the proposed
+wording is provided only for 28.11.4 [re.alg.replace]; wording is needed for the synopsis
+as well. We also note that this has impact on <tt>match_results::format</tt>,
+which may require further overloads.
 </blockquote>
 
-
-
 <p><i>[
-Voted to WP in Bellevue.
+2009-07 Frankfurt:
 ]</i></p>
 
 
+<blockquote>
+Daniel to tweak for us.
+</blockquote>
+
 <p><i>[
-post Bellevue, Pete notes:
+2009-07-25 Daniel tweaks both this issue and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>.
 ]</i></p>
 
 
 <blockquote>
 <p>
-Please remind people who are reviewing issues to check that the text
-modifications match the current draft. Issue 676, for example, adds two
-overloads for unordered_map::insert taking a hint. One takes a
-const_iterator and returns a const_iterator, and the other takes an
-iterator and returns an iterator. This was correct at the time the issue
-was written, but was changed in Toronto so there is only one hint
-overload, taking a const_iterator and returning an iterator.
-</p>
-<p>
-This issue is not ready. In addition to the relatively minor signature
-problem I mentioned earlier, it puts requirements in the wrong places.
-Instead of duplicating requirements throughout the template
-specifications, it should put them in the front matter that talks about
-requirements for unordered containers in general. This presentation
-problem is editorial, but I'm not willing to do the extensive rewrite
-that it requires. Please put it back into Open status.
+This is solved by the proposed resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>.
 </p>
 </blockquote>
 
-<p><b>Rationale:</b></p>
 <p><i>[
-San Francisco:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Solved by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
+Leave Open. Though we believe this is solved by the proposed resolution
+to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Provide additional overloads for <tt>regex_replace()</tt>: one additional
+overload of the iterator-based form (taking <tt>const charT* fmt</tt>), and three
+additional overloads of the convenience form (one taking <tt>const charT*
+str</tt>, another taking <tt>const charT* fmt</tt>, and the third taking both <tt>const
+charT* str</tt> and <tt>const charT* fmt</tt>).  28.11.4 [re.alg.replace]:
+</p>
+
+<blockquote>
+<pre>template &lt;class OutputIterator, class BidirectionalIterator, 
+    class traits, class charT&gt; 
+  OutputIterator 
+  regex_replace(OutputIterator out, 
+                BidirectionalIterator first, BidirectionalIterator last, 
+                const basic_regex&lt;charT, traits&gt;&amp; e, 
+                const basic_string&lt;charT&gt;&amp; fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+
+<ins>template &lt;class OutputIterator, class BidirectionalIterator, 
+    class traits, class charT&gt; 
+  OutputIterator 
+  regex_replace(OutputIterator out, 
+                BidirectionalIterator first, BidirectionalIterator last, 
+                const basic_regex&lt;charT, traits&gt;&amp; e, 
+                const charT* fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);</ins>
+</pre>
+<p>...</p>
+<pre>template &lt;class traits, class charT&gt; 
+  basic_string&lt;charT&gt; 
+  regex_replace(const basic_string&lt;charT&gt;&amp; s, 
+                const basic_regex&lt;charT, traits&gt;&amp; e, 
+                const basic_string&lt;charT&gt;&amp; fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+
+<ins>template &lt;class traits, class charT&gt; 
+  basic_string&lt;charT&gt; 
+  regex_replace(const basic_string&lt;charT&gt;&amp; s, 
+                const basic_regex&lt;charT, traits&gt;&amp; e, 
+                const charT* fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);</ins>
+
+<ins>template &lt;class traits, class charT&gt; 
+  basic_string&lt;charT&gt; 
+  regex_replace(const charT* s, 
+                const basic_regex&lt;charT, traits&gt;&amp; e, 
+                const basic_string&lt;charT&gt;&amp; fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);</ins>
+
+<ins>template &lt;class traits, class charT&gt; 
+  basic_string&lt;charT&gt; 
+  regex_replace(const charT* s, 
+                const basic_regex&lt;charT, traits&gt;&amp; e, 
+                const charT* fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);</ins>
+</pre>
 </blockquote>
 
 
@@ -6747,43 +5098,28 @@ Solved by
 
 
 <hr>
-<h3><a name="696"></a>696. <code>istream::operator&gt;&gt;(int&amp;)</code> broken</h3>
-<p><b>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-23  <b>Last modified:</b> 2009-07-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="727"></a>727. <tt>regex_replace()</tt> doesn't accept <tt>basic_string</tt>s with custom traits and allocators</h3>
+<p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-09-22  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-From message c++std-lib-17897:
-</p>
-<p>
-The code shown in 27.7.1.2.2 [istream.formatted.arithmetic] as the "as if"
-implementation of the two arithmetic extractors that don't have a
-corresponding <code>num_get</code> interface (i.e., the
-<code>short</code> and <code>int</code> overloads) is subtly buggy in
-how it deals with <code>EOF</code>, overflow, and other similar
-conditions (in addition to containing a few typos).
-</p>
-<p>
-One problem is that if <code>num_get::get()</code> reaches the EOF
-after reading in an otherwise valid value that exceeds the limits of
-the narrower type (but not <code>LONG_MIN</code> or
-<code>LONG_MAX</code>), it will set <code><i>err</i></code> to
-<code>eofbit</code>. Because of the if condition testing for
-<code>(<i>err</i> == 0)</code>, the extractor won't set
-<code>failbit</code> (and presumably, return a bogus value to the
-caller).
+<tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string&lt;charT, ST,
+SA&gt;&amp;</tt>.  <tt>regex_replace()</tt> takes <tt>const basic_string&lt;charT&gt;&amp;</tt>.  This prevents
+<tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
+allocators.
 </p>
+
 <p>
-Another problem with the code is that it never actually sets the
-argument to the extracted value. It can't happen after the call to
-<code>setstate()</code> since the function may throw, so we need to
-show when and how it's done (we can't just punt as say: "it happens
-afterwards"). However, it turns out that showing how it's done isn't
-quite so easy since the argument is normally left unchanged by the
-facet on error except when the error is due to a misplaced thousands
-separator, which causes <code>failbit</code> to be set but doesn't
-prevent the facet from storing the value.
+Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally
+templated on <tt>class ST, class SA</tt> and take <tt>const basic_string&lt;charT, ST,
+SA&gt;&amp;</tt>.  Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place
+<tt>class ST, class SA</tt> as the first template arguments; compatibility with
+existing code using TR1 and giving explicit template arguments to
+<tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template
+arguments.
 </p>
 
 <p><i>[
@@ -6792,369 +5128,431 @@ Batavia (2009-05):
 
 <blockquote>
 <p>
-We believe this part of the Standard has been recently adjusted
-and that this issue was addressed during that rewrite.
+Bill comments, "We need to look at the depth of this change."
 </p>
 <p>
-Move to NAD.
+Pete remarks that we are here dealing with a convenience function
+that saves a user from calling the iterato-based overload.
+</p>
+<p>
+Move to Open.
 </p>
 </blockquote>
 
 <p><i>[
-2009-05-28 Howard adds:
+2009-07 Frankfurt:
 ]</i></p>
 
 
 <blockquote>
-<p>
-I've moved this issue from Tentatively NAD to Open.
-</p>
+Howard to ask Stephan Lavavej to provide wording.
+</blockquote>
 
-<p>
-The current wording of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
-in 22.4.2.1.2 [facet.num.get.virtuals] p3, stage 3 appears to indicate that
-in parsing arithmetic types, the value is always set, but sometimes in addition
-to setting <tt>failbit</tt>.
-</p>
+<p><i>[
+2009-07-17 Stephan provided wording.
+]</i></p>
 
-<ul>
-<li>
-If there is a range error, the value is set to min or max, else
-</li>
-<li>
-if there is a conversion error, the value is set to 0, else
-</li>
-<li>
-if there is a grouping error, the value is set to whatever it would be if grouping were ignored, else
-</li>
-<li>
-the value is set to its error-free result.
-</li>
-</ul>
 
-<p>
-However there is a contradictory sentence in 22.4.2.1.2 [facet.num.get.virtuals] p1.
-</p>
+<p><i>[
+2009-07-25 Daniel tweaks both this issue and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>.
+]</i></p>
+
+
+<blockquote>
+<p>
+One relevant part of the proposed resolution below suggests
+to add a new overload of the format member function in the
+<tt>match_results</tt> class template that accepts two character pointers
+defining the <tt>begin</tt> and <tt>end</tt> of a format range. A more general
+approach could have proposed a pair of iterators instead, but
+the used pair of char pointers reflects existing practice. If the
+committee strongly favors an iterator-based signature, this
+could be simply changed. I think that the minimum requirement
+should be a <tt>BidirectionalIterator</tt>, but current implementations
+take advantage (at least partially) of the <tt>RandomAccessIterator</tt>
+sub interface of the char pointers.
+</p>
+
+<p><b>Suggested Resolution:</b></p>
+
+<p><i>[Moved into the proposed resloution]</i></p>
+
 
-<p>
-27.7.1.2.2 [istream.formatted.arithmetic] should mimic the behavior of 22.4.2.1.2 [facet.num.get.virtuals]
-(whatever we decide that behavior is) for
-<tt>int</tt> and <tt>short</tt>, and currently does not.  I believe that the
-correct code fragment should look like:
-</p>
 
-<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
-iostate err = ios_base::goodbit;
-long lval;
-use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval);
-if (lval &lt; numeric_limits&lt;int&gt;::min())
-{
-  err |= ios_base::failbit;
-  val = numeric_limits&lt;int&gt;::min();
-}
-else if (lval &gt; numeric_limits&lt;int&gt;::max())
-{
-  err |= ios_base::failbit;
-  val = numeric_limits&lt;int&gt;::max();
-}
-else
-  val = static_cast&lt;int&gt;(lval);
-setstate(err);
-</pre></blockquote>
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt
+2009-07-30 Stephan agrees with Daniel's wording.  Howard places Daniel's wording
+in the Proposed Resolution.
+]</i></p>
+
+
+<p><i>[
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Move to Ready.
+Move to Review. Chair is anxious to move this to Ready in Pittsburgh.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
+
+<ol>
+<li>
 <p>
-Change 22.4.2.1.2 [facet.num.get.virtuals], p1:
+Change 28.4 [re.syn] as indicated:
 </p>
 
-<blockquote>
--1- <i>Effects:</i> Reads characters from <tt>in</tt>, interpreting them
-according to <tt>str.flags()</tt>, <tt>use_facet&lt;ctype&lt;charT&gt;
-&gt;(loc)</tt>, and <tt>use_facet&lt; numpunct&lt;charT&gt;
-&gt;(loc)</tt>, where <tt>loc</tt> is <tt>str.getloc()</tt>. <del>If an error
-occurs, <tt>val</tt> is unchanged; otherwise it is set to the resulting value.</del>
-</blockquote>
+<blockquote><pre>// 28.11.4, function template regex_replace:
+template &lt;class OutputIterator, class BidirectionalIterator,
+          class traits, class charT<ins>, class ST, class SA</ins>&gt;
+  OutputIterator
+  regex_replace(OutputIterator out,
+                BidirectionalIterator first, BidirectionalIterator last,
+                const basic_regex&lt;charT, traits&gt;&amp; e,
+                const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; fmt,
+                regex_constants::match_flag_type flags =
+                  regex_constants::match_default);
+
+<ins>
+template &lt;class OutputIterator, class BidirectionalIterator,
+          class traits, class charT&gt;
+  OutputIterator
+  regex_replace(OutputIterator out,
+                BidirectionalIterator first, BidirectionalIterator last,
+                const basic_regex&lt;charT, traits&gt;&amp; e,
+                const charT* fmt,
+                regex_constants::match_flag_type flags =
+                  regex_constants::match_default);
+</ins>
+
+template &lt;class traits, class charT<ins>, class ST, class SA,
+          class FST, class FSA</ins>&gt;
+  basic_string&lt;charT<ins>, ST, SA</ins>&gt;
+  regex_replace(const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; s,
+                const basic_regex&lt;charT, traits&gt;&amp; e,
+                const basic_string&lt;charT<ins>, FST, FSA</ins>&gt;&amp; fmt,
+                regex_constants::match_flag_type flags =
+                  regex_constants::match_default);
+
+<ins>
+template &lt;class traits, class charT, class ST, class SA&gt;
+  basic_string&lt;charT, ST, SA&gt;
+  regex_replace(const basic_string&lt;charT, ST, SA&gt;&amp; s,
+                const basic_regex&lt;charT, traits&gt;&amp; e,
+                const charT* fmt,
+                regex_constants::match_flag_type flags =
+                  regex_constants::match_default);
+</ins>
+
+<ins>
+template &lt;class traits, class charT, class ST, class SA&gt;
+  basic_string&lt;charT&gt;
+  regex_replace(const charT* s,
+                const basic_regex&lt;charT, traits&gt;&amp; e,
+                const basic_string&lt;charT, ST, SA&gt;&amp; fmt,
+                regex_constants::match_flag_type flags =
+                  regex_constants::match_default);
+</ins>
+
+<ins>
+template &lt;class traits, class charT&gt;
+  basic_string&lt;charT&gt;
+  regex_replace(const charT* s,
+                const basic_regex&lt;charT, traits&gt;&amp; e,
+                const charT* fmt,
+                regex_constants::match_flag_type flags =
+                  regex_constants::match_default);
+</ins>
+</pre></blockquote>
+</li>
 
+<li>
 <p>
-Change 27.7.1.2.2 [istream.formatted.arithmetic], p2 and p3:
+Change 28.10 [re.results]/3, class template <tt>match_results</tt> as
+indicated:
 </p>
 
-<blockquote>
-<pre>operator&gt;&gt;(short&amp; val);
-</pre>
-<blockquote>
+<blockquote><pre><ins>
+template &lt;class OutputIter&gt;
+  OutputIter
+  format(OutputIter out,
+         const char_type* fmt_first, const char_type* fmt_last,
+         regex_constants::match_flag_type flags =
+           regex_constants::format_default) const;
+</ins>
+
+template &lt;class OutputIter<ins>, class ST, class SA</ins>&gt;
+  OutputIter
+  format(OutputIter out,
+         const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
+         regex_constants::match_flag_type flags =
+           regex_constants::format_default) const;
+
+<ins>template &lt;class ST, class SA&gt;</ins>
+  <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>
+  format(const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
+         regex_constants::match_flag_type flags =
+           regex_constants::format_default) const;
+
+<ins>
+string_type
+format(const char_type* fmt,
+       regex_constants::match_flag_type flags =
+         regex_constants::format_default) const;
+</ins>
+</pre></blockquote>
+</li>
+
+<li>
 <p>
--2- The conversion occurs as if performed by the following code fragment (using the same notation as for 
-the preceding code fragment):
+Insert at the very beginning of 28.10.4 [re.results.form] the following:
 </p>
 
-<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
-iostate err = ios<del>tate</del><ins>_base</ins>::goodbit;
-long lval;
-use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval);
-<del>if (err != 0)
-  ;
-else if (lval &lt; numeric_limits&lt;short&gt;::min()
-  || numeric_limits&lt;short&gt;::max() &lt; lval)
-     err = ios_base::failbit;</del>
-<ins>if (lval &lt; numeric_limits&lt;short&gt;::min())
-{
-  err |= ios_base::failbit;
-  val = numeric_limits&lt;short&gt;::min();
-}
-else if (lval &gt; numeric_limits&lt;short&gt;::max())
-{
-  err |= ios_base::failbit;
-  val = numeric_limits&lt;short&gt;::max();
-}</ins>
-else
-  val = static_cast&lt;short&gt;(lval);
-setstate(err);
-</pre></blockquote>
+<blockquote><pre><ins>
+template &lt;class OutputIter&gt;
+  OutputIter
+  format(OutputIter out,
+         const char_type* fmt_first, const char_type* fmt_last,
+         regex_constants::match_flag_type flags =
+           regex_constants::format_default) const;
+</ins>
+</pre>
+<blockquote>
+
+<p><ins>
+1 <i>Requires:</i> The type <tt>OutputIter</tt> shall satisfy the requirements for an
+Output Iterator (24.2.2 [output.iterators]).
+</ins></p>
+
+<p><ins>
+2 <i>Effects:</i> Copies the character sequence <tt>[fmt_first,fmt_last)</tt> to
+<tt>OutputIter out</tt>. Replaces each
+format specifier or escape sequence in the copied range with either
+the character(s) it represents
+or the sequence of characters within <tt>*this</tt> to which it refers. The
+bitmasks specified in <tt>flags</tt>
+determines what format specifiers and escape sequences are recognized.
+</ins></p>
 
+<p><ins>
+3 <i>Returns:</i> <tt>out</tt>.
+</ins></p>
 </blockquote>
+</blockquote>
+</li>
+
+<li>
+<p>
+Change 28.10.4 [re.results.form], before p. 1 until p. 3 (according to
+previous numbering)
+as indicated:
+</p>
 
-<pre>operator&gt;&gt;(int&amp; val);
+<blockquote><pre>template &lt;class OutputIter<ins>, class ST, class SA</ins>&gt;
+  OutputIter
+  format(OutputIter out,
+         const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
+         regex_constants::match_flag_type flags =
+           regex_constants::format_default) const;
 </pre>
+
 <blockquote>
 <p>
--3- The conversion occurs as if performed by the following code fragment (using the same notation as for 
-the preceding code fragment):
+<del><i>Requires:</i> The type <tt>OutputIter</tt> shall satisfy the requirements for
+an Output Iterator (24.2.3).</del>
 </p>
 
-<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
-iostate err = ios<del>tate</del><ins>_base</ins>::goodbit;
-long lval;
-use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval);
-<del>if (err != 0)
-  ;
-else if (lval &lt; numeric_limits&lt;int&gt;::min()
-  || numeric_limits&lt;int&gt;::max() &lt; lval)
-     err = ios_base::failbit;</del>
-<ins>if (lval &lt; numeric_limits&lt;int&gt;::min())
-{
-  err |= ios_base::failbit;
-  val = numeric_limits&lt;int&gt;::min();
-}
-else if (lval &gt; numeric_limits&lt;int&gt;::max())
-{
-  err |= ios_base::failbit;
-  val = numeric_limits&lt;int&gt;::max();
-}</ins>
-else
-  val = static_cast&lt;int&gt;(lval);
-setstate(err);
-</pre></blockquote>
+<p>
+<del><i>Effects:</i> Copies the character sequence <tt>[fmt.begin(),fmt.end())</tt> to
+<tt>OutputIter out</tt>. Replaces each
+format specifier or escape sequence in <tt>fmt</tt> with either the
+character(s) it represents or the sequence of
+characters within <tt>*this</tt> to which it refers. The bitmasks specified in
+<tt>flags</tt> determines what format
+specifiers and escape sequences are recognized.</del>
+</p>
 
+<p>
+<i>Returns:</i> <tt><del>out</del><ins>format(out, fmt.data(), fmt.data() +
+fmt.size(), flags)</ins></tt>.
+</p>
 </blockquote>
-
 </blockquote>
+</li>
 
+<li>
+<p>
+Change 28.10.4 [re.results.form], before p. 4 until p. 4 (according to
+previous numbering) as indicated:
+</p>
 
+<blockquote><pre><ins>template &lt;class ST, class SA&gt;</ins>
+  <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>
+  format(const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
+         regex_constants::match_flag_type flags =
+           regex_constants::format_default) const;
+</pre>
 
+<blockquote>
+<p>
+<i>Effects:</i> <del>Returns a copy of the string <tt>fmt</tt>. Replaces each format
+specifier or escape sequence
+in <tt>fmt</tt> with either the character(s) it represents or the sequence of
+characters within <tt>*this</tt> to which
+it refers. The bitmasks specified in flags determines what format
+specifiers and escape sequences are
+recognized.</del> <ins>Constructs an empty string <tt>result</tt> of type
+<tt>basic_string&lt;char_type, ST, SA&gt;</tt>,
+and calls <tt>format(back_inserter(result), fmt, flags)</tt>.</ins>
+</p>
 
-
-<hr>
-<h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</h3>
-<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-20  <b>Last modified:</b> 2009-07-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-The move-related changes inadvertently overwrote the intent of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a> removed the requirement of <tt>CopyAssignable</tt> from
-most of the member functions of node-based containers.  But the move-related changes
-unnecessarily introduced the <tt>MoveAssignable</tt> requirement for those members which used to
-require <tt>CopyAssignable</tt>.
+<ins><i>Returns:</i> <tt>result</tt></ins>
 </p>
+</blockquote>
+</blockquote>
+</li>
 
+<li>
 <p>
-We also discussed (c++std-lib-18722) the possibility of dropping <tt>MoveAssignable</tt>
-from some of the sequence requirements.  Additionally the <i>in-place</i> construction
-work may further reduce requirements.  For purposes of an easy reference, here are the
-minimum sequence requirements as I currently understand them.  Those items in requirements
-table in the working draft which do not appear below have been purposefully omitted for
-brevity as they do not have any requirements of this nature.  Some items which do not
-have any requirements of this nature are included below just to confirm that they were
-not omitted by mistake.
+At the end of 28.10.4 [re.results.form] insert as indicated:
 </p>
 
-<table border="1">
-<caption>Container Requirements</caption>
-<tbody><tr><td><tt>X u(a)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
-<tr><td><tt>X u(rv)</tt></td><td><tt>array</tt> and containers with a <tt>propagate_never</tt> allocator require <tt>value_type</tt> to be <tt>MoveConstructible</tt></td></tr>
-<tr><td><tt>a = u</tt></td><td>Sequences require <tt>value_type</tt> to be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
-                               Associative containers require <tt>value_type</tt> to be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a = rv</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveAssignable</tt>.
-                                Sequences and Associative containers with <tt>propagate_never</tt> and <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>swap(a,u)</tt></td><td><tt>array</tt> and containers with <tt>propagate_never</tt> and
-                  <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>Swappable</tt>.</td></tr>
-</tbody></table>
+<blockquote><pre><ins>
+string_type
+  format(const char_type* fmt,
+         regex_constants::match_flag_type flags =
+           regex_constants::format_default) const;
+</ins></pre>
 
+<blockquote>
 <p>
+<ins><i>Effects:</i> Constructs an empty string <tt>result</tt> of type <tt>string_type</tt>, and calls
+<tt>format(back_inserter(result), fmt, fmt +
+char_traits&lt;char_type&gt;::length(fmt), flags)</tt>.</ins>
 </p>
-
-<table border="1">
-<caption>Sequence Requirements</caption>
-<tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr>
-<tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
-<tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
-                                 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
-                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
-<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
-                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
-<tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
-                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
-<tr><td><tt>a.insert(p, i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
-                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt> when the iterators return an lvalue.
-                                        If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
-                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt> when the iterators return an rvalue.</td></tr>
-<tr><td><tt>a.erase(p)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
-<tr><td><tt>a.erase(q1, q2)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
-<tr><td><tt>a.clear()</tt></td><td></td></tr>
-<tr><td><tt>a.assign(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
-                                        If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
-<tr><td><tt>a.assign(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.</td></tr>
-<tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>.
-                                     The sequence <tt>vector</tt> also requires the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-</tbody></table>
-
 <p>
+<ins><i>Returns:</i> <tt>result</tt></ins>
 </p>
+</blockquote>
+</blockquote>
 
-<table border="1">
-<caption>Optional Sequence Requirements</caption>
-<tbody><tr><td><tt>a.front()</tt></td><td></td></tr>
-<tr><td><tt>a.back()</tt></td><td></td></tr>
-<tr><td><tt>a.push_front(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a.push_front(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.push_back(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a.push_back(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.pop_front()</tt></td><td></td></tr>
-<tr><td><tt>a.pop_back()</tt></td><td></td></tr>
-<tr><td><tt>a[n]</tt></td><td></td></tr>
-<tr><td><tt>a.at[n]</tt></td><td></td></tr>
-</tbody></table>
+</li>
 
+<li>
 <p>
+Change 28.11.4 [re.alg.replace] before p. 1 as indicated:
 </p>
 
-<table border="1">
-<caption>Associative Container Requirements</caption>
-<tbody><tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
-                                 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
-                                        If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
-</tbody></table>
+<blockquote><pre>template &lt;class OutputIterator, class BidirectionalIterator,
+          class traits, class charT<ins>, class ST, class SA</ins>&gt;
+  OutputIterator
+  regex_replace(OutputIterator out,
+                BidirectionalIterator first, BidirectionalIterator last,
+                const basic_regex&lt;charT, traits&gt;&amp; e,
+                const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; fmt,
+                regex_constants::match_flag_type flags =
+                  regex_constants::match_default);
 
-<p>
-</p>
+<ins>
+template &lt;class OutputIterator, class BidirectionalIterator,
+          class traits, class charT&gt;
+  OutputIterator
+  regex_replace(OutputIterator out,
+                BidirectionalIterator first, BidirectionalIterator last,
+                const basic_regex&lt;charT, traits&gt;&amp; e,
+                const charT* fmt,
+                regex_constants::match_flag_type flags =
+                  regex_constants::match_default);
+</ins></pre>
 
-<table border="1">
-<caption>Unordered Associative Container Requirements</caption>
-<tbody><tr><td><tt>X(i, j, n, hf, eq)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
-                                 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
-                                        If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
-</tbody></table>
+<blockquote>
+<i>Effects:</i> [..]. If any matches are found then, for each such match, if <tt>!(flags &amp;
+ regex_constants::format_no_copy)</tt> calls <tt>std::copy(m.prefix().first,
+m.prefix().second,
+ out)</tt>, and then calls <tt>m.format(out, fmt, flags)</tt> <ins>for the first
+form of the function
+ and <tt>m.format(out, fmt, fmt + char_traits&lt;charT&gt;::length(fmt), flags)</tt>
+for the second
+ form</ins>. [..].
+</blockquote>
+</blockquote>
+</li>
 
+<li>
 <p>
+Change 28.11.4 [re.alg.replace] before p. 3 as indicated:
 </p>
 
-<table border="1">
-<caption>Miscellaneous Requirements</caption>
-<tbody><tr><td><tt>map[lvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>CopyConstructible</tt>.
-                                         The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>map[rvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>MoveConstructible</tt>.
-                                         The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
-</tbody></table>
-
-<p><i>[
-Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
-]</i></p>
-
-
-<p><i>[
-Bellevue: This should be handled as part of the concepts work.
-]</i></p>
-
-
-<p><i>[
-2009-07-20 Reopened by Howard:
-]</i></p>
+<blockquote><pre>template &lt;class traits, class charT<ins>, class ST, class SA,
+          class FST, class FSA</ins>&gt;
+  basic_string&lt;charT<ins>, ST, SA</ins>&gt;
+  regex_replace(const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; s,
+                const basic_regex&lt;charT, traits&gt;&amp; e,
+                const basic_string&lt;charT<ins>, FST, FSA</ins>&gt;&amp; fmt,
+                regex_constants::match_flag_type flags =
+                  regex_constants::match_default);
 
+<ins>
+template &lt;class traits, class charT, class ST, class SA&gt;
+  basic_string&lt;charT, ST, SA&gt;
+  regex_replace(const basic_string&lt;charT, ST, SA&gt;&amp; s,
+                const basic_regex&lt;charT, traits&gt;&amp; e,
+                const charT* fmt,
+                regex_constants::match_flag_type flags =
+                  regex_constants::match_default);
+</ins></pre>
 
 <blockquote>
-<p>
-This is one of the issues that was "solved by concepts" and is now no longer solved.
-</p>
-
-<p>
-In a nutshell, concepts adopted the "minimum requirements" philosophy outlined
-in the discussion of this issue, and enforced it.  My strong suggestion is that
-we translate the concepts specification into documentation for the containers.
-</p>
-
-<p>
-What this means for vendors is that they will have to implement container members
-being careful to only use those characteristics of a type that the concepts specification
-formally allowed.  Note that I <em>am not</em> talking about <tt>enable_if</tt>'ing
-everything.  I am simply suggesting that (for example) we tell the vendor he can't call <tt>T's</tt>
-copy constructor or move constructor within the <tt>emplace</tt> member function, etc.
-</p>
+<i>Effects:</i> Constructs an empty string <tt>result</tt> of type <tt>basic_string&lt;charT<ins>,
+ST, SA</ins>&gt;</tt>, calls <tt>regex_replace(back_inserter(result), s.begin(), s.end(),
+e, fmt, flags)</tt>, and then returns <tt>result</tt>.
+</blockquote>
+</blockquote>
+</li>
 
+<li>
 <p>
-What this means for customers is that they will be able to use types within C++03
-containers which are sometimes not CopyConstructible, and sometimes not even
-MoveConstructible, etc.
+At the end of 28.11.4 [re.alg.replace] add the following new prototype description:
 </p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
 
+<blockquote><pre><ins>
+template &lt;class traits, class charT, class ST, class SA&gt;
+  basic_string&lt;charT&gt;
+  regex_replace(const charT* s,
+                const basic_regex&lt;charT, traits&gt;&amp; e,
+                const basic_string&lt;charT, ST, SA&gt;&amp; fmt,
+                regex_constants::match_flag_type flags =
+                  regex_constants::match_default);
+</ins>
 
-<p><b>Rationale:</b></p>
-<p><i>[
-post San Francisco:
-]</i></p>
-
+<ins>
+template &lt;class traits, class charT&gt;
+  basic_string&lt;charT&gt;
+  regex_replace(const charT* s,
+                const basic_regex&lt;charT, traits&gt;&amp; e,
+                const charT* fmt,
+                regex_constants::match_flag_type flags =
+                  regex_constants::match_default);
+</ins></pre>
 
 <blockquote>
-Solved by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
+<ins>
+<i>Effects:</i> Constructs an empty string <tt>result</tt> of type <tt>basic_string&lt;charT&gt;</tt>,
+calls <tt>regex_replace(back_inserter(result), s, s +
+char_traits&lt;charT&gt;::length(s),
+e, fmt, flags)</tt>, and then returns <tt>result</tt>.
+</ins>
 </blockquote>
+</blockquote>
+</li>
+
+</ol>
+
 
 
 
@@ -7162,1288 +5560,1382 @@ Solved by
 
 
 <hr>
-<h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
-<p><b>Section:</b> 20.8.10.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-08-24  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3>
+<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-10-10  <b>Last modified:</b> 2009-11-08</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-A discussion on
-<a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
-has identified a contradiction in the <tt>shared_ptr</tt> specification.
-The note:
+This issue was split from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a> now just
+deals with changing the requirements of <tt>T</tt> in the <tt>Swappable</tt>
+requirement from <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> to
+<tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
 </p>
 
-<blockquote><p>
-[ <i>Note:</i> this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
--end note ]
-</p></blockquote>
-
 <p>
-after the aliasing constructor
+This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators.  Here
+is example code:
 </p>
 
-<blockquote><pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
-</pre></blockquote>
+<blockquote><pre>namespace Mine {
 
-<p>
-reflects the intent of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
-to, well, allow the creation of an empty <tt>shared_ptr</tt>
-with a non-NULL stored pointer.
-</p>
+template &lt;class T&gt;
+struct proxy {...};
 
-<p>
-This is contradicted by the second sentence in the Returns clause of 20.8.10.2.5 [util.smartptr.shared.obs]:
-</p>
+template &lt;class T&gt;
+struct proxied_iterator
+{
+   typedef T value_type;
+   typedef proxy&lt;T&gt; reference;
+   reference operator*() const;
+   ...
+};
 
-<blockquote>
-<pre>T* get() const;
-</pre>
-<blockquote><p>
-<i>Returns:</i> the stored pointer. Returns a null pointer if <tt>*this</tt> is empty.
-</p></blockquote>
-</blockquote>
+struct A
+{
+   // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
+   void swap(A&amp;);
+   ...
+};
 
-<p><i>[
-Bellevue:
-]</i></p>
+void swap(A&amp;, A&amp;);
+void swap(proxy&lt;A&gt;, A&amp;);
+void swap(A&amp;, proxy&lt;A&gt;);
+void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);
 
+}  // Mine
+
+...
+
+Mine::proxied_iterator&lt;Mine::A&gt; i(...)
+Mine::A a;
+<b>swap(*i1, a);</b>
+</pre></blockquote>
 
-<blockquote>
-<p>
-Adopt option 1 and move to review, not ready.
-</p>
 <p>
-There was a lot of confusion about what an empty <tt>shared_ptr</tt> is (the term
-isn't defined anywhere), and whether we have a good mental model for how
-one behaves. We think it might be possible to deduce what the definition
-should be, but the words just aren't there. We need to open an issue on
-the use of this undefined term. (The resolution of that issue might
-affect the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.)
+The key point to note in the above code is that in the call to <tt>swap</tt>, <tt>*i1</tt>
+and <tt>a</tt> are different types (currently types can only be <tt>Swappable</tt> with the
+same type).  A secondary point is that to support proxies, one must be able to pass rvalues
+to <tt>swap</tt>.  But note that I am not stating that the general purpose <tt>std::swap</tt>
+should accept rvalues!  Only that overloaded <tt>swap</tt>s, as in the example above, be allowed
+to take rvalues.
 </p>
+
 <p>
-The LWG is getting more uncomfortable with the aliasing proposal (N2351)
-now that we realize some of its implications, and we need to keep an eye
-on it, but there isn't support for removing this feature at this time.
+That is, no standard library code needs to change.  We simply need to have a more flexible
+definition of <tt>Swappable</tt>.
 </p>
-</blockquote>
 
 <p><i>[
-Sophia Antipolis:
+Bellevue:
 ]</i></p>
 
 
 <blockquote>
 <p>
-We heard from Peter Dimov, who explained his reason for preferring solution 1.
-</p>
-<p>
-Because it doesn't seem to add anything. It simply makes the behavior
-for p = 0 undefined. For programmers who don't create empty pointers
-with p = 0, there is no difference. Those who do insist on creating them
-presumably have a good reason, and it costs nothing for us to define the
-behavior in this case.
-</p>
-<p>
-The aliasing constructor is sharp enough as it is, so "protecting" users
-doesn't make much sense in this particular case.
+While we believe Concepts work will define a swappable concept, we
+should still resolve this issue if possible to give guidance to the
+Concepts work.
 </p>
 <p>
-&gt; Do you have a use case for r being empty and r being non-null? 
+Would an ambiguous swap function in two namespaces found by ADL break
+this wording? Suggest that the phrase "valid expression" means such a
+pair of types would still not be swappable.
 </p>
 <p>
-I have received a few requests for it from "performance-conscious"
-people (you should be familiar with this mindset) who don't like the
-overhead of allocating and maintaining a control block when a null
-deleter is used to approximate a raw pointer. It is obviously an "at
-your own risk", low-level feature; essentially a raw pointer behind a
-shared_ptr facade.
+Motivation is proxy-iterators, but facility is considerably more
+general. Are we happy going so far?
 </p>
 <p>
-We could not agree upon a resolution to the issue; some of us thought
-that Peter's description above is supporting an undesirable behavior.
+We think this wording is probably correct and probably an improvement on
+what's there in the WP. On the other hand, what's already there in the
+WP is awfully complicated. Why do we need the two bullet points? They're
+too implementation-centric. They don't add anything to the semantics of
+what swap() means, which is there in the post-condition. What's wrong
+with saying that types are swappable if you can call swap() and it
+satisfies the semantics of swapping?
 </p>
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
+]</i></p>
+
+
+<p><i>[
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-<p>
-We favor option 1, move to Ready.
-</p>
+Leave as Open. Dave to provide wording.
+</blockquote>
+
 <p><i>[
-Howard:  Option 2 commented out for clarity, and can be brought back.
+2009-11-08 Howard adds:
 ]</i></p>
 
+
+<blockquote>
+Updated wording to sync with
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>.
+Also this issue is very closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</a>.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-In keeping the N2351 spirit and obviously my preference, change 20.8.10.2.5 [util.smartptr.shared.obs]:
+Change 20.2.1 [utility.arg.requirements]:
 </p>
 
 <blockquote>
-<pre>T* get() const;
-</pre>
-<blockquote><p>
-<i>Returns:</i> the stored pointer. <del>Returns a null pointer if <tt>*this</tt> is empty.</del>
-</p></blockquote>
+
+<p>
+-1- The template definitions in the C++ Standard Library refer to various
+named requirements whose details are set out in tables 31-38. In these
+tables, <tt>T</tt> <ins>and <tt>V</tt> are</ins> <del>is a</del> type<ins>s</ins> to be supplied by a C++ program
+instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
+values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
+lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
+<tt>const</tt>) <tt>T</tt>; <del>and</del> <tt>rv</tt> is a non-<tt>const</tt>
+rvalue of type <tt>T</tt><ins>; <tt>w</tt> is a value of type <tt>T</tt>; and <tt>v</tt> is a value of type <tt>V</tt></ins>.
+</p>
+
+<table border="1">
+<caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
+<tbody><tr><th>expression</th><th>Return type</th><th>Post-condition</th></tr>
+<tr><td><tt>swap(<del>s</del><ins>w</ins>,<del>t</del><ins>v</ins>)</tt></td><td><tt>void</tt></td>
+<td><del><tt>t</tt></del><ins><tt>w</tt></ins> has the value originally
+held by <del><tt>u</tt></del><ins><tt>v</tt></ins>, and
+<del><tt>u</tt></del><ins><tt>v</tt></ins> has the value originally held
+by <del><tt>t</tt></del><ins><tt>w</tt></ins></td></tr>
+<tr><td colspan="3">
+<p>
+The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
+</p>
+<ul>
+<li>
+<tt>T</tt> is <tt>Swappable</tt> if <ins><tt>T</tt> and <tt>V</tt> are
+the same type and </ins> <tt>T</tt> satisfies the
+<tt>MoveConstructible</tt> requirements (Table 
+33) and the 
+<tt>MoveAssignable</tt> requirements (Table 
+35);
+</li>
+<li>
+<tt>T</tt> is <tt>Swappable</tt> <ins>with <tt>V</tt></ins> if a namespace scope function named
+<tt>swap</tt> exists in the same namespace as the definition of
+<tt>T</tt> <ins>or <tt>V</tt></ins>, such that the expression
+<tt>swap(<del>s</del><ins>w</ins>,<del>t</del> <ins>v</ins>)</tt> is valid and has the
+semantics described in this table.
+</li>
+<li>
+<tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose
+element type is <tt>Swappable</tt>.
+</li>
+</ul>
+</td></tr>
+</tbody></table>
 </blockquote>
 
 
 
+<p><b>Rationale:</b></p>
+<p><i>[
+post San Francisco:
+]</i></p>
+
+
+<blockquote>
+Solved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2758.pdf">N2758</a>.
+</blockquote>
+
 
 
 
 
 
 <hr>
-<h3><a name="716"></a>716. Production in [re.grammar] not actually modified</h3>
-<p><b>Section:</b> 28.13 [re.grammar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-08-31  <b>Last modified:</b> 2009-07-16</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="774"></a>774. Member swap undefined for most containers</h3>
+<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-01-14  <b>Last modified:</b> 2009-10-31</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
+It appears most containers declare but do not define a member-swap
+function.
 </p>
 
-<blockquote>
 <p>
-The following productions within the ECMAScript grammar are modified as follows:
+This is unfortunate, as all overload the <tt>swap</tt> algorithm to call the
+member-swap function!
+(required for <tt>swappable</tt> guarantees [Table 37] and Container Requirements
+[Table 87])
 </p>
 
-<blockquote><pre>CharacterClass ::
-[ [lookahead &#8713; {^}] ClassRanges ]
-[ ^ ClassRanges ]
-</pre></blockquote>
-
-</blockquote>
-
 <p>
-This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
+Note in particular that Table 87 gives semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>,
+yet for all containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a circular
+definition.
 </p>
 
 <p>
-Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
+A quick survey of clause 23 shows that the following containers provide a
+definition for member-swap:
 </p>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<blockquote><pre>array
+queue
+stack
+vector
+</pre></blockquote>
 
-<blockquote>
 <p>
-We agree that what is specified is identical to what ECMA-262 specifies.
-Pete would like to take a bit of time to assess whether we had intended,
-but failed, to make a change.
-It would also be useful to hear from John Maddock on the issue.
+Whereas the following declare it, but do not define the semantics:
 </p>
+
+<blockquote><pre>deque
+list
+map
+multimap
+multiset
+priority_queue
+set
+unordered_map
+unordered_multi_map
+unordered_multi_set
+unordered_set
+</pre></blockquote>
+
 <p>
-Move to Open.
+Suggested resolution:
 </p>
+<blockquote>
+Provide a definition for each of the affected containers...
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+Bellevue:
 ]</i></p>
 
 
 <blockquote>
-Move to Ready.
+Move to Open and ask Alisdair to provide wording.
 </blockquote>
 
+<p><i>[
+2009-07 Frankfurt:
+]</i></p>
 
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Remove this mention of the CharacterClass production.
-</p>
-
-<blockquote><pre><del>CharacterClass ::
-[ [lookahead &#8713; {^}] ClassRanges ]
-[ ^ ClassRanges ]</del>
-</pre></blockquote>
-
-
-
-
+<blockquote>
+Daniel to provide wording.
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>
+is no longer applicable.
+</blockquote>
 
+<p><i>[
+2009-07-28 Daniel provided wording.
+]</i></p>
 
-<hr>
-<h3><a name="719"></a>719. <tt>std::is_literal</tt> type traits should be provided</h3>
-<p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-25  <b>Last modified:</b> 2009-07-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a></p>
-<p><b>Discussion:</b></p>
-<p>
-Since the inclusion of <tt>constexpr</tt> in the standard draft N2369 we have
-a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
-</p>
 
 <blockquote>
-<p>
--11- A type is a <i>literal</i> type if it is:
-</p>
-<ul>
-<li>a scalar type; or</li>
-<li><p>a class type (clause 9) with</p>
-<ul>
-<li>a trivial copy constructor,</li>
-<li>a trivial destructor,</li>
-<li>at least one constexpr constructor other than the copy constructor,</li>
-<li>no virtual base classes, and</li>
-<li>all non-static data members and base classes of literal types; or</li>
-</ul>
+<ol>
+<li>
+It assumes that the proposed resolution for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a> is applied,
+which breaks the circularity of definition between member
+<tt>swap</tt> and free <tt>swap</tt>.
 </li>
-<li>an array of literal type.</li>
-</ul>
-</blockquote>
 
-<p>
-I strongly suggest that the standard provides a type traits for
-literal types in 20.6.4.3 [meta.unary.prop] for several reasons:
-</p>
+<li>
+It uses the notation of the pre-concept allocator trait
+<tt>allocator_propagation_map</tt>, which might be renamed after the
+next refactoring phase of generalized allocators.
+</li>
 
-<ol type="a">
-<li>To keep the traits in sync with existing types.</li>
-<li>I see many reasons for programmers to use this trait in template
-   code to provide optimized template definitions for these types,
-   see below.</li>
-<li>A user-provided definition of this trait is practically impossible
-to write portably.</li>
+<li>
+It requires that compare objects, key equal functions and
+hash functions in containers are swapped via unqualified free
+<tt>swap</tt> according to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</a>.
+</li>
 </ol>
+</blockquote>
+
+<p><i>[
+2009-09-30 Daniel adds:
+]</i></p>
 
-<p>
-The special problem of reason (c) is that I don't see currently a
-way to portably test the condition for literal class types:
-</p>
 
 <blockquote>
-<ul>
-<li>at least one constexpr constructor other than the copy constructor,</li>
-</ul>
+The outcome of this issue should be considered with the outcome of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1198">1198</a> both in style and in content (e.g. 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>[
-Alisdair is considering preparing a paper listing a number of missing
-type traits, and feels that it might be useful to handle them all
-together rather than piecemeal. This would affect issue 719 and 750.
-These two issues should move to OPEN pending AM paper on type traits.
+2009-10 Santa Cruz:
 ]</i></p>
 
 
+<blockquote>
+Looked at, but took no action on as it overlaps too much with
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
+Waiting for a new draft WP.
+</blockquote>
+
 <p><i>[
-2009-07 Frankfurt:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Beman, Daniel, and Alisdair will work on a paper proposing new type traits.
+Leave as open. Pablo to provide wording.
 </blockquote>
 
+<p><i>[
+2009-10-26 Pablo updated wording.  Here is the wording he replaced:
+]</i></p>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-In 20.6.2 [meta.type.synop] in the group "type properties",
-just below the line
-</p>
-
-<blockquote><pre>template &lt;class T&gt; struct is_pod;
-</pre></blockquote>
 
+<blockquote class="note">
+<ol>
+<li>
 <p>
-add a new one:
+Add a new Throws clause just after X [allocator.propagation.map]/5:
 </p>
 
-<blockquote><pre>template &lt;class T&gt; struct is_literal;
-</pre></blockquote>
-
+<blockquote><pre>static void swap(Alloc&amp; a, Alloc&amp; b);
+</pre>
+<blockquote>
 <p>
-In 20.6.4.3 [meta.unary.prop], table Type Property Predicates, just
-below the line for the <tt>is_pod</tt> property add a new line:
+<i>Effects:</i> [..]
 </p>
 
-<table border="1">
-<tbody><tr>
-<th>Template</th><th>Condition</th><th>Preconditions</th>
-</tr>
-<tr>
-<td><tt>template &lt;class T&gt; struct is_literal;</tt></td>
-<td><tt>T</tt> is a literal type (3.9)</td>
-<td><tt>T</tt> shall be a complete type, an
-array of unknown bound, or
-(possibly cv-qualified) <tt>void</tt>.</td>
-</tr>
-</tbody></table>
-
-
-
-
-
-
-<hr>
-<h3><a name="723"></a>723. <tt>basic_regex</tt> should be moveable</h3>
-<p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-29  <b>Last modified:</b> 2009-07-16</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex">issues</a> in [re.regex].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 316</b></p>
-
 <p>
-According to the current state of the standard draft, the class
-template <tt>basic_regex</tt>, as described in 28.8 [re.regex]/3, is
-neither <tt>MoveConstructible</tt> nor <tt>MoveAssignable</tt>.
-IMO it should be, because typical regex state machines tend
-to have a rather large data quantum and I have seen several
-use cases, where a factory function returns regex values,
-which would take advantage of moveabilities.
+<ins><i>Throws:</i> Nothing.</ins>
 </p>
-
+</blockquote>
+</blockquote>
 <p><i>[
-Sophia Antipolis:
+This exception requirement is added, such that it's combination with the
+general container requirements of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
+[container.requirements.general]/9
+make it unambiguously clear that the following descriptions of "swaps the
+allocators" have the following meaning: (a) This swap is done by calling
+<tt>allocator_propagation_map&lt;allocator_type&gt;::swap</tt> and (b) This allocator
+swap does never propagate an exception
 ]</i></p>
 
+</li>
+
+<li>
+<p>
+Change 23.2.4.1 [associative.reqmts.except]/3 as indicated:
+</p>
 
 <blockquote>
-Needs wording for the semantics, the idea is agreed upon.
+For associative containers, no <tt>swap</tt> function throws an exception unless that
+exception is thrown by the <del>copy constructor or copy assignment
+operator</del>
+<ins><tt>swap</tt></ins> of the container's <tt>Pred</tt> object<ins>s</ins><del> (if any)</del>.
 </blockquote>
+</li>
 
-<p><i>[
-Post Summit Daniel updated wording to reflect new "swap rules".
-]</i></p>
-
+<li>
+<p>
+Change 23.2.5.1 [unord.req.except]/3 as indicated:
+</p>
 
-<p><i>[
-2009-07 Frankfurt:
-]</i></p>
+<blockquote>
+For unordered associative containers, no <tt>swap</tt> function throws an
+exception unless
+that exception is thrown by the <del>copy constructor or copy
+assignment operator</del>
+<ins><tt>swap</tt></ins> of the container's <tt>Hash</tt> or <tt>Pred</tt> object<ins>s,
+respectively</ins><del> (if any)</del>.
+</blockquote>
+</li>
 
+<li>
+<p>
+Insert a new paragraph just after 23.3 [sequences]/1:
+</p>
 
 <blockquote>
-Move to Ready.
+<ins>In addition to being available via inclusion of the <tt>&lt;algorithm&gt;</tt> header,
+the <tt>swap</tt> function templates in 25.3.3 [alg.swap] are also available when the
+header <tt>&lt;queue&gt;</tt> is included.</ins>
 </blockquote>
 
+<p><i>[
+There is a new issue in process that will suggest a minimum header for <tt>swap</tt>
+and <tt>move</tt>. If this one is provided, this text can be removed and the header
+dependency should be added to <tt>&lt;queue&gt;</tt>
+]</i></p>
 
 
-<p><b>Proposed resolution:</b></p>
-<p>
-In the class definition of <tt>basic_regex</tt>, just below 28.8 [re.regex]/3,
-perform the following changes:
-</p>
+</li>
 
-<ol type="a">
 <li>
 <p>
-Just after <tt>basic_regex(const basic_regex&amp;);</tt> insert:
+Add one further clause at the end of 23.3.1.2 [array.special]:
 </p>
+<p><i>[This part is added, because otherwise <tt>array::swap</tt> would otherwise
+contradict the
+general contract of 23.2.1 [container.requirements.general] p. 10 b. 5]</i></p>
 
-<blockquote><pre>basic_regex(basic_regex&amp;&amp;);
-</pre></blockquote>
+
+<blockquote>
+<ins><i>Throws:</i> Nothing, unless one of the element-wise <tt>swap</tt> calls throws
+an exception.</ins>
+</blockquote>
 </li>
+
 <li>
-<p>
-Just after <tt>basic_regex&amp; operator=(const basic_regex&amp;);</tt> insert:
-</p>
-<blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
-</pre></blockquote>
-</li>
+<ol type="a">
 <li>
 <p>
-Just after <tt>basic_regex&amp; assign(const basic_regex&amp; that);</tt> insert:
+In 23.3.2 [deque], class template deque synopsis change as indicated:
 </p>
-<blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
+<blockquote><pre>void swap(deque<del>&lt;T,Alloc&gt;</del>&amp;);
 </pre></blockquote>
 </li>
+
 <li>
 <p>
-In 28.8.2 [re.regex.construct], just after p.11 add the following
-new member definition:
+At the end of 23.3.2.3 [deque.modifiers] add as indicated:
 </p>
-<blockquote><pre>basic_regex(basic_regex&amp;&amp; e);
+
+<blockquote><pre><ins>void swap(deque&amp; x);</ins>
 </pre>
 <blockquote>
 <p>
-<i>Effects:</i> Move-constructs a <tt>basic_regex</tt> instance from <tt>e</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>flags()</tt> and <tt>mark_count()</tt> return <tt>e.flags()</tt> and
-<tt>e.mark_count()</tt>, respectively,
-that <tt>e</tt> had before construction, leaving
-<tt>e</tt> in a valid state with an unspecified value.
+<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
+with that of <tt>x</tt>.</ins>
 </p>
 <p>
-<i>Throws:</i> nothing.
+<ins><i>Complexity:</i> Constant time.</ins>
 </p>
 </blockquote>
 </blockquote>
 </li>
+</ol>
+</li>
+
+<li>
+<ol type="a">
 <li>
 <p>
-Also in 28.8.2 [re.regex.construct], just after p.18 add the
-following new member definition:
+In 23.3.3 [forwardlist], class template <tt>forward_list</tt> synposis change as indicated:
 </p>
 
-<blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp; e);
-</pre>
-<blockquote>
-<i>Effects:</i> Returns the result of <tt>assign(std::move(e))</tt>.
-</blockquote>
-</blockquote>
+<blockquote><pre>void swap(forward_list<del>&lt;T,Allocator&gt;</del>&amp;);
+</pre></blockquote>
 </li>
+
 <li>
 <p>
-In 28.8.3 [re.regex.assign], just after p. 2 add the following new
-member definition:
+At the end of 23.3.3.4 [forwardlist.modifiers] add as indicated:
 </p>
-<blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; rhs);
+
+<blockquote><pre><ins>void swap(forward_list&amp; x);</ins>
 </pre>
 <blockquote>
 <p>
-<i>Effects:</i> Move-assigns a <tt>basic_regex</tt> instance from <tt>rhs</tt> and returns <tt>*this</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>flags()</tt> and <tt>mark_count()</tt> return <tt>rhs.flags()</tt>
-and <tt>rhs.mark_count()</tt>, respectively, that
-<tt>rhs</tt> had before assignment, leaving <tt>rhs</tt>
-in a valid state with an unspecified value.
+<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
+with that of <tt>x</tt>.</ins>
 </p>
 <p>
-<i>Throws:</i> nothing.
+<ins><i>Complexity:</i> Constant time.</ins>
 </p>
 </blockquote>
 </blockquote>
 </li>
 </ol>
+</li>
 
+<li>
+<ol type="a">
+<li>
+<p>
+In 23.3.4 [list], class template <tt>list</tt> synopsis change as indicated:
+</p>
 
+<blockquote><pre>void swap(list<del>&lt;T,Allocator&gt;</del>&amp;);
+</pre></blockquote>
+</li>
 
-
-
-<hr>
-<h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3>
-<p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2007-09-12  <b>Last modified:</b> 2009-07-28</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<li>
 <p>
-The <tt>DefaultConstructible</tt> requirement is referenced in
-several places in the August 2007 working draft
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf">N2369</a>,
-but is not defined anywhere.
+At the end of 23.3.4.3 [list.modifiers] add as indicated:
 </p>
 
-<p><i>[
-Bellevue:
-]</i></p>
-
+<blockquote><pre><ins>void swap(list&amp; x);</ins>
+</pre>
 
 <blockquote>
 <p>
-Walking into the default/value-initialization mess...
-</p>
-<p>
-Why two lines? Because we need both expressions to be valid.
-</p>
-<p>
-AJM not sure what the phrase "default constructed" means. This is
-unfortunate, as the phrase is already used 24 times in the library!
-</p>
-<p>
-Example: const int would not accept first line, but will accept the second.
+<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
+with that of <tt>x</tt>.</ins>
 </p>
+
 <p>
-This is an issue that must be solved by concepts, but we might need to solve it independantly first.
+<ins><i>Complexity:</i> Constant time.</ins>
 </p>
+</blockquote>
+</blockquote>
+</li>
+</ol>
+</li>
+
+<li>
 <p>
-It seems that the requirements are the syntax in the proposed first
-column is valid, but not clear what semantics we need.
+At the end of 23.3.5.2.2 [priqueue.members] add a new prototype description:
 </p>
+
+<blockquote><pre><ins>void swap(priority_queue&amp; q);</ins>
+</pre>
+<blockquote>
 <p>
-A table where there is no post-condition seems odd, but appears to sum up our position best.
+<ins><i>Requires:</i> <tt>Compare</tt> shall satisfy the <tt>Swappable</tt> requirements
+( [swappable]).</ins>
 </p>
+
+<p><i>[
+This requirement is added to ensure that even a user defined <tt>swap</tt>
+which is found by
+ADL for <tt>Compare</tt> satisfies the <tt>Swappable</tt> requirements
+]</i></p>
+
+
 <p>
-At a minimum an object is declared and is destuctible.
+<ins><i>Effects:</i> <tt>this-&gt;c.swap(q.c); swap(this-&gt;comp, q.comp);</tt></ins>
 </p>
 <p>
-Move to open, as no-one happy to produce wording on the fly.
+<ins><i>Throws:</i> What and if <tt>c.swap(q.c)</tt> and <tt>swap(comp, q.comp)</tt> throws.</ins>
 </p>
 </blockquote>
-
+</blockquote>
 <p><i>[
-2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
+This part is added, because otherwise <tt>priority_queue::swap</tt> would otherwise
+contradict the general contract of 23.2.1 [container.requirements.general] p. 10 b. 5
 ]</i></p>
 
+</li>
 
+<li>
+<ol type="a">
+<li>
+<p>
+In 23.3.6 [vector], class template <tt>vector</tt> synopsis change as indicated:
+</p>
 
+<blockquote><pre>void swap(vector<del>&lt;T,Allocator&gt;</del>&amp;);
+</pre></blockquote>
+</li>
 
-<p><b>Proposed resolution:</b></p>
+<li>
 <p>
-In section X [utility.arg.requirements], before table 33, add the
-following table:
+Change 23.3.6.2 [vector.capacity]/8 as indicated:
 </p>
 
-<p style="text-align: center;" align="center">Table 33: <tt>DefaultConstructible</tt> requirements</p>
+<blockquote><pre>void swap(vector<del>&lt;T,Allocator&gt;</del>&amp; x);
+</pre>
 
-<div align="center">
+<blockquote>
+<i>Effects:</i> Exchanges the contents and <tt>capacity()</tt> <ins>and swaps the
+allocators</ins>
+of <tt>*this</tt> with that of <tt>x</tt>.
+</blockquote>
+</blockquote>
+</li>
+</ol>
+</li>
 
-<table style="border-collapse: collapse;" border="0" cellpadding="0" cellspacing="0">
- <tbody><tr>
-  <td style="border-style: solid none double solid; border-color: navy -moz-use-text-color navy navy; border-width: 1pt medium 1.5pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
-  <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">expression</p>
-  </td>
-  <td style="border-style: solid solid double none; border-color: navy navy navy -moz-use-text-color; border-width: 1pt 1pt 1.5pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
-  <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">post-condition</p>
-  </td>
- </tr>
- <tr>
-  <td style="border-style: none none solid solid; border-color: -moz-use-text-color -moz-use-text-color navy navy; border-width: medium medium 1pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
-  <p style="margin: 0in 0in 0.0001pt;"><tt>T
-  t;</tt><br>
-  <tt>T()</tt></p>
-  </td>
-  <td style="border-style: none solid solid none; border-color: -moz-use-text-color navy navy -moz-use-text-color; border-width: medium 1pt 1pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
-  <p style="margin: 0in 0in 0.0001pt;"><tt>T</tt>
-  is <i>default constructed.</i></p>
-  </td>
- </tr>
-</tbody></table>
+<li>
+<p>
+Insert a new paragraph just before 23.4 [associative]/1:
+</p>
 
-</div>
+<blockquote>
+<ins>In addition to being available via inclusion of the <tt>&lt;algorithm&gt;</tt> header,
+the <tt>swap</tt> function templates in 25.3.3 [alg.swap] are also available when any of the
+headers <tt>&lt;map&gt;</tt> or <tt>&lt;set&gt;</tt> are included.</ins>
+</blockquote>
+</li>
 
+<li>
+<ol type="a">
+<li>
+<p>
+In 23.4.1 [map], class template <tt>map</tt> synopsis change as indicated:
+</p>
 
+<blockquote><pre>void swap(map<del>&lt;Key,T,Compare,Allocator&gt;</del>&amp;);
+</pre></blockquote>
+</li>
+
+<li>
+<p>
+At the end of 23.4.1.3 [map.modifiers] add as indicated:
+</p>
+
+<blockquote><pre><ins>void swap(map&amp; x);</ins>
+</pre>
+
+<blockquote>
+<p>
+<ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
+( [swappable]).</ins>
+</p>
 
-<p><b>Rationale:</b></p>
 <p><i>[
-San Francisco:
+This requirement is added to ensure that even a user defined <tt>swap</tt>
+which is found by ADL for <tt>Compare</tt> satisfies the <tt>Swappable</tt>
+requirements
 ]</i></p>
 
-<blockquote>
-We believe concepts will solve this problem
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>).
+
+<p>
+<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
+with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
+of <tt>*this</tt> and <tt>x</tt>.</ins>
+</p>
+
+<p>
+<ins><i>Complexity:</i> Constant time</ins>
+</p>
 </blockquote>
+</blockquote>
+</li>
+</ol>
+</li>
 
+<li>
+<ol type="a">
+<li>
+<p>
+In 23.4.2 [multimap], class template <tt>multimap</tt> synopsis change as indicated:
+</p>
 
+<blockquote><pre>void swap(multimap<del>&lt;Key,T,Compare,Allocator&gt;</del>&amp;);
+</pre></blockquote>
+</li>
 
+<li>
+<p>
+At the end of 23.4.2.2 [multimap.modifiers] add as indicated:
+</p>
 
+<blockquote><pre><ins>void swap(multimap&amp; x);</ins>
+</pre>
 
-<hr>
-<h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3>
-<p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-09-22  <b>Last modified:</b> 2009-07-25</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<blockquote>
 <p>
-Two overloads of <tt>regex_replace()</tt> are currently provided:
+<ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
+( [swappable]).</ins>
+</p>
+<p>
+<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
+with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
+of <tt>*this</tt> and <tt>x</tt>.</ins>
+</p>
+<p>
+<ins><i>Complexity:</i> Constant time</ins>
 </p>
+</blockquote>
+</blockquote>
+</li>
+</ol>
+</li>
 
-<blockquote><pre>template &lt;class OutputIterator, class BidirectionalIterator, 
-    class traits, class charT&gt; 
-  OutputIterator 
-  regex_replace(OutputIterator out, 
-                BidirectionalIterator first, BidirectionalIterator last, 
-                const basic_regex&lt;charT, traits&gt;&amp; e, 
-                const basic_string&lt;charT&gt;&amp; fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
- 
-template &lt;class traits, class charT&gt; 
-  basic_string&lt;charT&gt; 
-  regex_replace(const basic_string&lt;charT&gt;&amp; s, 
-                const basic_regex&lt;charT, traits&gt;&amp; e, 
-                const basic_string&lt;charT&gt;&amp; fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
+<li>
+<ol type="a">
+<li>
+<p>
+In 23.4.3 [set], class template <tt>set</tt> synopsis change as indicated:
+</p>
+
+<blockquote><pre>void swap(set<del>&lt;Key,Compare,Allocator&gt;</del>&amp;);
 </pre></blockquote>
+</li>
 
-<ol>
-<li>Overloads taking <tt>const charT *</tt> are provided for <tt>regex_match()</tt> and
-<tt>regex_search()</tt>, but not <tt>regex_replace()</tt>.  This is inconsistent.</li>
 <li>
-<p>The absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p>
+<p>
+After section 23.4.3.1 [set.cons] add a new section <ins><tt>set</tt> modifiers
+ [set.modifiers]</ins>
+and add the following paragraphs:
+</p>
 
-<blockquote><pre>const string s("kitten");
-const regex r("en");
-cout &lt;&lt; regex_replace(s, r, "y") &lt;&lt; endl;
-</pre></blockquote>
+<blockquote><pre><ins>void swap(set&amp; x);</ins>
+</pre>
 
+<blockquote>
 <p>
-The compiler error message will be something like "could not deduce
-template argument for 'const std::basic_string&lt;_Elem&gt; &amp;' from 'const
-char[1]'".
+<ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
+( [swappable]).</ins>
 </p>
 
 <p>
-Users expect that anything taking a <tt>basic_string&lt;charT&gt;</tt> can also take a
-<tt>const charT *</tt>.  In their own code, when they write a function taking
-<tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const
-wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor.  Because the
-regex algorithms are templated on <tt>charT</tt>, they can't rely on
-<tt>basic_string</tt>'s implicit constructor (as the compiler error message
-indicates, template argument deduction fails first).
+<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
+with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
+of <tt>*this</tt> and <tt>x</tt>.</ins>
 </p>
 
 <p>
-If a user figures out what the compiler error message means, workarounds
-are available - but they are all verbose.  Explicit template arguments
-could be given to <tt>regex_replace()</tt>, allowing <tt>basic_string</tt>'s implicit
-constructor to be invoked - but <tt>charT</tt> is the last template argument, not
-the first, so this would be extremely verbose.  Therefore, constructing
-a <tt>basic_string</tt> from each C string is the simplest workaround.
+<ins>Complexity: Constant time</ins>
 </p>
+</blockquote>
+</blockquote>
+</li>
+</ol>
 </li>
 
 <li>
-There is an efficiency consideration: constructing <tt>basic_string</tt>s can
-impose performance costs that could be avoided by a library
-implementation taking C strings and dealing with them directly. 
-(Currently, for replacement sources, C strings can be converted into
-iterator pairs at the cost of verbosity, but for format strings, there
-is no way to avoid constructing a <tt>basic_string</tt>.)
+<ol type="a">
+<li>
+<p>
+In 23.4.4 [multiset], class template <tt>multiset</tt> synosis, change as indicated:
+</p>
+
+<blockquote><pre>void swap(multiset<del>&lt;Key,Compare,Allocator&gt;</del>&amp;);
+</pre></blockquote>
 </li>
-</ol>
 
-<p><i>[
-Sophia Antipolis:
-]</i></p>
+<li>
+<p>
+After section 23.4.4.1 [multiset.cons] add a new section <ins><tt>multiset</tt> modifiers
+ [multiset.modifiers]</ins> and add the following paragraphs:
+</p>
 
+<blockquote><pre><ins>void swap(multiset&amp; x);</ins>
+</pre>
 
 <blockquote>
-We note that Boost already has these overloads. However, the proposed
-wording is provided only for 28.11.4 [re.alg.replace]; wording is needed for the synopsis
-as well. We also note that this has impact on <tt>match_results::format</tt>,
-which may require further overloads.
-</blockquote>
+<p>
+<ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
+( [swappable]).</ins>
+</p>
 
-<p><i>[
-2009-07 Frankfurt:
-]</i></p>
+<p>
+<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
+with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
+of <tt>*this</tt> and <tt>x</tt>.</ins>
+</p>
+
+<p>
+<ins><i>Complexity:</i> Constant time</ins>
+</p>
+</blockquote>
+</blockquote>
+</li>
+</ol>
+</li>
 
+<li>
+<p>
+Insert a new paragraph just before 23.5 [unord]/1:
+</p>
 
 <blockquote>
-Daniel to tweak for us.
+<ins>In addition to being available via inclusion of the <tt>&lt;algorithm&gt;</tt> header,
+the <tt>swap</tt> function templates in 25.3.3 [alg.swap] are also available when any of the
+headers <tt>&lt;unordered_map&gt;</tt> or <tt>&lt;unordered_set&gt;</tt> are included.</ins>
 </blockquote>
 
-<p><i>[
-2009-07-25 Daniel tweaks both this issue and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>.
-]</i></p>
+</li>
+
+<li>
+<p>
+After section 23.5.1.2 [unord.map.elem] add a new section <ins>unordered_map
+modifiers  [unord.map.modifiers]</ins> and add the following paragraphs:
+</p>
 
+<blockquote><pre><ins>void swap(unordered_map&amp; x);</ins>
+</pre>
 
 <blockquote>
 <p>
-This is solved by the proposed resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>.
+<ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
+( [swappable]).</ins>
 </p>
-</blockquote>
-
 
+<p><i>[
+This requirement is added to ensure that even a user defined <tt>swap</tt>
+which is found by ADL for <tt>Hash</tt> and <tt>Pred</tt> satisfies the <tt>Swappable</tt>
+requirements
+]</i></p>
 
-<p><b>Proposed resolution:</b></p>
 
 <p>
-Provide additional overloads for <tt>regex_replace()</tt>: one additional
-overload of the iterator-based form (taking <tt>const charT* fmt</tt>), and three
-additional overloads of the convenience form (one taking <tt>const charT*
-str</tt>, another taking <tt>const charT* fmt</tt>, and the third taking both <tt>const
-charT* str</tt> and <tt>const charT* fmt</tt>).  28.11.4 [re.alg.replace]:
+<ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
+allocators of <tt>*this</tt>
+with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
+and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt>.</ins>
 </p>
 
-<blockquote>
-<pre>template &lt;class OutputIterator, class BidirectionalIterator, 
-    class traits, class charT&gt; 
-  OutputIterator 
-  regex_replace(OutputIterator out, 
-                BidirectionalIterator first, BidirectionalIterator last, 
-                const basic_regex&lt;charT, traits&gt;&amp; e, 
-                const basic_string&lt;charT&gt;&amp; fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
+<p>
+<ins><i>Complexity:</i> Constant time</ins>
+</p>
+</blockquote>
+</blockquote>
+</li>
 
-<ins>template &lt;class OutputIterator, class BidirectionalIterator, 
-    class traits, class charT&gt; 
-  OutputIterator 
-  regex_replace(OutputIterator out, 
-                BidirectionalIterator first, BidirectionalIterator last, 
-                const basic_regex&lt;charT, traits&gt;&amp; e, 
-                const charT* fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);</ins>
-</pre>
-<p>...</p>
-<pre>template &lt;class traits, class charT&gt; 
-  basic_string&lt;charT&gt; 
-  regex_replace(const basic_string&lt;charT&gt;&amp; s, 
-                const basic_regex&lt;charT, traits&gt;&amp; e, 
-                const basic_string&lt;charT&gt;&amp; fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
+<li>
+<p>
+After section 23.5.2.1 [unord.multimap.cnstr] add a new section
+<ins>unordered_multimap
+modifiers  [unord.multimap.modifiers]</ins> and add the following paragraphs:
+</p>
 
-<ins>template &lt;class traits, class charT&gt; 
-  basic_string&lt;charT&gt; 
-  regex_replace(const basic_string&lt;charT&gt;&amp; s, 
-                const basic_regex&lt;charT, traits&gt;&amp; e, 
-                const charT* fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);</ins>
+<blockquote><pre><ins>void swap(unordered_multimap&amp; x);</ins>
+</pre>
 
-<ins>template &lt;class traits, class charT&gt; 
-  basic_string&lt;charT&gt; 
-  regex_replace(const charT* s, 
-                const basic_regex&lt;charT, traits&gt;&amp; e, 
-                const basic_string&lt;charT&gt;&amp; fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);</ins>
+<blockquote>
+<p>
+<ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
+( [swappable]).</ins>
+</p>
 
-<ins>template &lt;class traits, class charT&gt; 
-  basic_string&lt;charT&gt; 
-  regex_replace(const charT* s, 
-                const basic_regex&lt;charT, traits&gt;&amp; e, 
-                const charT* fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);</ins>
-</pre>
+<p>
+<ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
+allocators of <tt>*this</tt>
+with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
+and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt></ins>
+</p>
+<p>
+<ins><i>Complexity:</i> Constant time</ins>
+</p>
 </blockquote>
+</blockquote>
+</li>
 
+<li>
+<p>
+After section 23.5.3.1 [unord.set.cnstr] add a new section
+<ins>unordered_set modifiers
+ [unord.set.modifiers]</ins> and add the following paragraphs:
+</p>
 
+<blockquote><pre><ins>void swap(unordered_set&amp; x);</ins>
+</pre>
 
+<blockquote>
+<p>
+<ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
+( [swappable]).</ins>
+</p>
 
+<p>
+<ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
+allocators of <tt>*this</tt>
+with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
+and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt></ins>
+</p>
 
-
-<hr>
-<h3><a name="727"></a>727. <tt>regex_replace()</tt> doesn't accept <tt>basic_string</tt>s with custom traits and allocators</h3>
-<p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-09-22  <b>Last modified:</b> 2009-07-31</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-<tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string&lt;charT, ST,
-SA&gt;&amp;</tt>.  <tt>regex_replace()</tt> takes <tt>const basic_string&lt;charT&gt;&amp;</tt>.  This prevents
-<tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
-allocators.
+<ins><i>Complexity:</i> Constant time</ins>
 </p>
+</blockquote>
+</blockquote>
+</li>
 
+<li>
 <p>
-Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally
-templated on <tt>class ST, class SA</tt> and take <tt>const basic_string&lt;charT, ST,
-SA&gt;&amp;</tt>.  Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place
-<tt>class ST, class SA</tt> as the first template arguments; compatibility with
-existing code using TR1 and giving explicit template arguments to
-<tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template
-arguments.
+After section 23.5.4.1 [unord.multiset.cnstr] add a new section
+<ins>unordered_multiset
+modifiers  [unord.multiset.modifiers]</ins> and add the following paragraphs:
 </p>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<blockquote><pre><ins>void swap(unordered_multiset&amp; x);</ins>
+</pre>
 
 <blockquote>
 <p>
-Bill comments, "We need to look at the depth of this change."
+<ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
+( [swappable]).</ins>
 </p>
+
 <p>
-Pete remarks that we are here dealing with a convenience function
-that saves a user from calling the iterato-based overload.
+<ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
+allocators of <tt>*this</tt>
+with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
+and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt></ins>
 </p>
 <p>
-Move to Open.
+<ins><i>Complexity:</i> Constant time</ins>
 </p>
 </blockquote>
+</blockquote>
+</li>
 
-<p><i>[
-2009-07 Frankfurt:
-]</i></p>
-
+</ol>
 
-<blockquote>
-Howard to ask Stephan Lavavej to provide wording.
 </blockquote>
 
 <p><i>[
-2009-07-17 Stephan provided wording.
+2009-10-30 Pablo and Daniel updated wording.
 ]</i></p>
 
 
+
+
+<p><b>Proposed resolution:</b></p>
+
 <p><i>[
-2009-07-25 Daniel tweaks both this issue and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>.
+This resolution is based on the September 2009 WP,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>,
+except that it
+assumes that
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>
+and issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1232">1232</a> have already been applied.  Note in
+particular that Table 91 in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>
+is refered to as Table 90 because
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>
+removed the old Table 90.  This resolution also addresses issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#431">431</a>.
 ]</i></p>
 
+<p>
+In 23.2.1 [container.requirements.general], replace the a.swap(b) row in table 90,
+"container requirements" (was table 91 before the application of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a> to the
+WP):
+</p>
+<blockquote>
+<table border="1">
+  <tbody><tr>
+    <td><code>a.swap(b)</code></td>
+    <td><code>void</code></td>
+    <td>&nbsp;&nbsp;&nbsp;</td>
+    <td><code><del>swap(a,b)</del><ins>Exchange the contents of <tt>a</tt> and <tt>b</tt>.</ins></code></td>
+    <td>(Note A)</td>
+  </tr>
+  <tr>
+    <td><ins><code>swap(a,b)</code></ins></td>
+    <td><ins><code>void</code></ins></td>
+    <td><code>&nbsp;&nbsp;&nbsp;</code></td>
+    <td><ins><code>a.swap(b)</code></ins></td>
+    <td><ins>(Note A)</ins></td>
+  </tr>
+</tbody></table>
+</blockquote>
+<p>
+Modify the notes immediately following Table 90 in
+23.2.1 [container.requirements.general] as follows (The wording below is after the
+application of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>.  The editor might also want to combine Notes
+A and B into one.):
+</p>
+<blockquote><p>
+Notes: the algorithms<del> swap(),</del> equal() and lexicographical_compare()
+are defined in Clause 25.  Those entries marked "(Note A)" or "(Note B)"
+<del>should</del> have <ins>linear complexity for array and</ins> constant
+complexity <ins>for all other standard containers</ins>.
+</p></blockquote>
+<p>
+In 23.2.1 [container.requirements.general], after paragraph 9, add:
+</p>
+<blockquote><p><ins>
+The expression <code>a.swap(b)</code>, for containers <code>a</code>
+and <code>b</code> of a standard container type other than <code>array</code>,
+exchanges the values of <code>a</code> and <code>b</code> without invoking any
+move, copy, or swap operations on the individual container elements.
+Any <code>Compare</code>, <code>Pred</code>, or <code>Hash</code> function
+objects belonging to <code>a</code> and <code>b</code> shall satisfy
+the <code>Swappable</code> requirements and are exchanged by unqualified calls
+to non-member <code>swap</code>.  If
+<code>allocator_traits&lt;allocator_type&gt;::propagate_on_container_swap::value
+== true</code>, then the allocators of <code>a</code> and <code>b</code> are
+also exchanged using an unqualified call to non-member <code>swap</code>.
+Otherwise, the behavior is undefined unless <code>a.get_allocator() ==
+b.get_allocator()</code>.  Each iterator refering to an element in one
+container before the swap shall refer to the same element in the other
+container after the swap.  It is unspecified whether an iterator with
+value <code>a.end()</code> before the swap will have
+value <code>b.end()</code> after the swap.  In addition to being available via
+inclusion of the <code>&lt;utility&gt;</code> header, the <code>swap</code>
+function template in 25.3.3 [alg.swap] is also available within the definition of
+every standard container's <code>swap</code> function.
+</ins></p></blockquote>
+<p><i>[
+Note to the editor: Paragraph 2 starts with a sentence fragment,
+clearly from an editing or source-control error.
+]</i></p>
 
+<p>
+Modify 23.2.4.1 [associative.reqmts.except] as follows:
+</p>
 <blockquote>
 <p>
-One relevant part of the proposed resolution below suggests
-to add a new overload of the format member function in the
-<tt>match_results</tt> class template that accepts two character pointers
-defining the <tt>begin</tt> and <tt>end</tt> of a format range. A more general
-approach could have proposed a pair of iterators instead, but
-the used pair of char pointers reflects existing practice. If the
-committee strongly favors an iterator-based signature, this
-could be simply changed. I think that the minimum requirement
-should be a <tt>BidirectionalIterator</tt>, but current implementations
-take advantage (at least partially) of the <tt>RandomAccessIterator</tt>
-sub interface of the char pointers.
+<b>23.2.4.1 Exception safety guarantees 23.2.4.1 [associative.reqmts.except]</b>
+</p>
+<p>
+For associative containers, no <code>clear()</code> function throws an
+exception. <code>erase(k)</code> does not throw an exception unless that
+exception is thrown by the
+container's <code><del>Pred</del><ins>Compare</ins></code> object (if any).
 </p>
+<p>
+For associative containers, if an exception is thrown by any operation from
+within an <code>insert()</code> function inserting a single element,
+the <code>insert()</code> function has no effect.
+</p>
+<p>
+For associative containers, no <code>swap</code> function throws an exception
+unless that exception is thrown by the <del>copy constructor
+or copy assignment operator</del><ins>swap</ins> of the
+container's <code><del>Pred</del><ins>Compare</ins></code> object (if any).
+</p></blockquote>
+<p>
+Modify 23.2.5.1 [unord.req.except], paragraph 3 as follows:
+</p>
+<blockquote><p>
+For unordered associative containers, no <code>swap</code> function throws an
+exception unless that exception is thrown by the <del>copy constructor or copy
+assignment operator</del><ins>swap</ins> of the container's <code>Hash</code>
+or <code>Pred</code> object (if any).
+</p></blockquote>
+<p>
+Modify section 23.3.1.2 [array.special]:
+</p>
+<blockquote>
+<p>
+<b>array specialized algorithms 23.3.1.2 [array.special]</b>
+</p>
+<p>
+<code>template &lt;class T, size_t N&gt; void swap(array&lt;T,N&gt;&amp; x,array&lt;T,N&gt;&amp; y);</code>
+</p>
+<blockquote>
+<p>
+<i>Effects:</i> <code><del>swap_ranges(x.begin(), x.end(), y.begin() );</del><ins>x.swap(y);</ins></code>
+</p>
+</blockquote>
+</blockquote>
+<p>
+Add a new section after 23.3.1.5 [array.fill] (Note to the editor: array::fill make use
+of a concept requirement that must be removed or changed to text.):
+</p>
+<blockquote>
+<p>
+<ins><b>array::swap [array.swap]</b></ins>
+</p>
+<p>
+<ins><code>void swap(array&amp; y);</code></ins>
+</p>
+<blockquote>
+<p><ins>
+<i>Effects:</i> <code>swap_ranges(this-&gt;begin(), this-&gt;end(), y.begin() );</code>
+</ins></p>
+<p><ins>
+<i>Throws:</i> Nothing unless one of the element-wise swap calls throws an
+exception.
+</ins></p>
+<p><ins>
+[<i>Note</i>: Unlike other containers' <code>swap</code> functions,
+<code>array::swap</code> takes linear, not constant, time, may exit via an
+exception, and does not cause iterators to become associated with the other
+container. &#8212; <i>end note</i>]
+</ins></p>
+</blockquote>
+</blockquote>
 
-<p><b>Suggested Resolution:</b></p>
+<p>
+Insert a new paragraph just after 23.3.5 [container.adaptors]/1:
+</p>
+<blockquote><p><ins>
+For container adaptors, no <code>swap</code> function throws an exception
+unless that exception is thrown by the swap of the
+adaptor's <code>Container</code> or <code>Compare</code> object (if any).
+</ins></p></blockquote>
 
-<p><i>[Moved into the proposed resloution]</i></p>
 
 
 
-</blockquote>
 
-<p><i>[
-2009-07-30 Stephan agrees with Daniel's wording.  Howard places Daniel's wording
-in the Proposed Resolution.
-]</i></p>
 
 
 
 
-<p><b>Proposed resolution:</b></p>
 
-<ol>
-<li>
+
+
+<hr>
+<h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3>
+<p><b>Section:</b> 25.4.4 [alg.merge] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-25  <b>Last modified:</b> 2009-10-22</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Change 28.4 [re.syn] as indicated:
+Though issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> has fixed many open issues, it seems that some are still open:
 </p>
 
-<blockquote><pre>// 28.11.4, function template regex_replace:
-template &lt;class OutputIterator, class BidirectionalIterator,
-          class traits, class charT<ins>, class ST, class SA</ins>&gt;
-  OutputIterator
-  regex_replace(OutputIterator out,
-                BidirectionalIterator first, BidirectionalIterator last,
-                const basic_regex&lt;charT, traits&gt;&amp; e,
-                const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; fmt,
-                regex_constants::match_flag_type flags =
-                  regex_constants::match_default);
-
-<ins>
-template &lt;class OutputIterator, class BidirectionalIterator,
-          class traits, class charT&gt;
-  OutputIterator
-  regex_replace(OutputIterator out,
-                BidirectionalIterator first, BidirectionalIterator last,
-                const basic_regex&lt;charT, traits&gt;&amp; e,
-                const charT* fmt,
-                regex_constants::match_flag_type flags =
-                  regex_constants::match_default);
-</ins>
-
-template &lt;class traits, class charT<ins>, class ST, class SA,
-          class FST, class FSA</ins>&gt;
-  basic_string&lt;charT<ins>, ST, SA</ins>&gt;
-  regex_replace(const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; s,
-                const basic_regex&lt;charT, traits&gt;&amp; e,
-                const basic_string&lt;charT<ins>, FST, FSA</ins>&gt;&amp; fmt,
-                regex_constants::match_flag_type flags =
-                  regex_constants::match_default);
-
-<ins>
-template &lt;class traits, class charT, class ST, class SA&gt;
-  basic_string&lt;charT, ST, SA&gt;
-  regex_replace(const basic_string&lt;charT, ST, SA&gt;&amp; s,
-                const basic_regex&lt;charT, traits&gt;&amp; e,
-                const charT* fmt,
-                regex_constants::match_flag_type flags =
-                  regex_constants::match_default);
-</ins>
-
-<ins>
-template &lt;class traits, class charT, class ST, class SA&gt;
-  basic_string&lt;charT&gt;
-  regex_replace(const charT* s,
-                const basic_regex&lt;charT, traits&gt;&amp; e,
-                const basic_string&lt;charT, ST, SA&gt;&amp; fmt,
-                regex_constants::match_flag_type flags =
-                  regex_constants::match_default);
-</ins>
+<p>
+Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.4.4 [alg.merge] in N2461
+have no Requires element and the Effects element contains some requirements,
+which is probably editorial. Worse is that:
+</p>
 
-<ins>
-template &lt;class traits, class charT&gt;
-  basic_string&lt;charT&gt;
-  regex_replace(const charT* s,
-                const basic_regex&lt;charT, traits&gt;&amp; e,
-                const charT* fmt,
-                regex_constants::match_flag_type flags =
-                  regex_constants::match_default);
-</ins>
-</pre></blockquote>
+<ul>
+<li>
+no assignment requirements are specified (neither implicit nor explicit).
 </li>
 
 <li>
-<p>
-Change 28.10 [re.results]/3, class template <tt>match_results</tt> as
-indicated:
-</p>
+the effects clause just speaks of "merges", which is badly worded
+near to a circular definition.
+</li>
 
-<blockquote><pre><ins>
-template &lt;class OutputIter&gt;
-  OutputIter
-  format(OutputIter out,
-         const char_type* fmt_first, const char_type* fmt_last,
-         regex_constants::match_flag_type flags =
-           regex_constants::format_default) const;
-</ins>
+<li>
+p. 2 mentions a range <tt>[first, last)</tt>, which is not defined by the
+function arguments or otherwise.
+</li>
 
-template &lt;class OutputIter<ins>, class ST, class SA</ins>&gt;
-  OutputIter
-  format(OutputIter out,
-         const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
-         regex_constants::match_flag_type flags =
-           regex_constants::format_default) const;
+<li>
+p. 2 says "according to the ordering defined by comp" which is both
+incomplete (because
+this excludes the first variant with &lt;) and redundant (because the
+following subordinate
+clause mentions comp again)
+</li>
+</ul>
 
-<ins>template &lt;class ST, class SA&gt;</ins>
-  <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>
-  format(const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
-         regex_constants::match_flag_type flags =
-           regex_constants::format_default) const;
+<p><i>[
+Post Summit Alisdair adds:
+]</i></p>
 
-<ins>
-string_type
-format(const char_type* fmt,
-       regex_constants::match_flag_type flags =
-         regex_constants::format_default) const;
-</ins>
-</pre></blockquote>
-</li>
 
-<li>
+<blockquote>
 <p>
-Insert at the very beginning of 28.10.4 [re.results.form] the following:
+Suggest:
 </p>
-
-<blockquote><pre><ins>
-template &lt;class OutputIter&gt;
-  OutputIter
-  format(OutputIter out,
-         const char_type* fmt_first, const char_type* fmt_last,
-         regex_constants::match_flag_type flags =
-           regex_constants::format_default) const;
-</ins>
-</pre>
 <blockquote>
-
-<p><ins>
-1 <i>Requires:</i> The type <tt>OutputIter</tt> shall satisfy the requirements for an
-Output Iterator (24.2.3 [output.iterators]).
-</ins></p>
-
-<p><ins>
-2 <i>Effects:</i> Copies the character sequence <tt>[fmt_first,fmt_last)</tt> to
-<tt>OutputIter out</tt>. Replaces each
-format specifier or escape sequence in the copied range with either
-the character(s) it represents
-or the sequence of characters within <tt>*this</tt> to which it refers. The
-bitmasks specified in <tt>flags</tt>
-determines what format specifiers and escape sequences are recognized.
-</ins></p>
-
-<p><ins>
-3 <i>Returns:</i> <tt>out</tt>.
-</ins></p>
-</blockquote>
+(where <tt>last</tt> is equal to <tt>next(result, distance(first1, last1) +
+distance(first2, last2))</tt>, such that resulting range will be sorted in
+non-decreasing order; that is, for every iterator <tt>i</tt> in <tt>[result,last)</tt> other
+than <tt>result</tt>, the condition <tt>*i &lt; *prev(i)</tt> or, respectively, <tt>comp(*i,
+*prev(i))</tt> will be <tt>false</tt>.
 </blockquote>
-</li>
 
-<li>
 <p>
-Change 28.10.4 [re.results.form], before p. 1 until p. 3 (according to
-previous numbering)
-as indicated:
+Note that this might still not be technically accurate in the case of
+<tt>InputIterators</tt>, depending on other resolutions working their way through the
+system (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>).
 </p>
+</blockquote>
 
-<blockquote><pre>template &lt;class OutputIter<ins>, class ST, class SA</ins>&gt;
-  OutputIter
-  format(OutputIter out,
-         const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
-         regex_constants::match_flag_type flags =
-           regex_constants::format_default) const;
-</pre>
+<p><i>[
+Post Summit Daniel adds:
+]</i></p>
+
+
+<blockquote>
+If we want to use <tt>prev</tt> and <tt>next</tt> here (Note: <tt>merge</tt>
+is sufficiently satisfied with <tt>InputIterator</tt>) we should instead *add* more to
+25 [algorithms]/6, but I can currently not propose any good wording for this.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
 <blockquote>
 <p>
-<del><i>Requires:</i> The type <tt>OutputIter</tt> shall satisfy the requirements for
-an Output Iterator (24.2.3).</del>
+Pete points out the existing wording in [algorithms]/4
+that permits the use of + in algorithm specifications.
 </p>
-
 <p>
-<del><i>Effects:</i> Copies the character sequence <tt>[fmt.begin(),fmt.end())</tt> to
-<tt>OutputIter out</tt>. Replaces each
-format specifier or escape sequence in <tt>fmt</tt> with either the
-character(s) it represents or the sequence of
-characters within <tt>*this</tt> to which it refers. The bitmasks specified in
-<tt>flags</tt> determines what format
-specifiers and escape sequences are recognized.</del>
+Alisdair points out that that wording may not apply to input iterators.
 </p>
-
 <p>
-<i>Returns:</i> <tt><del>out</del><ins>format(out, fmt.data(), fmt.data() +
-fmt.size(), flags)</ins></tt>.
+Move to Review.
 </p>
 </blockquote>
+
+<p><i>[
+2009-07 Frankfurt:
+]</i></p>
+
+
+<blockquote>
+Move to Ready.
 </blockquote>
-</li>
 
-<li>
-<p>
-Change 28.10.4 [re.results.form], before p. 4 until p. 4 (according to
-previous numbering) as indicated:
-</p>
+<p><i>[
+2009-08-23 Daniel reopens:
+]</i></p>
 
-<blockquote><pre><ins>template &lt;class ST, class SA&gt;</ins>
-  <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>
-  format(const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
-         regex_constants::match_flag_type flags =
-           regex_constants::format_default) const;
-</pre>
 
 <blockquote>
 <p>
-<i>Effects:</i> <del>Returns a copy of the string <tt>fmt</tt>. Replaces each format
-specifier or escape sequence
-in <tt>fmt</tt> with either the character(s) it represents or the sequence of
-characters within <tt>*this</tt> to which
-it refers. The bitmasks specified in flags determines what format
-specifiers and escape sequences are
-recognized.</del> <ins>Constructs an empty string result of type
-<tt>basic_string&lt;char_type, ST, SA&gt;</tt>,
-and calls <tt>format(back_inserter(result), fmt, flags)</tt>.</ins>
+The proposed wording must be rephrased, because the part
 </p>
 
+<blockquote>
+for every iterator <tt>i</tt> in <tt>[result,last)</tt> other than <tt>result</tt>, the condition
+<tt>*i &lt; *(i - 1)</tt> or, respectively, <tt>comp(*i, *(i - 1))</tt> will be <tt>false</tt>"
+</blockquote>
+
 <p>
-<ins><i>Returns:</i> <tt>result</tt></ins>
+isn't meaningful, because the range <tt>[result,last)</tt> is that of a pure
+<tt>OutputIterator</tt>, which is not <em>readable</em> in general.
 </p>
+
+<p><i>[Howard:  Proposed wording updated by Daniel, status moved from Ready to Review.]</i></p>
+
 </blockquote>
-</blockquote>
-</li>
 
-<li>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
+
+<blockquote>
 <p>
-At the end of 28.10.4 [re.results.form] insert as indicated:
+Matt has some different words to propose.  Those words have been moved into
+the proposed wording section, and the original proposed wording now appears
+here:
+</p>
+<blockquote>
+<p>
+In 25.4.4 [alg.merge] replace p.1+ 2:
 </p>
-
-<blockquote><pre><ins>
-string_type
-  format(const char_type* fmt,
-         regex_constants::match_flag_type flags =
-           regex_constants::format_default) const;
-</ins></pre>
 
 <blockquote>
 <p>
-<ins><i>Effects:</i> Constructs an empty string result of type <tt>string_type</tt>, and calls
-<tt>format(back_inserter(result), fmt, fmt +
-char_traits&lt;char_type&gt;::length(fmt), flags)</tt>.</ins>
+<i>Effects:</i> <del>Merges</del><ins>Copies all the elements of the</ins>
+two sorted ranges
+<tt>[first1,last1)</tt> and <tt>[first2,last2)</tt> into the range <tt>[result,result +
+(last1 - first1) + (last2 - first2))</tt>
+<ins>, such that resulting range will be sorted in non-decreasing
+order; that is for every
+pair of iterators <tt>i</tt> and <tt>j</tt> of either input ranges, where <tt>*i</tt> was copied
+to the output range
+before <tt>*j</tt> was copied to the output range, the condition <tt>*j &lt; *i</tt> or,
+respectively, <tt>comp(*j, *i)</tt>
+will be <tt>false</tt>.</ins>
 </p>
+
 <p>
-<ins><i>Returns:</i> <tt>result</tt></ins>
+<ins><i>Requires:</i></ins>The resulting range shall not overlap with either
+of the original ranges.
+<del>The list 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 <tt>[first,last)</tt> other than <tt>first</tt>,
+the condition <tt>*i &lt; *(i - 1)</tt> or
+<tt>comp(*i, *(i - 1))</tt> will be <tt>false</tt>.</del>
 </p>
 </blockquote>
 </blockquote>
+</blockquote>
 
-</li>
 
-<li>
-<p>
-Change 28.11.4 [re.alg.replace] before p. 1 as indicated:
-</p>
-
-<blockquote><pre>template &lt;class OutputIterator, class BidirectionalIterator,
-          class traits, class charT<ins>, class ST, class SA</ins>&gt;
-  OutputIterator
-  regex_replace(OutputIterator out,
-                BidirectionalIterator first, BidirectionalIterator last,
-                const basic_regex&lt;charT, traits&gt;&amp; e,
-                const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; fmt,
-                regex_constants::match_flag_type flags =
-                  regex_constants::match_default);
-
-<ins>
-template &lt;class OutputIterator, class BidirectionalIterator,
-          class traits, class charT&gt;
-  OutputIterator
-  regex_replace(OutputIterator out,
-                BidirectionalIterator first, BidirectionalIterator last,
-                const basic_regex&lt;charT, traits&gt;&amp; e,
-                const charT* fmt,
-                regex_constants::match_flag_type flags =
-                  regex_constants::match_default);
-</ins></pre>
-
-<blockquote>
-<i>Effects:</i> [..]. If any matches are found then, for each such match, if <tt>!(flags &amp;
- regex_constants::format_no_copy)</tt> calls <tt>std::copy(m.prefix().first,
-m.prefix().second,
- out)</tt>, and then calls <tt>m.format(out, fmt, flags)</tt> <ins>for the first
-form of the function
- and <tt>m.format(out, fmt, fmt + char_traits&lt;charT&gt;::length(fmt), flags)</tt>
-for the second
- form</ins>. [..].
-</blockquote>
-</blockquote>
-</li>
-
-<li>
-<p>
-Change 28.11.4 [re.alg.replace] before p. 3 as indicated:
-</p>
-
-<blockquote><pre>template &lt;class traits, class charT<ins>, class ST, class SA,
-          class FST, class FSA</ins>&gt;
-  basic_string&lt;charT<ins>, ST, SA</ins>&gt;
-  regex_replace(const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; s,
-                const basic_regex&lt;charT, traits&gt;&amp; e,
-                const basic_string&lt;charT<ins>, FST, FSA</ins>&gt;&amp; fmt,
-                regex_constants::match_flag_type flags =
-                  regex_constants::match_default);
-
-<ins>
-template &lt;class traits, class charT, class ST, class SA&gt;
-  basic_string&lt;charT, ST, SA&gt;
-  regex_replace(const basic_string&lt;charT, ST, SA&gt;&amp; s,
-                const basic_regex&lt;charT, traits&gt;&amp; e,
-                const charT* fmt,
-                regex_constants::match_flag_type flags =
-                  regex_constants::match_default);
-</ins></pre>
 
-<blockquote>
-<i>Effects:</i> Constructs an empty string result of type <tt>basic_string&lt;charT<ins>,
-ST, SA</ins>&gt;</tt>, calls <tt>regex_replace(back_inserter(result), s.begin(), s.end(),
-e, fmt, flags)</tt>, and then returns <tt>result</tt>.
-</blockquote>
-</blockquote>
-</li>
+<p><b>Proposed resolution:</b></p>
+<p><del>
+<i>Effects:</i> Merges two sorted ranges <tt>[first1,last1)</tt> and
+<tt>[first2,last2)</tt> into the range <tt>[result, result + (last1 -
+first1) + (last2 - first2))</tt>.
+</del></p>
+<p><ins>
+<i>Effects:</i> Copies all the elements of the two sorted ranges
+<tt>[first1,last1)</tt> and <tt>[first2,last2)</tt> into the range
+<tt>[result, result_last)</tt>, where <tt>result_last</tt> is <tt>result
++ (last1 - first1) + (last2 - first2)</tt>, such that the resulting
+range satisfies <tt>is_sorted(result, result_last)</tt> or
+<tt>is_sorted(result, result_last, comp)</tt>, respectively.
+</ins></p>
 
-<li>
 <p>
-At the end of 28.11.4 [re.alg.replace] add the following new prototype description:
+<ins><i>Requires:</i></ins> The resulting range shall not overlap with
+either of the original ranges.  <del>The list 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 <tt>[first,last)</tt> other
+than <tt>first</tt>, the condition <tt>*i &lt; *(i - 1)</tt> or
+<tt>comp(*i, *(i - 1))</tt> will be <tt>false</tt>.</del>
 </p>
 
-<blockquote><pre><ins>
-template &lt;class traits, class charT, class ST, class SA&gt;
-  basic_string&lt;charT&gt;
-  regex_replace(const charT* s,
-                const basic_regex&lt;charT, traits&gt;&amp; e,
-                const basic_string&lt;charT, ST, SA&gt;&amp; fmt,
-                regex_constants::match_flag_type flags =
-                  regex_constants::match_default);
-</ins>
-
-<ins>
-template &lt;class traits, class charT&gt;
-  basic_string&lt;charT&gt;
-  regex_replace(const charT* s,
-                const basic_regex&lt;charT, traits&gt;&amp; e,
-                const charT* fmt,
-                regex_constants::match_flag_type flags =
-                  regex_constants::match_default);
-</ins></pre>
-
-<blockquote>
-<ins>
-<i>Effects:</i> Constructs an empty string result of type <tt>basic_string&lt;charT&gt;</tt>,
-calls <tt>regex_replace(back_inserter(result), s, s +
-char_traits&lt;charT&gt;::length(s),
-e, fmt, flags)</tt>, and then returns <tt>result</tt>.
-</ins>
-</blockquote>
-</blockquote>
-</li>
-
-</ol>
-
-
 
 
 
 
 
 <hr>
-<h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3>
-<p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-10-10  <b>Last modified:</b> 2009-07-28</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
+<h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
+<p><b>Section:</b> 20.5 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-02-18  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-This issue was split from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a> now just
-deals with changing the requirements of <tt>T</tt> in the <tt>Swappable</tt>
-requirement from <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> to
-<tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
+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>
-This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators.  Here
-is example code:
+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>namespace Mine {
-
-template &lt;class T&gt;
-struct proxy {...};
-
-template &lt;class T&gt;
-struct proxied_iterator
-{
-   typedef T value_type;
-   typedef proxy&lt;T&gt; reference;
-   reference operator*() const;
-   ...
-};
-
-struct A
-{
-   // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
-   void swap(A&amp;);
-   ...
-};
-
-void swap(A&amp;, A&amp;);
-void swap(proxy&lt;A&gt;, A&amp;);
-void swap(A&amp;, proxy&lt;A&gt;);
-void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);
+<blockquote><pre>pair() = default;
+</pre></blockquote>
 
-}  // Mine
+<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>
 
-Mine::proxied_iterator&lt;Mine::A&gt; i(...)
-Mine::A a;
-<b>swap(*i1, a);</b>
+<blockquote><pre>tuple() = default;
+tuple(const tuple&amp;) = default;
 </pre></blockquote>
 
 <p>
-The key point to note in the above code is that in the call to <tt>swap</tt>, <tt>*i1</tt>
-and <tt>a</tt> are different types (currently types can only be <tt>Swappable</tt> with the
-same type).  A secondary point is that to support proxies, one must be able to pass rvalues
-to <tt>swap</tt>.  But note that I am not stating that the general purpose <tt>std::swap</tt>
-should accept rvalues!  Only that overloaded <tt>swap</tt>s, as in the example above, be allowed
-to take rvalues.
+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>
-That is, no standard library code needs to change.  We simply need to have a more flexible
-definition of <tt>Swappable</tt>.
+** How does the committee wish to trade implementation
+efficiency versus implementation flexibility?
 </p>
 
 <p><i>[
@@ -8453,1468 +6945,1128 @@ Bellevue:
 
 <blockquote>
 <p>
-While we believe Concepts work will define a swappable concept, we
-should still resolve this issue if possible to give guidance to the
-Concepts work.
+General agreement; the first half of the issue is NAD.
 </p>
 <p>
-Would an ambiguous swap function in two namespaces found by ADL break
-this wording? Suggest that the phrase "valid expression" means such a
-pair of types would still not be swappable.
+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>
-Motivation is proxy-iterators, but facility is considerably more
-general. Are we happy going so far?
+Concensus: Go forward, but not at expense of other desired qualities.
 </p>
 <p>
-We think this wording is probably correct and probably an improvement on
-what's there in the WP. On the other hand, what's already there in the
-WP is awfully complicated. Why do we need the two bullet points? They're
-too implementation-centric. They don't add anything to the semantics of
-what swap() means, which is there in the post-condition. What's wrong
-with saying that types are swappable if you can call swap() and it
-satisfies the semantics of swapping?
+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-07-28 Reopened by Alisdair.  No longer solved by concepts.
+2009-05-27 Daniel adds:
 ]</i></p>
 
 
+<blockquote>
+This is partly solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1117">1117</a>.
+</blockquote>
 
+<p><i>[
+2009-07 Frankfurt:
+]</i></p>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Change X [utility.arg.requirements]:
-</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>
--1- The template definitions in the C++ Standard Library refer to various
-named requirements whose details are set out in tables 31-38. In these
-tables, <tt>T</tt> <ins>and <tt>V</tt> are</ins> <del>is a</del> type<ins>s</ins> to be supplied by a C++ program
-instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
-values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
-lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
-<tt>const</tt>) <tt>T</tt>; <del>and</del> <tt>rv</tt> is a non-<tt>const</tt>
-rvalue of type <tt>T</tt><ins>; <tt>w</tt> is a value of type <tt>T</tt>; and <tt>v</tt> is a value of type <tt>V</tt></ins>.
+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>
 
-<table border="1">
-<caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
-<tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
-<tr><td><tt>swap(<del>s</del><ins>w</ins>,<del>t</del><ins>v</ins>)</tt></td><td><tt>void</tt></td>
-<td><del><tt>t</tt></del><ins><tt>w</tt></ins> has the value originally
-held by <del><tt>u</tt></del><ins><tt>v</tt></ins>, and
-<del><tt>u</tt></del><ins><tt>v</tt></ins> has the value originally held
-by <del><tt>t</tt></del><ins><tt>w</tt></ins></td></tr>
-<tr><td colspan="3">
 <p>
-The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
+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>
-<ul>
-<li>
-<tt>T</tt> is <tt>Swappable</tt> if <ins><tt>T</tt> and <tt>V</tt> are
-the same type and </ins> <tt>T</tt> satisfies the
-<del><tt>CopyConstructible</tt></del>
-<ins><tt>MoveConstructible</tt></ins> requirements (Table <del>34</del>
-<ins>33</ins>) and the <del><tt>CopyAssignable</tt></del>
-<ins><tt>MoveAssignable</tt></ins> requirements (Table <del>36</del>
-<ins>35</ins>);
-</li>
-<li>
-<tt>T</tt> is <tt>Swappable</tt> <ins>with <tt>V</tt></ins> if a namespace scope function named
-<tt>swap</tt> exists in the same namespace as the definition of
-<tt>T</tt> <ins>or <tt>V</tt></ins>, such that the expression
-<tt>swap(<del>t</del><ins>w</ins>,<del>u</del> <ins>v</ins>)</tt> is valid and has the
-semantics described in this table.
-</li>
-</ul>
-</td></tr>
-</tbody></table>
-</blockquote>
-
 
+<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><b>Rationale:</b></p>
 <p><i>[
-post San Francisco:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Solved by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2758.pdf">N2758</a>.
+Leave as open. Alisdair to provide wording.
 </blockquote>
 
 
 
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
 
 
 
 <hr>
-<h3><a name="774"></a>774. Member swap undefined for most containers</h3>
-<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-01-14  <b>Last modified:</b> 2009-07-30</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
+<h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3>
+<p><b>Section:</b> 20.3.4 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2008-03-14  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>
-It appears most containers declare but do not define a member-swap
-function.
-</p>
-
-<p>
-This is unfortunate, as all overload the <tt>swap</tt> algorithm to call the
-member-swap function!
-(required for <tt>swappable</tt> guarantees [Table 37] and Container Requirements
-[Table 87])
-</p>
+<blockquote><pre>#include &lt;utility&gt;
 
-<p>
-Note in particular that Table 87 gives semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>,
-yet for all containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a circular
-definition.
-</p>
+int main()
+{
+   std::pair&lt;char *, char *&gt; p (0,0);
+}
+</pre></blockquote>
 
 <p>
-A quick survey of clause 23 shows that the following containers provide a
-definition for member-swap:
+I just got a bug report about that, because it's valid C++03, but not
+C++0x. The important realization, for me, is that the emplace
+proposal---which made <tt>push_back</tt> variadic, causing the <tt>push_back(0)</tt>
+issue---didn't cause this break in backward compatibility. The break
+actually happened when we added this pair constructor as part of adding
+rvalue references into the language, long before variadic templates or
+emplace came along:
 </p>
 
-<blockquote><pre>array
-queue
-stack
-vector
+<blockquote><pre>template&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; y);
 </pre></blockquote>
 
 <p>
-Whereas the following declare it, but do not define the semantics:
+Now, concepts will address this issue by constraining that <tt>pair</tt>
+constructor to only <tt>U</tt>'s and <tt>V</tt>'s that can properly construct "first" and
+"second", e.g. (from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf">N2322</a>):
 </p>
 
-<blockquote><pre>deque
-list
-map
-multimap
-multiset
-priority_queue
-set
-unordered_map
-unordered_multi_map
-unordered_multi_set
-unordered_set
+<blockquote><pre>template&lt;class U , class V &gt;
+requires Constructible&lt;T1, U&amp;&amp;&gt; &amp;&amp; Constructible&lt;T2, V&amp;&amp;&gt;
+pair(U&amp;&amp; x , V&amp;&amp; y );
 </pre></blockquote>
 
-<p>
-Suggested resolution:
-</p>
-<blockquote>
-Provide a definition for each of the affected containers...
-</blockquote>
-
 <p><i>[
-Bellevue:
+San Francisco:
 ]</i></p>
 
 
 <blockquote>
-Move to Open and ask Alisdair to provide wording.
+<p>
+Suggested to resolve using pass-by-value for that case.
+</p>
+<p>
+Side question: Should pair interoperate with tuples? Can construct a
+tuple of a pair, but not a pair from a two-element tuple.
+</p>
+<p>
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a>.
+</p>
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
 ]</i></p>
 
 
-<blockquote>
-Daniel to provide wording.
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>
-is no longer applicable.
-</blockquote>
-
 <p><i>[
-2009-07-28 Daniel provided wording.
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-<ol>
-<li>
-It assumes that the proposed resolution for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#883">883</a> is applied,
-which breaks the circularity of definition between member
-<tt>swap</tt> and free <tt>swap</tt>.
-</li>
-
-<li>
-It uses the notation of the pre-concept allocator trait
-<tt>allocator_propagation_map</tt>, which might be renamed after the
-next refactoring phase of generalized allocators.
-</li>
-
-<li>
-It requires that compare objects, key equal functions and
-hash functions in containers are swapped via unqualified free
-<tt>swap</tt> according to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</a>.
-</li>
-</ol>
+Leave as open. Howard to provide wording.
 </blockquote>
 
 
+
 <p><b>Proposed resolution:</b></p>
-<ol>
-<li>
 <p>
-Add a new Throws clause just after X [allocator.propagation.map]/5:
 </p>
 
-<blockquote><pre>static void swap(Alloc&amp; a, Alloc&amp; b);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> [..]
-</p>
 
-<p>
-<ins><i>Throws:</i> Nothing.</ins>
-</p>
-</blockquote>
-</blockquote>
+<p><b>Rationale:</b></p>
 <p><i>[
-This exception requirement is added, such that it's combination with the
-general container requirements of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
-[container.requirements.general]/9
-make it unambiguously clear that the following descriptions of "swaps the
-allocators" have the following meaning: (a) This swap is done by calling
-<tt>allocator_propagation_map&lt;allocator_type&gt;::swap</tt> and (b) This allocator
-swap does never propagate an exception
+San Francisco:
 ]</i></p>
 
-</li>
-
-<li>
-<p>
-Change 23.2.4.1 [associative.reqmts.except]/3 as indicated:
-</p>
 
 <blockquote>
-For associative containers, no <tt>swap</tt> function throws an exception unless that
-exception is thrown by the <del>copy constructor or copy assignment
-operator</del>
-<ins><tt>swap</tt></ins> of the container's <tt>Pred</tt> object<ins>s</ins><del> (if any)</del>.
+Solved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
 </blockquote>
-</li>
 
-<li>
-<p>
-Change 23.2.5.1 [unord.req.except]/3 as indicated:
-</p>
 
-<blockquote>
-For unordered associative containers, no <tt>swap</tt> function throws an
-exception unless
-that exception is thrown by the <del>copy constructor or copy
-assignment operator</del>
-<ins><tt>swap</tt></ins> of the container's <tt>Hash</tt> or <tt>Pred</tt> object<ins>s,
-respectively</ins><del> (if any)</del>.
-</blockquote>
-</li>
 
-<li>
+
+
+
+
+<hr>
+<h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3>
+<p><b>Section:</b> 20.7.15.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-16  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Insert a new paragraph just after 23.3 [sequences]/1:
+<tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as
+described in the rvalue core proposal.
 </p>
 
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
 <blockquote>
-<ins>In addition to being available via inclusion of the <tt>&lt;algorithm&gt;</tt> header,
-the <tt>swap</tt> function templates in 25.4.3 [alg.swap] are also available when the
-header <tt>&lt;queue&gt;</tt> is included.</ins>
+According to Doug Gregor, as far as <tt>std::function</tt> is concerned, perfect
+forwarding can not be obtained because of type erasure. Not everyone
+agreed with this diagnosis of forwarding.
 </blockquote>
 
 <p><i>[
-There is a new issue in process that will suggest a minimum header for <tt>swap</tt>
-and <tt>move</tt>. If this one is provided, this text can be removed and the header
-dependency should be added to <tt>&lt;queue&gt;</tt>
+2009-05-01 Howard adds:
 ]</i></p>
 
 
-</li>
-
-<li>
+<blockquote>
 <p>
-Add one further clause at the end of 23.3.1.2 [array.special]:
+Sebastian Gesemann brought to my attention that the <tt>CopyConstructible</tt>
+requirement on <tt>function</tt>'s <tt>ArgTypes...</tt> is an unnecessary
+restriction.
 </p>
-<p><i>[This part is added, because otherwise <tt>array::swap</tt> would otherwise
-contradict the
-general contract of 23.2.1 [container.requirements.general] p. 10 b. 5]</i></p>
 
+<blockquote><pre>template&lt;Returnable R, <b>CopyConstructible</b>... ArgTypes&gt;
+class function&lt;R(ArgTypes...)&gt;
+...
+</pre></blockquote>
 
-<blockquote>
-<ins><i>Throws:</i> Nothing, unless one of the element-wise <tt>swap</tt> calls throws
-an exception.</ins>
-</blockquote>
-</li>
-
-<li>
-<ol type="a">
-<li>
 <p>
-In 23.3.2 [deque], class template deque synopsis change as indicated:
+On further investigation, this complaint seemed to be the same
+issue as this one.  I believe the reason <tt>CopyConstructible</tt> was put
+on <tt>ArgTypes</tt> in the first place was because of the nature of the
+<i>invoke</i> member:
 </p>
-<blockquote><pre>void swap(deque<del>&lt;T,Alloc&gt;</del>&amp;);
-</pre></blockquote>
-</li>
 
-<li>
-<p>
-At the end of 23.3.2.3 [deque.modifiers] add as indicated:
-</p>
+<blockquote><pre>template&lt;class R, class ...ArgTypes&gt;
+R
+function&lt;R(ArgTypes...)&gt;::operator()(ArgTypes... arg) const
+{
+    if (f_ == 0)
+        throw bad_function_call();
+    return (*f_)(arg...);
+}
+</pre></blockquote>
 
-<blockquote><pre><ins>void swap(deque&amp; x);</ins>
-</pre>
-<blockquote>
-<p>
-<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
-with that of <tt>x</tt>.</ins>
-</p>
 <p>
-<ins><i>Complexity:</i> Constant time.</ins>
+However now with rvalue-refs, "by value" no longer implies <tt>CopyConstructible</tt>
+(as Sebastian correctly points out).  If rvalue arguments are supplied, <tt>MoveConstructible</tt>
+is sufficient.  Furthermore, the constraint need not be applied in <tt>function</tt>
+if I understand correctly.  Rather the client must apply the proper constraints
+at the call site.  Therefore, at the very least, I recommend that <tt>CopyConstructible</tt>
+be removed from the template class <tt>function</tt>.
 </p>
-</blockquote>
-</blockquote>
-</li>
-</ol>
-</li>
 
-<li>
-<ol type="a">
-<li>
 <p>
-In 23.3.3 [forwardlist], class template <tt>forward_list</tt> synposis change as indicated:
+Furthermore we need to mandate that the <i>invoker</i> is coded as:
 </p>
 
-<blockquote><pre>void swap(forward_list<del>&lt;T,Allocator&gt;</del>&amp;);
+<blockquote><pre>template&lt;class R, class ...ArgTypes&gt;
+R
+function&lt;R(ArgTypes...)&gt;::operator()(ArgTypes... arg) const
+{
+    if (f_ == 0)
+        throw bad_function_call();
+    return (*f_)(<b>std::forward&lt;ArgTypes&gt;(</b>arg<b>)</b>...);
+}
 </pre></blockquote>
-</li>
 
-<li>
 <p>
-At the end of 23.3.3.4 [forwardlist.modifiers] add as indicated:
+Note that <tt>ArgTypes&amp;&amp;</tt> (the "perfect forwarding signature") is not 
+appropriate here as this is not a deduced context for <tt>ArgTypes</tt>.  Instead
+the client's arguments must implicitly convert to the non-deduced <tt>ArgType</tt>
+type.  Catching these arguments by value makes sense to enable decay.
 </p>
 
-<blockquote><pre><ins>void swap(forward_list&amp; x);</ins>
-</pre>
-<blockquote>
-<p>
-<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
-with that of <tt>x</tt>.</ins>
-</p>
 <p>
-<ins><i>Complexity:</i> Constant time.</ins>
+Next <tt>forward</tt> is used to move the <tt>ArgTypes</tt> as efficiently as
+possible, and also with minimum requirements (not <tt>CopyConstructible</tt>)
+to the type-erased functor.  For object types, this will be a <tt>move</tt>.  For
+reference type <tt>ArgTypes</tt>, this will be a copy.  The end result <em>must</em> be
+that the following is a valid program:
 </p>
-</blockquote>
-</blockquote>
-</li>
-</ol>
-</li>
 
-<li>
-<ol type="a">
-<li>
-<p>
-In 23.3.4 [list], class template <tt>list</tt> synopsis change as indicated:
-</p>
+<blockquote><pre>#include &lt;functional&gt;
+#include &lt;memory&gt;
+#include &lt;cassert&gt;
 
-<blockquote><pre>void swap(list<del>&lt;T,Allocator&gt;</del>&amp;);
+std::unique_ptr&lt;int&gt;
+f(std::unique_ptr&lt;int&gt; p, int&amp; i)
+{
+    ++i;
+    return std::move(p);
+}
+
+int main()
+{
+    int i = 2;
+    std::function&lt;std::unique_ptr&lt;int&gt;(std::unique_ptr&lt;int&gt;,
+                                       int&amp;&gt; g(f);
+    std::unique_ptr&lt;int&gt; p = g(std::unique_ptr&lt;int&gt;(new int(1)), i);
+    assert(*p == 1);
+    assert(i == 3);
+}
 </pre></blockquote>
-</li>
 
-<li>
-<p>
-At the end of 23.3.4.3 [list.modifiers] add as indicated:
-</p>
+<p><i>[
+Tested in pre-concepts rvalue-ref-enabled compiler.
+]</i></p>
 
-<blockquote><pre><ins>void swap(list&amp; x);</ins>
-</pre>
 
-<blockquote>
 <p>
-<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
-with that of <tt>x</tt>.</ins>
+In the example above, the first <tt>ArgType</tt> is <tt>unique_ptr&lt;int&gt;</tt>
+and the second <tt>ArgType</tt> is <tt>int&amp;</tt>.  Both <em>must</em> work!
 </p>
 
-<p>
-<ins><i>Complexity:</i> Constant time.</ins>
-</p>
 </blockquote>
-</blockquote>
-</li>
-</ol>
-</li>
-
-<li>
-<p>
-At the end of 23.3.5.2.2 [priqueue.members] add a new prototype description:
-</p>
-
-<blockquote><pre><ins>void swap(priority_queue&amp; q);</ins>
-</pre>
-<blockquote>
-<p>
-<ins><i>Requires:</i> <tt>Compare</tt> shall satisfy the <tt>Swappable</tt> requirements
-( [swappable]).</ins>
-</p>
 
 <p><i>[
-This requirement is added to ensure that even a user defined <tt>swap</tt>
-which is found by
-ADL for <tt>Compare</tt> satisfies the <tt>Swappable</tt> requirements
+2009-05-27 Daniel adds:
 ]</i></p>
 
 
+<blockquote>
 <p>
-<ins><i>Effects:</i> <tt>this-&gt;c.swap(q.c); swap(this-&gt;comp, q.comp);</tt></ins>
-</p>
-<p>
-<ins><i>Throws:</i> What and if <tt>c.swap(q.c)</tt> and <tt>swap(comp, q.comp)</tt> throws.</ins>
+in the 2009-05-01 comment of above mentioned issue Howard
 </p>
-</blockquote>
-</blockquote>
-<p><i>[
-This part is added, because otherwise <tt>priority_queue::swap</tt> would otherwise
-contradict the general contract of 23.2.1 [container.requirements.general] p. 10 b. 5
-]</i></p>
-
-</li>
 
-<li>
 <ol type="a">
 <li>
+Recommends to replace the <tt>CopyConstructible</tt> requirement by a
+<tt>MoveConstructible</tt> requirement
+</li>
+<li>
+Says: "Furthermore, the constraint need not be applied in <tt>function</tt> if I
+understand correctly. Rather the client must apply the proper constraints
+at the call site"
+</li>
+</ol>
 <p>
-In 23.3.6 [vector], class template <tt>vector</tt> synopsis change as indicated:
+I'm fine with (a), but I think comment (b) is incorrect, at least in the
+sense I read these sentences. Let's look at Howard's example code:
 </p>
 
-<blockquote><pre>void swap(vector<del>&lt;T,Allocator&gt;</del>&amp;);
+<blockquote><pre>function&lt;R(ArgTypes...)&gt;::operator()(ArgTypes... arg) const
+{
+   if (f_ == 0)
+       throw bad_function_call();
+   return (*f_)(std::forward&lt;ArgTypes&gt;(arg)...);
+}
 </pre></blockquote>
-</li>
 
-<li>
 <p>
-Change 23.3.6.2 [vector.capacity]/8 as indicated:
+In the constrained scope of this <tt>operator()</tt> overload the expression
+"<tt>(*f_)(std::forward&lt;ArgTypes&gt;(arg)...)</tt>" must be valid. How can it
+do so, if <tt>ArgTypes</tt> aren't at least <tt>MoveConstructible</tt>?
 </p>
+</blockquote>
+
+<p><i>[
+2009-07 Frankfurt:
+]</i></p>
 
-<blockquote><pre>void swap(vector<del>&lt;T,Allocator&gt;</del>&amp; x);
-</pre>
 
 <blockquote>
-<i>Effects:</i> Exchanges the contents and <tt>capacity()</tt> <ins>and swaps the
-allocators</ins>
-of <tt>*this</tt> with that of <tt>x</tt>.
-</blockquote>
+Leave this open and wait until concepts are removed from the Working
+Draft so that we know how to write the proposed resolution in terms of
+diffs to otherwise stable text.
 </blockquote>
-</li>
-</ol>
-</li>
 
-<li>
-<p>
-Insert a new paragraph just before 23.4 [associative]/1:
-</p>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
 
 <blockquote>
-<ins>In addition to being available via inclusion of the <tt>&lt;algorithm&gt;</tt> header,
-the <tt>swap</tt> function templates in 25.4.3 [alg.swap] are also available when any of the
-headers <tt>&lt;map&gt;</tt> or <tt>&lt;set&gt;</tt> are included.</ins>
+Leave as open. Howard to provide wording. Howard welcomes any help.
 </blockquote>
-</li>
 
-<li>
-<ol type="a">
-<li>
-<p>
-In 23.4.1 [map], class template <tt>map</tt> synopsis change as indicated:
-</p>
 
-<blockquote><pre>void swap(map<del>&lt;Key,T,Compare,Allocator&gt;</del>&amp;);
-</pre></blockquote>
-</li>
 
-<li>
+<p><b>Proposed resolution:</b></p>
 <p>
-At the end of 23.4.1.3 [map.modifiers] add as indicated:
 </p>
 
-<blockquote><pre><ins>void swap(map&amp; x);</ins>
-</pre>
 
-<blockquote>
-<p>
-<ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
-( [swappable]).</ins>
-</p>
 
-<p><i>[
-This requirement is added to ensure that even a user defined <tt>swap</tt>
-which is found by ADL for <tt>Compare</tt> satisfies the <tt>Swappable</tt>
-requirements
-]</i></p>
 
 
+<hr>
+<h3><a name="816"></a>816. Should <tt>bind()</tt>'s returned functor have a nofail copy ctor when <tt>bind()</tt> is nofail?</h3>
+<p><b>Section:</b> 20.7.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2008-02-08  <b>Last modified:</b> 2009-11-07</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
-with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
-of <tt>*this</tt> and <tt>x</tt>.</ins>
+Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> notes that <tt>bind(f, t1, ..., tN)</tt>
+should be nofail when <tt>f, t1, ..., tN</tt> have nofail copy ctors.
 </p>
-
 <p>
-<ins><i>Complexity:</i> Constant time</ins>
+However, no guarantees are provided for the copy ctor of the functor
+returned by <tt>bind()</tt>.  (It's guaranteed to have a copy ctor, which can
+throw implementation-defined exceptions: <tt>bind()</tt> returns a forwarding
+call wrapper, TR1 3.6.3/2.  A forwarding call wrapper is a call wrapper,
+TR1 3.3/4.  Every call wrapper shall be CopyConstructible, TR1 3.3/4.
+Everything without an exception-specification may throw
+implementation-defined exceptions unless otherwise specified, C++03
+17.4.4.8/3.)
+</p>
+<p>
+Should the nofail guarantee requested by Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> be extended
+to cover both calling <tt>bind()</tt> and copying the returned functor?
 </p>
+
+<p><i>[
+Howard adds:
+]</i></p>
+
+
+<blockquote>
+<tt>tuple</tt> construction should probably have a similar guarantee.
 </blockquote>
+
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<blockquote>
+Howard to provide wording.
 </blockquote>
-</li>
-</ol>
-</li>
 
-<li>
-<ol type="a">
-<li>
-<p>
-In 23.4.2 [multimap], class template <tt>multimap</tt> synopsis change as indicated:
-</p>
+<p><i>[
+Post Summit, Anthony provided wording.
+]</i></p>
 
-<blockquote><pre>void swap(multimap<del>&lt;Key,T,Compare,Allocator&gt;</del>&amp;);
-</pre></blockquote>
-</li>
 
-<li>
-<p>
-At the end of 23.4.2.2 [multimap.modifiers] add as indicated:
-</p>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Part of all of this issue appears to be rendered moot
+by the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a> (q.v.).
+We recommend the issues be considered simultaneously
+(or possibly even merged)
+to ensure there is no overlap.
+Move to Open, and likewise for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>.
+</blockquote>
+
+<p><i>[
+2009-07 Frankfurt:
+]</i></p>
+
+
+<blockquote>
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a> (see below). Leave Open.
+</blockquote>
+
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
-<blockquote><pre><ins>void swap(multimap&amp; x);</ins>
-</pre>
 
 <blockquote>
+Move to Ready. Decoupling from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-<ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
-( [swappable]).</ins>
+Add a new sentence to the end of paragraphs 2 and 4 of 20.7.11.1.3 [func.bind.bind]:
 </p>
+
+<blockquote>
 <p>
-<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
-with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
-of <tt>*this</tt> and <tt>x</tt>.</ins>
+-2- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a weak result type (20.6.2). The effect of <tt>g(u1, u2,
+..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, Callable&lt;F cv,V1, V2, ..., VN&gt;::result_type)</tt>, where <i>cv</i>
+represents the <i>cv</i>-qualifiers of <tt>g</tt> and the values and types of the bound arguments
+<tt>v1, v2, ..., vN</tt> are determined as specified below.
+<ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
+exception if and only if the corresponding constructor of <tt>F</tt> or any of the types
+in <tt>BoundArgs...</tt> throw an exception.</ins>
 </p>
+<p>...</p>
 <p>
-<ins><i>Complexity:</i> Constant time</ins>
+-5- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a nested type <tt>result_type</tt> defined as a synonym
+for <tt>R</tt>. The effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, R)</tt>, where the
+values and types of the bound arguments <tt>v1, v2, ..., vN</tt> are determined as specified below.
+<ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
+exception if and only if the corresponding constructor of <tt>F</tt> or any of the types
+in <tt>BoundArgs...</tt> throw an exception.</ins>
 </p>
+
 </blockquote>
-</blockquote>
-</li>
-</ol>
-</li>
 
-<li>
-<ol type="a">
-<li>
-<p>
-In 23.4.3 [set], class template <tt>set</tt> synopsis change as indicated:
-</p>
 
-<blockquote><pre>void swap(set<del>&lt;Key,Compare,Allocator&gt;</del>&amp;);
-</pre></blockquote>
-</li>
 
-<li>
-<p>
-After section 23.4.3.1 [set.cons] add a new section <ins><tt>set</tt> modifiers
- [set.modifiers]</ins>
-and add the following paragraphs:
-</p>
 
-<blockquote><pre><ins>void swap(set&amp; x);</ins>
-</pre>
 
-<blockquote>
+<hr>
+<h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3>
+<p><b>Section:</b> 20.7.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-03-17  <b>Last modified:</b> 2009-11-08</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses US 72, JP 38 and DE 21</b></p>
+
 <p>
-<ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
-( [swappable]).</ins>
+The functor returned by <tt>bind()</tt> should have a move constructor that
+requires only move construction of its contained functor and bound arguments.
+That way move-only functors can be passed to objects such as <tt>thread</tt>.
 </p>
-
 <p>
-<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
-with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
-of <tt>*this</tt> and <tt>x</tt>.</ins>
+This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>.
 </p>
 
 <p>
-<ins>Complexity: Constant time</ins>
+US 72:
 </p>
+
+<blockquote>
+<tt>bind</tt> should support move-only functors and bound arguments.
 </blockquote>
-</blockquote>
-</li>
-</ol>
-</li>
 
-<li>
-<ol type="a">
-<li>
 <p>
-In 23.4.4 [multiset], class template <tt>multiset</tt> synosis, change as indicated:
+JP 38:
 </p>
 
-<blockquote><pre>void swap(multiset<del>&lt;Key,Compare,Allocator&gt;</del>&amp;);
-</pre></blockquote>
-</li>
-
-<li>
+<blockquote>
 <p>
-After section 23.4.4.1 [multiset.cons] add a new section <ins><tt>multiset</tt> modifiers
- [multiset.modifiers]</ins> and add the following paragraphs:
+add the move requirement for bind's return type.
+</p>
+<p>
+For example, assume following <tt>th1</tt> and <tt>th2</tt>,
 </p>
 
-<blockquote><pre><ins>void swap(multiset&amp; x);</ins>
-</pre>
+<blockquote><pre>void f(vector&lt;int&gt; v) { }
+
+vector&lt;int&gt; v{ ... };
+thread th1([v]{ f(v); });
+thread th2(bind(f, v));
+</pre></blockquote>
 
-<blockquote>
 <p>
-<ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
-( [swappable]).</ins>
+When function object are set to thread, <tt>v</tt> is moved to <tt>th1</tt>'s lambda
+expression in a Move Constructor of lambda expression because <tt>th1</tt>'s lambda
+expression has a Move Constructor. But <tt>bind</tt> of <tt>th2</tt>'s
+return type doesn't have the requirement of Move, so it may not
+moved but copied.
 </p>
-
 <p>
-<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
-with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
-of <tt>*this</tt> and <tt>x</tt>.</ins>
+Add the requirement of move to get rid of this useless copy.
 </p>
-
 <p>
-<ins><i>Complexity:</i> Constant time</ins>
+And also, add the <tt>MoveConstructible</tt> as well as <tt>CopyConstructible</tt>.
 </p>
 </blockquote>
-</blockquote>
-</li>
-</ol>
-</li>
 
-<li>
 <p>
-Insert a new paragraph just before 23.5 [unord]/1:
+DE 21
 </p>
 
 <blockquote>
-<ins>In addition to being available via inclusion of the <tt>&lt;algorithm&gt;</tt> header,
-the <tt>swap</tt> function templates in 25.4.3 [alg.swap] are also available when any of the
-headers <tt>&lt;unordered_map&gt;</tt> or <tt>&lt;unordered_set&gt;</tt> are included.</ins>
+The specification for bind claims twice that "the values and types for
+the bound arguments v1, v2, ..., vN are determined as specified below".
+No such specification appears to exist.
 </blockquote>
 
-</li>
-
-<li>
-<p>
-After section 23.5.1.2 [unord.map.elem] add a new section <ins>unordered_map
-modifiers  [unord.map.modifiers]</ins> and add the following paragraphs:
-</p>
+<p><i>[
+San Francisco:
+]</i></p>
 
-<blockquote><pre><ins>void swap(unordered_map&amp; x);</ins>
-</pre>
 
 <blockquote>
-<p>
-<ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
-( [swappable]).</ins>
-</p>
+Howard to provide wording.
+</blockquote>
 
 <p><i>[
-This requirement is added to ensure that even a user defined <tt>swap</tt>
-which is found by ADL for <tt>Hash</tt> and <tt>Pred</tt> satisfies the <tt>Swappable</tt>
-requirements
+Post Summit Alisdair and Howard provided wording.
 ]</i></p>
 
 
+<blockquote>
 <p>
-<ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
-allocators of <tt>*this</tt>
-with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
-and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt>.</ins>
+Several issues are being combined in this resolution.  They are all touching the
+same words so this is an attempt to keep one issue from stepping on another, and
+a place to see the complete solution in one place.
 </p>
 
-<p>
-<ins><i>Complexity:</i> Constant time</ins>
-</p>
-</blockquote>
-</blockquote>
+<ol>
+<li>
+<tt>bind</tt> needs to be "moved".
 </li>
-
 <li>
-<p>
-After section 23.5.2.1 [unord.multimap.cnstr] add a new section
-<ins>unordered_multimap
-modifiers  [unord.multimap.modifiers]</ins> and add the following paragraphs:
-</p>
+20.7.11.1.3 [func.bind.bind]/p3, p6 and p7 were accidently removed from N2798.
+</li>
+<li>
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a> argues for a way to pass by &amp;&amp; for
+efficiency but retain the decaying behavior of pass by value for the
+<tt>thread</tt> constructor.  That same solution is applicable here.
+</li>
+</ol>
+</blockquote>
 
-<blockquote><pre><ins>void swap(unordered_multimap&amp; x);</ins>
-</pre>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
 <blockquote>
 <p>
-<ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
-( [swappable]).</ins>
-</p>
-
-<p>
-<ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
-allocators of <tt>*this</tt>
-with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
-and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt></ins>
+We were going to recommend moving this issue to Tentatively Ready
+until we noticed potential overlap with issue 816 (q.v.).
 </p>
 <p>
-<ins><i>Complexity:</i> Constant time</ins>
+Move to Open,
+and recommend both issues be considered together
+(and possibly merged).
 </p>
 </blockquote>
-</blockquote>
-</li>
 
-<li>
-<p>
-After section 23.5.3.1 [unord.set.cnstr] add a new section
-<ins>unordered_set modifiers
- [unord.set.modifiers]</ins> and add the following paragraphs:
-</p>
+<p><i>[
+2009-07 Frankfurt:
+]</i></p>
 
-<blockquote><pre><ins>void swap(unordered_set&amp; x);</ins>
-</pre>
 
 <blockquote>
-<p>
-<ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
-( [swappable]).</ins>
-</p>
-
-<p>
-<ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
-allocators of <tt>*this</tt>
-with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
-and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt></ins>
-</p>
-
-<p>
-<ins><i>Complexity:</i> Constant time</ins>
-</p>
-</blockquote>
+The proposed resolution uses concepts. Leave Open.
 </blockquote>
-</li>
 
-<li>
-<p>
-After section 23.5.4.1 [unord.multiset.cnstr] add a new section
-<ins>unordered_multiset
-modifiers  [unord.multiset.modifiers]</ins> and add the following paragraphs:
-</p>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
-<blockquote><pre><ins>void swap(unordered_multiset&amp; x);</ins>
-</pre>
 
 <blockquote>
-<p>
-<ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
-( [swappable]).</ins>
-</p>
-
-<p>
-<ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
-allocators of <tt>*this</tt>
-with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
-and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt></ins>
-</p>
-<p>
-<ins><i>Complexity:</i> Constant time</ins>
-</p>
+Leave as Open. Howard to provide deconceptified wording.
 </blockquote>
-</blockquote>
-</li>
-
-</ol>
-
 
+<p><i>[
+2009-11-07 Howard updates wording.
+]</i></p>
 
 
 
 
-<hr>
-<h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3>
-<p><b>Section:</b> 25.5.4 [alg.merge] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-25  <b>Last modified:</b> 2009-07-16</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Proposed resolution:</b></p>
 <p>
-Though issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> has fixed many open issues, it seems that some are still open:
+Change 20.7 [function.objects] p2:
 </p>
 
+<blockquote><pre>template&lt;class F<del>n</del>, class... <del>Types</del> <ins>BoundArgs</ins>&gt;
+  <i>unspecified</i> bind(F<del>n</del><ins>&amp;&amp;</ins>, <del>Types</del> <ins>BoundArgs&amp;&amp;</ins>...);
+template&lt;class R, class F<del>n</del>, class... <del>Types</del> <ins>BoundArgs</ins>&gt;
+  <i>unspecified</i> bind(F<del>n</del><ins>&amp;&amp;</ins>, <del>Types</del> <ins>BoundArgs&amp;&amp;</ins>...);
+</pre></blockquote>
+
 <p>
-Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.5.4 [alg.merge] in N2461
-have no Requires element and the Effects element contains some requirements,
-which is probably editorial. Worse is that:
+Change 20.7.11.1.3 [func.bind.bind]:
 </p>
 
-<ul>
-<li>
-no assignment requirements are specified (neither implicit nor explicit).
-</li>
-
-<li>
-the effects clause just speaks of "merges", which is badly worded
-near to a circular definition.
-</li>
-
-<li>
-p. 2 mentions a range <tt>[first, last)</tt>, which is not defined by the
-function arguments or otherwise.
-</li>
+<blockquote>
+<p><ins>
+Within this clause:
+</ins></p>
 
-<li>
-p. 2 says "according to the ordering defined by comp" which is both
-incomplete (because
-this excludes the first variant with &lt;) and redundant (because the
-following subordinate
-clause mentions comp again)
-</li>
+<ul>
+<li><ins>
+Let <tt>FD</tt> be a synonym for the type <tt>decay&lt;F&gt;::type</tt>.
+</ins></li>
+<li><ins>
+Let <tt>fd</tt> be an lvalue of type <tt>FD</tt> constructed from
+<tt>std::forward&lt;F&gt;(f)</tt>.
+</ins></li>
+<li><ins>
+Let <tt>Ti</tt> be a synonym for the i<sup><i>th</i></sup> type in the
+parameter pack <tt>BoundArgs</tt>.
+</ins></li>
+<li><ins>
+Let <tt>TiD</tt> be a synonym for the type <tt>decay&lt;Ti&gt;::type</tt>.
+</ins></li>
+<li><ins>
+Let <tt>ti</tt> be the i<sup><i>th</i></sup> argument in <tt>bound_args</tt>.
+</ins></li>
+<li><ins>
+Let <tt>tid</tt> be an lvalue of type <tt>TiD</tt> constructed from
+<tt>std::forward&lt;Ti&gt;(ti)</tt>.
+</ins></li>
 </ul>
 
-<p><i>[
-Post Summit Alisdair adds:
-]</i></p>
-
+<pre>template&lt;class F, class... BoundArgs&gt;
+  <i>unspecified</i> bind(F<ins>&amp;&amp;</ins> f, BoundArgs<ins>&amp;&amp;</ins>... bound_args);
+</pre>
 
 <blockquote>
 <p>
-Suggest:
-</p>
-<blockquote>
-(where <tt>last</tt> is equal to <tt>next(result, distance(first1, last1) +
-distance(first2, last2))</tt>, such that resulting range will be sorted in
-non-decreasing order; that is, for every iterator <tt>i</tt> in <tt>[result,last)</tt> other
-than <tt>result</tt>, the condition <tt>*i &lt; *prev(i)</tt> or, respectively, <tt>comp(*i,
-*prev(i))</tt> will be <tt>false</tt>.
-</blockquote>
-
-<p>
-Note that this might still not be technically accurate in the case of
-<tt>InputIterators</tt>, depending on other resolutions working their way through the
-system (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>).
+-1- <i>Requires:</i>
+<ins><tt>is_constructible&lt;FD, F&gt;::value</tt>
+shall be <tt>true</tt>.</ins>
+<ins><tt>is_constructible&lt;TiD, Ti&gt;::value</tt>
+shall be <tt>true</tt></ins>.
+<del><tt>F</tt> and each <tt>Ti</tt> in
+<tt>BoundArgs</tt> shall be CopyConstructible.</del>
+<tt><i>INVOKE</i>(f<ins>d</ins>, w1, w2, ..., wN)</tt> (20.7.2 [func.require]) shall be a valid expression for some values
+<i>w1, w2, ..., wN</i>, where <tt>N == sizeof...(bound_args)</tt>.
 </p>
-</blockquote>
-
-<p><i>[
-Post Summit Daniel adds:
-]</i></p>
-
-
-<blockquote>
-If we want to use <tt>prev</tt> and <tt>next</tt> here (Note: <tt>merge</tt>
-is sufficiently satisfied with <tt>InputIterator</tt>) we should instead *add* more to
-25 [algorithms]/6, but I can currently not propose any good wording for this.
-</blockquote>
-
-<p><i>[
-Batavia (2009-05):
-]</i></p>
-
-<blockquote>
 <p>
-Pete points out the existing wording in [algorithms]/4
-that permits the use of + in algorithm specifications.
+-2- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a weak
+result type (20.7.2 [func.require]). The effect of <tt>g(u1, u2,
+..., uM)</tt> shall be <tt><i>INVOKE</i>(f<ins>d</ins>, v1, v2, ..., vN,
+result_of&lt;F<ins>D</ins> <i>cv</i> (V1, V2, ..., VN)&gt;::type)</tt>, where
+<i>cv</i> represents the <i>cv</i>-qualifiers of <tt>g</tt> and the
+values and types of the bound arguments <tt>v1, v2, ..., vN</tt> are
+determined as specified below.
+<ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
+exception if and only if the corresponding constructor of <tt>FD</tt> or any of the types
+<tt>TiD</tt> throw an exception.</ins>
 </p>
 <p>
-Alisdair points out that that wording may not apply to input iterators.
+-3- <i>Throws:</i> Nothing unless the <del>copy</del>
+construct<ins>ion</ins><del>or</del> of
+<tt><del>F</del><ins>fd</ins></tt> or of one of the <ins>values
+<tt>tid</tt></ins> <del>types in the <tt>BoundArgs...</tt> pack
+expansion</del> throws an exception.
 </p>
 <p>
-Move to Review.
+<ins>
+<i>Remarks:</i> The <i>unspecified</i> return type shall be
+<tt>MoveConstructible</tt>.  If all of <tt>FD</tt> and <tt>TiD</tt> are
+<tt>CopyConstructible</tt> then the <i>unspecified</i> return type shall
+be <tt>CopyConstructible</tt>. [<i>Note:</i> This implies that all of
+<tt>FD</tt> and <tt>TiD</tt> shall be <tt>MoveConstructible</tt> &#8212;
+<i>end note</i>]
+</ins>
 </p>
 </blockquote>
 
-<p><i>[
-2009-07 Frankfurt:
-]</i></p>
-
+<pre>template&lt;class R, class F, class... BoundArgs&gt;
+  <i>unspecified</i> bind(F<ins>&amp;&amp;</ins> f, BoundArgs<ins>&amp;&amp;</ins>... bound_args);
+</pre>
 
 <blockquote>
-Move to Ready.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-In 25.5.4 [alg.merge] replace p.1+ 2:
+-4- <i>Requires:</i>
+<ins><tt>is_constructible&lt;FD, F&gt;::value</tt>
+shall be <tt>true</tt>.</ins>
+<ins><tt>is_constructible&lt;TiD, Ti&gt;::value</tt>
+shall be <tt>true</tt></ins>.
+<del><tt>F</tt> and each <tt>Ti</tt> in
+<tt>BoundArgs</tt> shall be CopyConstructible.</del>
+<tt><i>INVOKE</i>(f<ins>d</ins>, w1,
+w2, ..., wN)</tt> shall be a valid expression for some values <i>w1, w2,
+..., wN</i>, where <tt>N == sizeof...(bound_args)</tt>.
+</p>
+<p>
+-5- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a nested
+type <tt>result_type</tt> defined as a synonym for <tt>R</tt>. The
+effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(f<ins>d</ins>, v1,
+v2, ..., vN, R)</tt>, where the values and types of the bound arguments
+<tt>v1, v2, ..., vN</tt> are determined as specified below.
+<ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
+exception if and only if the corresponding constructor of <tt>FD</tt> or any of the types
+<tt>TiD</tt> throw an exception.</ins>
 </p>
-
-<blockquote>
 <p>
-<i>Effects:</i> <del>Merges</del> <ins>Copies all the elements of the</ins> two sorted ranges <tt>[first1,last1)</tt> and
-<tt>[first2,last2)</tt> into the range
-<del><tt>[result,result + (last1 - first1) + (last2 - first2))</tt></del>
-<ins><tt>[result, last)</tt> (where <tt>last</tt> is equal to <tt>result + (last1
-- first1) + (last2 - first2))</tt>, such that resulting range will be
-sorted in non-decreasing order; that is, for every iterator <tt>i</tt> in
-<tt>[result,last)</tt> other than <tt>result</tt>, the condition <tt>*i &lt; *(i - 1)</tt> or,
-respectively, <tt>comp(*i, *(i - 1))</tt> will be false</ins>.
+-6- <i>Throws:</i> Nothing unless the <del>copy</del>
+construct<ins>ion</ins><del>or</del> of
+<tt><del>F</del><ins>fd</ins></tt> or of one of the <ins>values
+<tt>tid</tt></ins> <del>types in the <tt>BoundArgs...</tt> pack
+expansion</del> throws an exception.
 </p>
-
 <p>
-<ins><i>Requires:</i></ins> The resulting range shall not overlap with either of the original ranges. <del>The list 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
-<tt>[first,last)</tt> other than <tt>first</tt>, the condition <tt>*i &lt; *(i - 1)</tt> or
-<tt>comp(*i, *(i - 1))</tt> will be false.</del>
+<ins>
+<i>Remarks:</i> The <i>unspecified</i> return type shall be
+<tt>MoveConstructible</tt>.  If all of <tt>FD</tt> and <tt>TiD</tt> are
+<tt>CopyConstructible</tt> then the <i>unspecified</i> return type shall
+be <tt>CopyConstructible</tt>. [<i>Note:</i> This implies that all of
+<tt>FD</tt> and <tt>TiD</tt> shall be <tt>MoveConstructible</tt> &#8212;
+<i>end note</i>]
+</ins>
 </p>
 </blockquote>
 
 <p>
-[N.B.: I attempted to reuse the wording style of <tt>inplace_merge</tt>,
-therefore proposing to
-insert ", respectively," between both predicate tests. This is no
-strictly necessary as
-other parts of <tt>&lt;algorithm&gt;</tt> show, just a matter of consistency]
+-7- The values of the <i>bound arguments</i> <tt>v1, v2, ..., vN</tt> and
+their corresponding types <tt>V1, V2, ..., VN</tt> depend on the type<ins>s
+<tt>TiD</tt> derived from</ins>
+<del>of the corresponding argument <tt>ti</tt> in <tt>bound_args</tt> of type
+<tt>Ti</tt> in <tt>BoundArgs</tt> in</del>
+the call to <tt>bind</tt> and the
+<i>cv</i>-qualifiers <i>cv</i> of the call wrapper <tt>g</tt> as
+follows:
 </p>
 
+<ul>
+<li>
+if <tt><del>ti</del> <ins>TiD</ins></tt> <del>is of</del> <ins>has</ins>
+type <tt>reference_wrapper&lt;T&gt;</tt> the argument is
+<tt>ti<ins>d</ins>.get()</tt> and its type <tt>Vi</tt> is
+<tt>T&amp;</tt>;
+</li>
+<li>
+if the value of
+<tt>std::is_bind_expression&lt;Ti<ins>D</ins>&gt;::value</tt> is
+<tt>true</tt> the argument is <tt>ti<ins>d</ins>(u1, u2, ..., uM)</tt>
+and its type <tt>Vi</tt> is <tt>result_of&lt;Ti<ins>D</ins> <i>cv</i>
+(U1&amp;, U2&amp;, ..., UM&amp;)&gt;::type</tt>;
+</li>
+<li>
+if the value <tt>j</tt> of
+<tt>std::is_placeholder&lt;Ti<ins>D</ins>&gt;::value</tt> is not zero
+the argument is <tt>std::forward&lt;Uj&gt;(uj)</tt> and its type
+<tt>Vi</tt> is <tt>Uj&amp;&amp;</tt>;
+</li>
+<li>
+otherwise the value is <tt>ti<ins>d</ins></tt> and its type <tt>Vi</tt>
+is <tt>Ti<ins>D</ins> <i>cv</i> &amp;</tt>.
+</li>
+</ul>
 
+</blockquote>
 
 
 
 
-<hr>
-<h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3>
-<p><b>Section:</b> 24.6.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-02-06  <b>Last modified:</b> 2009-07-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 287</b></p>
 
-<blockquote>
-<p>
-It is not clear what the initial state of an <tt>istream_iterator</tt> should be. Is
-_value_ initialized by reading the stream, or default/value initialized? If
-it is initialized by reading the stream, what happens if the initialization
-is deferred until first dereference, when ideally the iterator value should
-have been that of an end-of-stream iterator which is not safely
-dereferencable?
-</p>
 
+<hr>
+<h3><a name="819"></a>819. rethrow_if_nested</h3>
+<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-25  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Recommendation: Specify _value_ is initialized by reading the stream, or
-the iterator takes on the end-of-stream value if the stream is empty.
+Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I
+got it quite right.
 </p>
-</blockquote>
 
 <p>
-The description of how an istream_iterator object becomes an
-end-of-stream iterator is a) ambiguous and b) out of date WRT
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>:
+The current wording says:
 </p>
 
 <blockquote>
-<tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
-input stream for which it was constructed. After it is constructed, and
-every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
-the end of stream is reached (<tt>operator void*()</tt> on the stream returns
-<tt>false</tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
-The constructor with no arguments <tt>istream_iterator()</tt> always constructs
-an end of stream input iterator object, which is the only legitimate
-iterator to be used for the end condition. The result of <tt>operator*</tt> on an
-end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
-returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
-For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
-store things into istream iterators. The main peculiarity of the istream
-iterators is the fact that <tt>++</tt> operators are not equality preserving,
-that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
-is used a new value is read.
-</blockquote>
-
+<pre>template &lt;class E&gt; void rethrow_if_nested(const E&amp; e);
+</pre>
+<blockquote>
 <p>
-<tt>istream::operator void*()</tt> returns null if <tt>istream::fail()</tt> is <tt>true</tt>,
-otherwise non-null. <tt>istream::fail()</tt> returns <tt>true</tt> if <tt>failbit</tt> or
-<tt>badbit</tt> is set in <tt>rdstate()</tt>. Reaching the end of stream doesn't
-necessarily imply that <tt>failbit</tt> or <tt>badbit</tt> is set (e.g., after
-extracting an <tt>int</tt> from <tt>stringstream("123")</tt> the stream object will
-have reached the end of stream but <tt>fail()</tt> is <tt>false</tt> and <tt>operator
-void*()</tt> will return a non-null value).
+<i>Effects:</i> Calls <tt>e.rethrow_nested()</tt> only if <tt>e</tt>
+is publicly derived from <tt>nested_exception</tt>.
 </p>
+</blockquote>
+</blockquote>
 
 <p>
-Also I would prefer to be explicit about calling <tt>fail()</tt> here
-(there is no <tt>operator void*()</tt> anymore.)
+This is trying to be a bit subtle, by requiring <tt>e</tt> (not <tt>E</tt>) to be publicly
+derived from <tt>nested_exception</tt> the idea is that a <tt>dynamic_cast</tt> would be
+required to be sure.  Unfortunately, if <tt>e</tt> is dynamically but not statically
+derived from <tt>nested_exception</tt>, <tt>e.rethrow_nested()</tt> is ill-formed.
 </p>
 
 <p><i>[
-Summit:
+San Francisco:
 ]</i></p>
 
 
 <blockquote>
-Moved from Ready to Open for the purposes of using this issue to address NB UK 287.
-Martin to handle.
+Alisdair was volunteered to provide wording.
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-<p>
-This improves the wording.
-</p>
-<p>
-Move to Ready.
-</p>
+Leave as Open. Alisdair to provide wording.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
-<p>
-Change 24.6.1 [istream.iterator]/1:
-</p>
-
-<blockquote>
-<tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
-input stream for which it was constructed. After it is constructed, and
-every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
-<del>the end of stream is reached</del> <ins>the iterator fails to read and store a value of <tt>T</tt></ins>
-(<tt><del>operator void*()</del> <ins>fail()</ins></tt> on the stream returns
-<tt><del>false</del> <ins>true</ins></tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
-The constructor with no arguments <tt>istream_iterator()</tt> always constructs
-an end of stream input iterator object, which is the only legitimate
-iterator to be used for the end condition. The result of <tt>operator*</tt> on an
-end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
-returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
-For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
-store things into istream iterators. The main peculiarity of the istream
-iterators is the fact that <tt>++</tt> operators are not equality preserving,
-that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
-is used a new value is read.
-</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
-<p><b>Section:</b> 20.5 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-02-18  <b>Last modified:</b> 2009-07-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
+<h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3>
+<p><b>Section:</b> 20.8.14.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-05-14  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single">active issues</a> in [unique.ptr.single].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/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?
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (including recent updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>) proposes a useful
+extension point for <tt>unique_ptr</tt> by granting support for an optional
+<tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt>
+(In the following: <tt>pointer</tt>).
 </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:
+Unfortunately no requirements are specified for the type <tt>pointer</tt> which has
+impact on at least two key features of <tt>unique_ptr</tt>:
 </p>
 
-<blockquote><pre>tuple() = default;
-tuple(const tuple&amp;) = default;
-</pre></blockquote>
+<ol>
+<li>Operational fail-safety.</li>
+<li>(Well-)Definedness of expressions.</li>
+</ol>
 
 <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?
+<tt>Unique_ptr</tt> specification makes great efforts to require that essentially *all*
+operations cannot throw and therefore adds proper wording to the affected
+operations of the deleter as well. If user-provided <tt>pointer</tt>-emulating types
+("smart pointers") will be allowed, either *all* throw-nothing clauses have to
+be replaced by weaker "An exception is thrown only if <tt>pointer</tt>'s {op} throws
+an exception"-clauses or it has to be said explicitly that all used
+operations of
+<tt>pointer</tt> are required *not* to throw. I understand the main focus of <tt>unique_ptr</tt>
+to be as near as possible to the advantages of native pointers which cannot
+fail and thus strongly favor the second choice. Also, the alternative position
+would make it much harder to write safe and simple template code for
+<tt>unique_ptr</tt>. Additionally, I assume that a general statement need to be given
+that all of the expressions of <tt>pointer</tt> used to define semantics are required to
+be well-formed and well-defined (also as back-end for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>).
 </p>
 
 <p><i>[
-Bellevue:
+Sophia Antipolis:
 ]</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.
+Howard: We maybe need a core concept <tt>PointerLike</tt>, but we don't need the
+arithmetic (see <tt>shared_ptr</tt> vs. <tt>vector&lt;T&gt;::iterator</tt>.
 </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.
+Howard will go through and enumerate the individual requirements wrt. <tt>pointer</tt> for each member function.
 </p>
 </blockquote>
 
 <p><i>[
-2009-05-27 Daniel adds:
-]</i></p>
-
-
-<blockquote>
-This is partly solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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.
+Move to Ready.
 </blockquote>
 
 <p><i>[
-2009-07-20 Alisdair adds:
+2009-10-15 Alisdair pulls from Ready:
 ]</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.
+I hate to pull an issue out of Ready status, but I don't think 834 is
+fully baked yet.
 </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.
+For reference the proposed resolution is to add the following words:
 </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>
+<tt>unique_ptr&lt;T, D&gt;::pointer</tt>'s operations shall be
+well-formed, shall have well defined behavior, and shall not throw
+exceptions.
 </blockquote>
 
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3>
-<p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2008-03-14  <b>Last modified:</b> 2009-07-28</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<blockquote><pre>#include &lt;utility&gt;
-
-int main()
-{
-   std::pair&lt;char *, char *&gt; p (0,0);
-}
-</pre></blockquote>
-
 <p>
-I just got a bug report about that, because it's valid C++03, but not
-C++0x. The important realization, for me, is that the emplace
-proposal---which made <tt>push_back</tt> variadic, causing the <tt>push_back(0)</tt>
-issue---didn't cause this break in backward compatibility. The break
-actually happened when we added this pair constructor as part of adding
-rvalue references into the language, long before variadic templates or
-emplace came along:
+This leaves me with a big question : which operations?
 </p>
 
-<blockquote><pre>template&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; y);
-</pre></blockquote>
-
 <p>
-Now, concepts will address this issue by constraining that <tt>pair</tt>
-constructor to only <tt>U</tt>'s and <tt>V</tt>'s that can properly construct "first" and
-"second", e.g. (from
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf">N2322</a>):
+Are all pointer operations required to be nothrow, including operations
+that have nothing to do with interactions with <tt>unique_ptr</tt>?  This was
+much simpler with concepts where we could point to operations within a
+certain concept, and so nail down the interactions.
 </p>
-
-<blockquote><pre>template&lt;class U , class V &gt;
-requires Constructible&lt;T1, U&amp;&amp;&gt; &amp;&amp; Constructible&lt;T2, V&amp;&amp;&gt;
-pair(U&amp;&amp; x , V&amp;&amp; y );
-</pre></blockquote>
+</blockquote>
 
 <p><i>[
-San Francisco:
+2009-10-15 Daniel adds:
 ]</i></p>
 
 
 <blockquote>
-<p>
-Suggested to resolve using pass-by-value for that case.
-</p>
-<p>
-Side question: Should pair interoperate with tuples? Can construct a
-tuple of a pair, but not a pair from a two-element tuple.
-</p>
-<p>
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a>.
-</p>
+I volunteer to prepare a more fine-grained solution, but I would like
+to ask for feedback that helps me doing so. If this question is asked
+early in the meeting I might be able to fix it within the week, but I
+cannot promise that now.
 </blockquote>
 
 <p><i>[
-2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
+2009-10 Santa Cruz:
 ]</i></p>
 
 
+<blockquote>
+Leave in open. Daniel to provide wording as already suggested.
+</blockquote>
+
+
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
+Add the following sentence just at the end of the newly proposed
+20.8.14.2 [unique.ptr.single]/p. 3:
 </p>
 
-
-<p><b>Rationale:</b></p>
-<p><i>[
-San Francisco:
-]</i></p>
-
-
 <blockquote>
-Solved by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
+<tt>unique_ptr&lt;T, D&gt;::pointer</tt>'s operations shall be well-formed, shall have well
+defined behavior, and shall not throw exceptions.
 </blockquote>
 
 
 
 
 
-
-
 <hr>
-<h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3>
-<p><b>Section:</b> 20.7.16.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-16  <b>Last modified:</b> 2009-07-16</p>
+<h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3>
+<p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>
-<tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as
-described in the rvalue core proposal.
-</p>
+       <p>
 
-<p><i>[
-Sophia Antipolis:
-]</i></p>
+The fix for
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>,
+now integrated into the working paper, overlooks a couple of minor
+problems.
 
+       </p>
+       <p>
 
-<blockquote>
-According to Doug Gregor, as far as <tt>std::function</tt> is concerned, perfect
-forwarding can not be obtained because of type erasure. Not everyone
-agreed with this diagnosis of forwarding.
-</blockquote>
+First, being an unformatted function once again, <code>flush()</code>
+is required to create a sentry object whose constructor must, among
+other things, flush the tied stream. When two streams are tied
+together, either directly or through another intermediate stream
+object, flushing one will also cause a call to <code>flush()</code> on
+the other tied stream(s) and vice versa, ad infinitum. The program
+below demonstrates the problem.
 
-<p><i>[
-2009-05-01 Howard adds:
-]</i></p>
+       </p>
+       <p>
 
+Second, as Bo Persson notes in his
+comp.lang.c++.moderated <a href="http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/f2187794e9cc036d/305df31dc583054a">post</a>,
+for streams with the <code>unitbuf</code> flag set such
+as <code>std::stderr</code>, the destructor of the sentry object will
+again call <code>flush()</code>. This seems to create an infinite
+recursion for <code>std::cerr &lt;&lt; std::flush;</code>
 
-<blockquote>
-<p>
-Sebastian Gesemann brought to my attention that the <tt>CopyConstructible</tt>
-requirement on <tt>function</tt>'s <tt>ArgTypes...</tt> is an unnecessary
-restriction.
-</p>
+       </p>
+       <blockquote>
+           <pre>#include &lt;iostream&gt;
 
-<blockquote><pre>template&lt;Returnable R, <b>CopyConstructible</b>... ArgTypes&gt;
-class function&lt;R(ArgTypes...)&gt;
-...
-</pre></blockquote>
-
-<p>
-On further investigation, this complaint seemed to be the same
-issue as this one.  I believe the reason <tt>CopyConstructible</tt> was put
-on <tt>ArgTypes</tt> in the first place was because of the nature of the
-<i>invoke</i> member:
-</p>
-
-<blockquote><pre>template&lt;class R, class ...ArgTypes&gt;
-R
-function&lt;R(ArgTypes...)&gt;::operator()(ArgTypes... arg) const
-{
-    if (f_ == 0)
-        throw bad_function_call();
-    return (*f_)(arg...);
-}
-</pre></blockquote>
-
-<p>
-However now with rvalue-refs, "by value" no longer implies <tt>CopyConstructible</tt>
-(as Sebastian correctly points out).  If rvalue arguments are supplied, <tt>MoveConstructible</tt>
-is sufficient.  Furthermore, the constraint need not be applied in <tt>function</tt>
-if I understand correctly.  Rather the client must apply the proper constraints
-at the call site.  Therefore, at the very least, I recommend that <tt>CopyConstructible</tt>
-be removed from the template class <tt>function</tt>.
-</p>
-
-<p>
-Furthermore we need to mandate that the <i>invoker</i> is coded as:
-</p>
-
-<blockquote><pre>template&lt;class R, class ...ArgTypes&gt;
-R
-function&lt;R(ArgTypes...)&gt;::operator()(ArgTypes... arg) const
+int main ()
 {
-    if (f_ == 0)
-        throw bad_function_call();
-    return (*f_)(<b>std::forward&lt;ArgTypes&gt;(</b>arg<b>)</b>...);
-}
-</pre></blockquote>
-
-<p>
-Note that <tt>ArgTypes&amp;&amp;</tt> (the "perfect forwarding signature") is not 
-appropriate here as this is not a deduced context for <tt>ArgTypes</tt>.  Instead
-the client's arguments must implicitly convert to the non-deduced <tt>ArgType</tt>
-type.  Catching these arguments by value makes sense to enable decay.
-</p>
-
-<p>
-Next <tt>forward</tt> is used to move the <tt>ArgTypes</tt> as efficiently as
-possible, and also with minimum requirements (not <tt>CopyConstructible</tt>)
-to the type-erased functor.  For object types, this will be a <tt>move</tt>.  For
-reference type <tt>ArgTypes</tt>, this will be a copy.  The end result <em>must</em> be
-that the following is a valid program:
-</p>
-
-<blockquote><pre>#include &lt;functional&gt;
-#include &lt;memory&gt;
-#include &lt;cassert&gt;
+   std::cout.tie (&amp;std::cerr);
+   std::cerr.tie (&amp;std::cout);
+   std::cout &lt;&lt; "cout\n";
+   std::cerr &lt;&lt; "cerr\n";
+} 
+</pre>
+</blockquote>
 
-std::unique_ptr&lt;int&gt;
-f(std::unique_ptr&lt;int&gt; p, int&amp; i)
-{
-    ++i;
-    return std::move(p);
-}
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
-int main()
-{
-    int i = 2;
-    std::function&lt;std::unique_ptr&lt;int&gt;(std::unique_ptr&lt;int&gt;,
-                                       int&amp;&gt; g(f);
-    std::unique_ptr&lt;int&gt; p = g(std::unique_ptr&lt;int&gt;(new int(1)), i);
-    assert(*p == 1);
-    assert(i == 3);
-}
-</pre></blockquote>
+<blockquote>
+We agree with the proposed resolution.
+Move to Review.
+</blockquote>
 
 <p><i>[
-Tested in pre-concepts rvalue-ref-enabled compiler.
+2009-05-26 Daniel adds:
 ]</i></p>
 
 
+<blockquote>
 <p>
-In the example above, the first <tt>ArgType</tt> is <tt>unique_ptr&lt;int&gt;</tt>
-and the second <tt>ArgType</tt> is <tt>int&amp;</tt>.  Both <em>must</em> work!
+I think that the most recently suggested change in
+27.7.2.4 [ostream::sentry] need some further word-smithing. As
+written, it would make the behavior undefined, if under
+conditions when <tt>pubsync()</tt> should be called, but when
+in this scenario <tt>os.rdbuf()</tt> returns 0.
+</p>
+<p>
+This case is explicitly handled in <tt>flush()</tt> and needs to be
+taken care of. My suggested fix is:
 </p>
 
+<blockquote>
+If <tt>((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception()</tt>
+<ins><tt>&amp;&amp; os.rdbuf() != 0</tt></ins>) is true, calls <del><tt>os.flush()</tt></del>
+<ins><tt>os.rdbuf()-&gt;pubsync()</tt></ins>.
 </blockquote>
 
-<p><i>[
-2009-05-27 Daniel adds:
-]</i></p>
-
-
-<blockquote>
 <p>
-in the 2009-05-01 comment of above mentioned issue Howard
+Two secondary questions are:
 </p>
 
-<ol type="a">
+<ol>
 <li>
-Recommends to replace the <tt>CopyConstructible</tt> requirement by a
-<tt>MoveConstructible</tt> requirement
+Should <tt>pubsync()</tt> be invoked in any case or shouldn't a
+base requirement for this trial be that <tt>os.good() == true</tt>
+as required in the original <tt>flush()</tt> case?
 </li>
 <li>
-Says: "Furthermore, the constraint need not be applied in <tt>function</tt> if I
-understand correctly. Rather the client must apply the proper constraints
-at the call site"
+Since <tt>uncaught_exception()</tt> is explicitly tested, shouldn't
+a return value of -1 of <tt>pubsync()</tt> produce <tt>setstate(badbit)</tt>
+(which may throw <tt>ios_base::failure</tt>)?
 </li>
 </ol>
-<p>
-I'm fine with (a), but I think comment (b) is incorrect, at least in the
-sense I read these sentences. Let's look at Howard's example code:
-</p>
-
-<blockquote><pre>function&lt;R(ArgTypes...)&gt;::operator()(ArgTypes... arg) const
-{
-   if (f_ == 0)
-       throw bad_function_call();
-   return (*f_)(std::forward&lt;ArgTypes&gt;(arg)...);
-}
-</pre></blockquote>
-
-<p>
-In the constrained scope of this <tt>operator()</tt> overload the expression
-"<tt>(*f_)(std::forward&lt;ArgTypes&gt;(arg)...)</tt>" must be valid. How can it
-do so, if <tt>ArgTypes</tt> aren't at least <tt>MoveConstructible</tt>?
-</p>
 </blockquote>
 
 <p><i>[
@@ -9923,196 +8075,139 @@ do so, if <tt>ArgTypes</tt> aren't at least <tt>MoveConstructible</tt>?
 
 
 <blockquote>
-Leave this open and wait until concepts are removed from the Working
-Draft so that we know how to write the proposed resolution in terms of
-diffs to otherwise stable text.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="816"></a>816. Should <tt>bind()</tt>'s returned functor have a nofail copy ctor when <tt>bind()</tt> is nofail?</h3>
-<p><b>Section:</b> 20.7.12.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2008-02-08  <b>Last modified:</b> 2009-07-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> notes that <tt>bind(f, t1, ..., tN)</tt>
-should be nofail when <tt>f, t1, ..., tN</tt> have nofail copy ctors.
-</p>
 <p>
-However, no guarantees are provided for the copy ctor of the functor
-returned by <tt>bind()</tt>.  (It's guaranteed to have a copy ctor, which can
-throw implementation-defined exceptions: <tt>bind()</tt> returns a forwarding
-call wrapper, TR1 3.6.3/2.  A forwarding call wrapper is a call wrapper,
-TR1 3.3/4.  Every call wrapper shall be CopyConstructible, TR1 3.3/4.
-Everything without an exception-specification may throw
-implementation-defined exceptions unless otherwise specified, C++03
-17.4.4.8/3.)
+Daniel volunteered to modify the proposed resolution to address his two questions.
 </p>
 <p>
-Should the nofail guarantee requested by Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> be extended
-to cover both calling <tt>bind()</tt> and copying the returned functor?
+Move back to Open.
 </p>
-
-<p><i>[
-Howard adds:
-]</i></p>
-
-
-<blockquote>
-<tt>tuple</tt> construction should probably have a similar guarantee.
 </blockquote>
 
 <p><i>[
-San Francisco:
+2009-07-26 Daniel provided wording.  Moved to Review.
 ]</i></p>
 
 
-<blockquote>
-Howard to provide wording.
-</blockquote>
-
 <p><i>[
-Post Summit, Anthony provided wording.
+2009-10-13 Daniel adds:
 ]</i></p>
 
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
-
 <blockquote>
-Part of all of this issue appears to be rendered moot
-by the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a> (q.v.).
-We recommend the issues be considered simultaneously
-(or possibly even merged)
-to ensure there is no overlap.
-Move to Open, and likewise for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>.
+This proposed wording is written to match the outcome
+of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a>.
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+2009 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a> (see below). Leave Open.
+Move to Open. Martin to propose updated wording that will also resolve
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> consistently.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
+<p><i>[
+based on
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>
+numbering
+]</i></p>
+
+
+<ol>
+<li>
 <p>
-Add a new sentence to the end of paragraphs 2 and 4 of 20.7.12.1.3 [func.bind.bind]:
+Just before 27.5.4.2 [basic.ios.members]/2 insert a new paragraph:
 </p>
 
 <blockquote>
+<ins><i>Requires:</i> If <tt>(tiestr != 0)</tt> is <tt>true</tt>, <tt>tiestr</tt> must not be reachable
+by traversing the linked list of tied stream objects starting from
+<tt>tiestr-&gt;tie()</tt>.</ins>
+</blockquote>
+</li>
+
+<li>
 <p>
--2- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a weak result type (20.6.2). The effect of <tt>g(u1, u2,
-..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, Callable&lt;F cv,V1, V2, ..., VN&gt;::result_type)</tt>, where <i>cv</i>
-represents the <i>cv</i>-qualifiers of <tt>g</tt> and the values and types of the bound arguments
-<tt>v1, v2, ..., vN</tt> are determined as specified below.
-<ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
-exception if and only if the corresponding constructor of <tt>F</tt> or any of the types
-in <tt>BoundArgs...</tt> throw an exception.</ins>
-</p>
-<p>...</p>
-<p>
--4- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a nested type <tt>result_type</tt> defined as a synonym
-for <tt>R</tt>. The effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, R)</tt>, where the
-values and types of the bound arguments <tt>v1, v2, ..., vN</tt> are determined as specified below.
-<ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
-exception if and only if the corresponding constructor of <tt>F</tt> or any of the types
-in <tt>BoundArgs...</tt> throw an exception.</ins>
+Change 27.7.2.4 [ostream::sentry]/4 as indicated:
 </p>
 
+<blockquote>
+If <tt>((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception()<ins>&amp;&amp;
+os.good()</ins>)</tt> is <tt>true</tt>, calls <del><tt>os.flush()</tt></del>
+<ins><tt>os.rdbuf()-&gt;pubsync()</tt>. If that function returns -1 sets
+<tt>badbit</tt> in <tt>os.rdstate()</tt> without propagating an exception</ins>.
 </blockquote>
+</li>
+
+</ol>
 
 
+   
 
 
 
 <hr>
-<h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3>
-<p><b>Section:</b> 20.7.12.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-03-17  <b>Last modified:</b> 2009-07-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="836"></a>836. 
+       effects of <code>money_base::space</code> and
+       <code>money_base::none</code> on <code>money_get</code>
+   </h3>
+<p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17  <b>Last modified:</b> 2009-10-21</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a></p>
 <p><b>Discussion:</b></p>
-<p><b>Addresses US 72, JP 38 and DE 21</b></p>
 
-<p>
-The functor returned by <tt>bind()</tt> should have a move constructor that
-requires only move construction of its contained functor and bound arguments.
-That way move-only functors can be passed to objects such as <tt>thread</tt>.
-</p>
-<p>
-This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>.
-</p>
+       <p>
 
-<p>
-US 72:
-</p>
+In paragraph 2, 22.4.6.1.2 [locale.money.get.virtuals] specifies the following:
 
-<blockquote>
-<tt>bind</tt> should support move-only functors and bound arguments.
-</blockquote>
+       </p>
+       <blockquote>
 
-<p>
-JP 38:
-</p>
+Where <code>space</code> or <code>none</code> appears in the format
+pattern, except at the end, optional white space (as recognized
+by <code>ct.is</code>) is consumed after any required space.
 
-<blockquote>
-<p>
-add the move requirement for bind's return type.
-</p>
-<p>
-For example, assume following <tt>th1</tt> and <tt>th2</tt>,
-</p>
+       </blockquote>
+       <p>
 
-<blockquote><pre>void f(vector&lt;int&gt; v) { }
+This requirement can be (and has been) interpreted two mutually
+exclusive ways by different readers. One possible interpretation
+is that:
 
-vector&lt;int&gt; v{ ... };
-thread th1([v]{ f(v); });
-thread th2(bind(f, v));
-</pre></blockquote>
+       </p>
+       <blockquote>
+           <ol>
+               <li>
 
-<p>
-When function object are set to thread, <tt>v</tt> is moved to <tt>th1</tt>'s lambda
-expression in a Move Constructor of lambda expression because <tt>th1</tt>'s lambda
-expression has a Move Constructor. But <tt>bind</tt> of <tt>th2</tt>'s
-return type doesn't have the requirement of Move, so it may not
-moved but copied.
-</p>
-<p>
-Add the requirement of move to get rid of this useless copy.
-</p>
-<p>
-And also, add the <tt>MoveConstructible</tt> as well as <tt>CopyConstructible</tt>.
-</p>
-</blockquote>
+where <code>money_base::space</code> appears in the format, at least
+one space is required, and
 
-<p>
-DE 21
-</p>
+               </li>
+               <li>
 
-<blockquote>
-The specification for bind claims twice that "the values and types for
-the bound arguments v1, v2, ..., vN are determined as specified below".
-No such specification appears to exist.
-</blockquote>
+where <code>money_base::none</code> appears in the format, space is
+allowed but not required.
+
+               </li>
+           </ol>
+       </blockquote>
+       <p>
+
+The other is that:
+
+       </p>
+       <blockquote>
+
+where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional.
+
+       </blockquote>
 
 <p><i>[
 San Francisco:
@@ -10120,249 +8215,214 @@ San Francisco:
 
 
 <blockquote>
-Howard to provide wording.
+Martin will revise the proposed resolution.
 </blockquote>
 
 <p><i>[
-Post Summit Alisdair and Howard provided wording.
+2009-07 Frankfurt:
 ]</i></p>
 
 
 <blockquote>
 <p>
-Several issues are being combined in this resolution.  They are all touching the
-same words so this is an attempt to keep one issue from stepping on another, and
-a place to see the complete solution in one place.
+There is a noun missing from the proposed resolution. It's not clear
+that the last sentence would be helpful, even if the word were not
+missing:
 </p>
-
-<ol>
-<li>
-<tt>bind</tt> needs to be "moved".
-</li>
-<li>
-20.7.12.1.3 [func.bind.bind]/p3, p6 and p7 were accidently removed from N2798.
-</li>
-<li>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a> argues for a way to pass by &amp;&amp; for
-efficiency but retain the decaying behavior of pass by value for the
-<tt>thread</tt> constructor.  That same solution is applicable here.
-</li>
-</ol>
+<blockquote>
+In either case, any required MISSINGWORD followed by all optional whitespace (as recognized by ct.is()) is consumed.
 </blockquote>
+<p>
+Strike this sentence and move to Review.
+</p>
 
 <p><i>[
-Batavia (2009-05):
+Howard: done.
 ]</i></p>
 
-<blockquote>
-<p>
-We were going to recommend moving this issue to Tentatively Ready
-until we noticed potential overlap with issue 816 (q.v.).
-</p>
-<p>
-Move to Open,
-and recommend both issues be considered together
-(and possibly merged).
-</p>
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-The proposed resolution uses concepts. Leave Open.
+Move to Ready.
 </blockquote>
 
+   
 
+   <p><b>Proposed resolution:</b></p>
+       <p>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.7 [function.objects] p2:
-</p>
+I propose to change the text to make it clear that the first
+interpretation is intended, that is, to make following change to
+22.4.6.1.2 [locale.money.get.virtuals], p2:
 
-<blockquote><pre>template&lt;<del>CopyConstructible</del> <ins>MoveConstructible</ins> Fn, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... Types&gt;
-  <i>unspecified</i> bind(Fn<ins>&amp;&amp;</ins>, Types<ins>&amp;&amp;</ins>...);
-template&lt;Returnable R, <del>CopyConstructible</del> <ins>MoveConstructible</ins> Fn, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... Types&gt;
-  <i>unspecified</i> bind(Fn<ins>&amp;&amp;</ins>, Types<ins>&amp;&amp;</ins>...);
-</pre></blockquote>
+       </p>
+
+       <blockquote>
+
+When <code><ins>money_base::</ins>space</code>
+or <code><ins>money_base::</ins>none</code> appears <ins>as the last
+element </ins>in the format pattern, <del>except at the end, optional
+white space (as recognized by <code>ct.is</code>) is consumed after
+any required space.</del> <ins>no white space is consumed. Otherwise,
+where <code>money_base::space</code> appears in any of the initial
+elements of the format pattern, at least one white space character is
+required. Where <code>money_base::none</code> appears in any of the
+initial elements of the format pattern, white space is allowed but not
+required.</ins>
+If <code>(str.flags() &amp; str.showbase)</code> is <code>false</code>, ...
+
+       </blockquote>
+   
 
+
+
+<hr>
+<h3><a name="854"></a>854. <tt>default_delete</tt> converting constructor underspecified</h3>
+<p><b>Section:</b> 20.8.14.1.1 [unique.ptr.dltr.dflt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-18  <b>Last modified:</b> 2009-10-21</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+No relationship between <tt>U</tt> and <tt>T</tt> in the converting constructor for <tt>default_delete</tt> template.
+</p>
+<p>
+Requirements: <tt>U*</tt> is convertible to <tt>T*</tt> and <tt>has_virtual_destructor&lt;T&gt;</tt>;
+the latter should also become a concept.
+</p>
+<p>
+Rules out cross-casting.
+</p>
 <p>
-Change 20.7.12.1.3 [func.bind.bind]:
+The requirements for <tt>unique_ptr</tt> conversions should be the same as those on the deleter.
 </p>
 
-<blockquote><pre>template&lt;<del>CopyConstructible</del> <ins>MoveConstructible</ins> F, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... BoundArgs&gt;
-  <i>unspecified</i> bind(F<ins>&amp;&amp;</ins> f, BoundArgs<ins>&amp;&amp;</ins>... bound_args);
-</pre>
+<p><i>[
+Howard adds 2008-11-26:
+]</i></p>
+
 
 <blockquote>
 <p>
-<ins><i>Requires:</i> <i>unspecified</i> return type shall be <tt>MoveConstructible</tt>.</ins>
-</p>
-<p>
--1- <i>Requires:</i> <tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.6.2) shall be a valid expression for some values
-<i>w1, w2, ..., wN</i>, where <tt>N == sizeof...(bound_args)</tt>.
+I believe we need to be careful to not outlaw the following use case, and
+I believe the current proposed wording
+(<tt>requires Convertible&lt;U*, T*&gt; &amp;&amp; HasVirtualDestructor&lt;T&gt;</tt>) does so:
 </p>
+
+<blockquote><pre>#include &lt;memory&gt;
+
+int main()
+{
+    std::unique_ptr&lt;int&gt; p1(new int(1));
+    std::unique_ptr&lt;const int&gt; p2(move(p1));
+    int i = *p2;
+<font color="#c80000">//    *p2 = i;  // should not compile</font>
+}
+</pre></blockquote>
+
 <p>
--2- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a weak result type (20.6.2). The effect of <tt>g(u1, u2,
-..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, Callable&lt;F cv,V1, V2, ..., VN&gt;::result_type)</tt>, where <i>cv</i>
-represents the <i>cv</i>-qualifiers of <tt>g</tt> and the values and types of the bound arguments
-<tt>v1, v2, ..., vN</tt> are determined as specified below.
+I've removed "<tt>&amp;&amp; HasVirtualDestructor&lt;T&gt;</tt>" from the
+<tt>requires</tt> clause in the proposed wording.
 </p>
-<p><ins>
-<i>Throws:</i> Nothing unless the constructor of <tt>F</tt> or of one of the types in the <tt>BoundArgs...</tt> pack expansion
-throws an exception.
-</ins></p>
+
 </blockquote>
 
-<pre>template&lt;Returnable R, <del>CopyConstructible</del> <ins>MoveConstructible</ins> F, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... BoundArgs&gt;
-  <i>unspecified</i> bind(F<ins>&amp;&amp;</ins> f, BoundArgs<ins>&amp;&amp;</ins>... bound_args);
-</pre>
+<p><i>[
+Post Summit:
+]</i></p>
+
 
 <blockquote>
 <p>
-<ins><i>Requires:</i> <i>unspecified</i> return type shall be <tt>MoveConstructible</tt>.</ins>
+Alisdair: This issue has to stay in review pending a paper constraining
+<tt>unique_ptr</tt>.
 </p>
 <p>
--3- <i>Requires:</i> <tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> shall be a valid expression for some values <i>w1, w2, ...,
-wN</i>, where <tt>N == sizeof...(bound_args)</tt>.
+Consensus: We agree with the resolution, but <tt>unique_ptr</tt> needs
+to be constrained, too.
 </p>
 <p>
--4- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a nested type <tt>result_type</tt> defined as a synonym
-for <tt>R</tt>. The effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, R)</tt>, where the
-values and types of the bound arguments <tt>v1, v2, ..., vN</tt> are determined as specified below.
+Recommend Keep in Review.
 </p>
-<p>
-</p><p><ins>
-<i>Throws:</i> Nothing unless the constructor of <tt>F</tt> or of one of the types in the <tt>BoundArgs...</tt> pack expansion
-throws an exception.
-</ins></p>
-
 </blockquote>
 
-<p><ins>
-Let the values of <i>bound arguments</i> <tt>v1, v2, ..., vN</tt> and
-their corresponding types <tt>V1, V2, ..., VN</tt> depend on the type of
-the corresponding argument <tt>ti</tt> in <tt>bound_args</tt> in the
-call to <tt>bind</tt> and the <i>cv</i>-qualifiers <i>cv</i> of the call
-wrapper <tt>g</tt> as follows. Let <tt>Ti</tt> be an alias for the ith
-element of the pack expansion <tt>decay&lt;BoundArgs&gt;::type...</tt>,
-and let <tt>ti</tt> be an alias for the ith element in the function
-parameter pack expansion <tt>bound_args...</tt>:
-</ins></p>
-
-<ul>
-<li><ins>
-if <tt>ti</tt> is of type <tt>reference_wrapper&lt;T&gt;</tt> the argument is
-<tt>ti.get()</tt> and its type <tt>Vi</tt> is <tt>T&amp;</tt>;
-</ins></li>
-<li><ins>
-if the value of <tt>std::is_bind_expression&lt;Ti&gt;::value</tt> is <tt>true</tt> the argument is <tt>ti(u1, u2, ..., uM)</tt> and
-its type <tt>Vi</tt> is <tt>result_of&lt;Ti cv (U1&amp;, U2&amp;, ..., UM&amp;)&gt;::type</tt>;
-</ins></li>
-<li><ins>
-if the value <tt>j</tt> of <tt>std::is_placeholder&lt;Ti&gt;::value</tt> is not zero the argument is <tt>std::forward&lt;Uj&gt;(uj)</tt> and
-its type <tt>Vi</tt> is <tt>Uj&amp;&amp;</tt>;
-</ins></li>
-<li><ins>
-otherwise the value is <tt>ti</tt> and its type <tt>Vi</tt> is <tt>Ti cv &amp;</tt>.
-</ins></li>
-</ul>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
+<blockquote>
+Keep in Review status for the reasons cited.
 </blockquote>
 
+<p><i>[
+2009-07 Frankfurt:
+]</i></p>
 
 
-
-
-
-<hr>
-<h3><a name="819"></a>819. rethrow_if_nested</h3>
-<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-25  <b>Last modified:</b> 2008-09-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I
-got it quite right.
-</p>
-
+<blockquote>
 <p>
-The current wording says:
+The proposed resolution uses concepts. Howard needs to rewrite the
+proposed resolution.
 </p>
-
-<blockquote>
-<pre>template &lt;class E&gt; void rethrow_if_nested(const E&amp; e);
-</pre>
-<blockquote>
 <p>
-<i>Effects:</i> Calls <tt>e.rethrow_nested()</tt> only if <tt>e</tt>
-is publicly derived from <tt>nested_exception</tt>.
+Move back to Open.
 </p>
 </blockquote>
-</blockquote>
 
-<p>
-This is trying to be a bit subtle, by requiring <tt>e</tt> (not <tt>E</tt>) to be publicly
-derived from <tt>nested_exception</tt> the idea is that a <tt>dynamic_cast</tt> would be
-required to be sure.  Unfortunately, if <tt>e</tt> is dynamically but not statically
-derived from <tt>nested_exception</tt>, <tt>e.rethrow_nested()</tt> is ill-formed.
-</p>
+<p><i>[
+2009-07-26 Howard provided rewritten proposed wording and moved to Review.
+]</i></p>
+
 
 <p><i>[
-San Francisco:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Alisdair was volunteered to provide wording.
+Move to Ready.
 </blockquote>
 
 
+
 <p><b>Proposed resolution:</b></p>
+<p>
+Add after 20.8.14.1.1 [unique.ptr.dltr.dflt], p1:
+</p>
+
+<blockquote><pre>template &lt;class U&gt; default_delete(const default_delete&lt;U&gt;&amp; other);
+</pre>
+<blockquote>
+<p>
+-1- <i>Effects:</i> ...
+</p>
+<p><ins>
+<i>Remarks:</i> This constructor shall participate in overload resolution
+if and only if <tt>U*</tt> is implicitly convertible to <tt>T*</tt>.
+</ins></p>
+</blockquote>
+</blockquote>
+
 
 
 
 
 
 <hr>
-<h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3>
-<p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> James Kanze <b>Opened:</b> 2008-04-01  <b>Last modified:</b> 2009-07-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
+<h3><a name="860"></a>860. Floating-Point State</h3>
+<p><b>Section:</b> 26 [numerics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-06-23  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numerics">issues</a> in [numerics].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-I just noticed that the following program is legal in C++03, but
-is forbidden in the current draft:
-</p>
-
-<blockquote><pre>#include &lt;vector&gt;
-#include &lt;iostream&gt;
-
-class Toto
-{
-public:
-    Toto() {}
-    explicit Toto( Toto const&amp; ) {}
-} ;
-
-int
-main()
-{
-    std::vector&lt; Toto &gt; v( 10 ) ;
-    return 0 ;
-}
-</pre></blockquote>
-
-<p>
-Is this change intentional?  (And if so, what is the
-justification?  I wouldn't call such code good, but I don't see
-any reason to break it unless we get something else in return.)
+There are a number of functions that affect the floating point state.
+These function need to be thread-safe, but I'm unsure of the right
+approach in the standard, as we inherit them from C.
 </p>
 
 <p><i>[
@@ -10371,8 +8431,30 @@ San Francisco:
 
 
 <blockquote>
-The subgroup that looked at this felt this was a good change, but it may
-already be handled by incoming concepts (we're not sure).
+<p>
+Nick: I think we already say that these functions do not introduce data
+races; see 17.6.5.6/20
+</p>
+<p>
+Pete: there's more to it than not introducing data races; are these
+states maintained per thread?
+</p>
+<p>
+Howard: 21.5/14 says that strtok and strerror are not required to avoid
+data races, and 20.9/2 says the same about asctime, gmtime, ctime, and
+gmtime.
+</p>
+<p>
+Nick: POSIX has a list of not-safe functions. All other functions are
+implicitly thread safe.
+</p>
+<p>
+Lawrence is to form a group between meetings to attack this issue. Nick
+and Tom volunteered to work with Lawrence.
+</p>
+<p>
+Move to Open.
+</p>
 </blockquote>
 
 <p><i>[
@@ -10382,77 +8464,77 @@ Post Summit:
 
 <blockquote>
 <p>
-Alisdair: Proposed resolution kinda funky as these tables no longer
-exist. Move from direct init to copy init. Clarify with Doug, recommends
-NAD.
+Hans: Sane oses seem ok. Sensible thing is implementable and makes sense.
+</p>
+<p>
+Nick: Default wording seems to cover this? Hole in POSIX, these
+functions need to be added to list of thread-unsafe functions.
+</p>
+<p>
+Lawrence: Not sufficient, not "thread-safe" per our definition, but
+think of state as a thread-local variable. Need something like "these
+functions only affect state in the current thread."
+</p>
+<p>
+Hans: Suggest the following wording: "The floating point environment is
+maintained per-thread."
+</p>
+<p>
+Walter: Any other examples of state being thread safe that are not
+already covered elsewhere?
 </p>
 <p>
-Walter: Suggest NAD via introduction of concepts.
+Have thread unsafe functions paper which needs to be updated. Should
+just fold in 26.3 [cfenv] functions.
 </p>
 <p>
-Recommend close as NAD.
+Recommend Open. Lawrence instead suggests leaving it open until we have
+suitable wording that may or may not include the thread local
+commentary.
 </p>
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+2009-09-23 Hans provided wording.
 ]</i></p>
 
 
 <blockquote>
-Need to look at again without concepts.
+If I understand the history correctly, Nick, as the Posix liaison,
+should probably get a veto on this, since I think it came from Posix (?)
+via WG14 and should probably really be addressed there (?).  But I think
+we are basically in agreement that there is no other sane way to do
+this, and hence we don't have to worry too much about stepping on toes. 
+As far as I can tell, this same issue also exists in the latest Posix
+standard (?).
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-<p>
-Move to Ready with original proposed resolution.
-</p>
-<p><i>[Howard:  Original proposed resolution restored.]</i></p>
-
+Moved to Ready.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-In X [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]:
+Add at the end of 26.3.1 [cfenv.syn]:
 </p>
 
 <blockquote>
-<table border="1">
-<tbody><tr>
-<th>expression</th><th>post-condition</th>
-</tr>
-<tr>
-<td><tt>T t<ins>(rv)</ins><del> = rv</del></tt></td><td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
-</tr>
-<tr>
-<td colspan="2" align="center">...</td>
-</tr>
-</tbody></table>
-</blockquote>
-
 <p>
-In X [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]:
+2 The header defines all functions, types, and macros the same as C99 7.6.
 </p>
 
-<blockquote>
-<table border="1">
-<tbody><tr>
-<th>expression</th><th>post-condition</th>
-</tr>
-<tr>
-<td><tt>T t<ins>(u)</ins><del> = u</del></tt></td><td>the value of <tt>u</tt> is unchanged and is equivalent to <tt>t</tt></td>
-</tr>
-<tr>
-<td colspan="2" align="center">...</td>
-</tr>
-</tbody></table>
+<p><ins>
+A separate floating point environment shall be maintained for each
+thread.  Each function accesses the environment corresponding to its
+calling thread.
+</ins></p>
 </blockquote>
 
 
@@ -10460,141 +8542,53 @@ In X [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requ
 
 
 <hr>
-<h3><a name="823"></a>823. <tt>identity&lt;void&gt;</tt> seems broken</h3>
-<p><b>Section:</b> 20.3.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Walter Brown <b>Opened:</b> 2008-04-09  <b>Last modified:</b> 2009-07-30</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
+<h3><a name="861"></a>861. Incomplete specification of EqualityComparable for std::forward_list</h3>
+<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-06-24  <b>Last modified:</b> 2009-10-24</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-N2588 seems to have added an <tt>operator()</tt> member function to the
-<tt>identity&lt;&gt;</tt> helper in 20.3.2 [forward].  I believe this change makes it no
-longer possible to instantiate <tt>identity&lt;void&gt;</tt>, as it would require
-forming a reference-to-<tt>void</tt> type as this <tt>operator()</tt>'s parameter type.
-</p>
-
-<p>
-Suggested resolution:  Specialize <tt>identity&lt;void&gt;</tt> so as not to require
-the member function's presence.
+Table 89, Container requirements, defines <tt>operator==</tt> in terms of the container
+member function <tt>size()</tt> and the algorithm <tt>std::equal</tt>:
 </p>
 
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
 <blockquote>
+<tt>==</tt> is an equivalence relation. <tt>a.size() == b.size() &amp;&amp;
+equal(a.begin(), a.end(), b.begin()</tt>
+</blockquote>
+
 <p>
-Jens: suggests to add a requires clause to avoid specializing on <tt>void</tt>.
-</p>
-<p>
-Alisdair: also consider cv-qualified <tt>void</tt>.
+The new container <tt>forward_list</tt> does not provide a <tt>size</tt> member function
+by design but does provide <tt>operator==</tt> and <tt>operator!=</tt> without specifying it's semantic.
 </p>
 <p>
-Alberto provided proposed wording.
+Other parts of the (sequence) container requirements do also depend on
+<tt>size()</tt>, e.g. <tt>empty()</tt>
+or <tt>clear()</tt>, but this issue explicitly attempts to solve the missing
+<tt>EqualityComparable</tt> specification,
+because of the special design choices of <tt>forward_list</tt>.
 </p>
-</blockquote>
-
-<p><i>[
-2009-07-30 Daniel reopens:
-]</i></p>
-
-
-<blockquote>
 <p>
-This issue became closed, because the <tt>ReferentType</tt> requirement
-fixed the problem - this is no longer the case. In retrospective it seems
-to be that the root of current issues around <tt>std::identity</tt> (823, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>)
-is that it was standardized as something very different (an unconditional
-type mapper) than traditional usage indicated (a function object that should
-derive from <tt>std::unary_function)</tt>, as the SGI definition does. This issue could
-be solved, if <tt>std::identity</tt> is removed (one proposal of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>), but until this
-has been decided, this issue should remain open. An alternative for
-removing it, would be, to do the following:
+I propose to apply one of the following resolutions, which are described as:
 </p>
 
-<ol type="a">
+<ol type="A">
 <li>
-<p>
-Let <tt>identity</tt> stay as a <em>real</em> function object, which would
-now properly
-derive from <tt>unary_function</tt>:
-</p>
-
-<blockquote><pre>template &lt;class T&gt; struct identity : unary_function&lt;T, T&gt; {
-  const T&amp; operator()(const T&amp;) const;
-};
-</pre></blockquote>
+Provide a definition, which is optimal for this special container without
+previous size test. This choice prevents two <tt>O(N)</tt> calls of <tt>std::distance()</tt>
+with the corresponding container ranges and instead uses a special
+<tt>equals</tt> implementation which takes two container ranges instead of 1 1/2.
 </li>
-
 <li>
-<p>
-Invent (if needed) a generic type wrapper (corresponding to concept
-<tt>IdentityOf</tt>),
-e.g. <tt>identity_of</tt>, and move it's prototype description back to 20.3.2 [forward]:
-</p>
-
-<blockquote><pre>template &lt;class T&gt; struct identity_of {
-  typedef T type;
-};
-</pre></blockquote>
-
-<p>
-and adapt the <tt>std::forward</tt> signature to use <tt>identity_of</tt>
-instead of <tt>identity</tt>.
-</p>
+The simple fix where the usual test is adapted such that <tt>size()</tt> is replaced
+by <tt>distance</tt> with corresponding performance disadvantages.
 </li>
 </ol>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change definition of <tt>identity</tt> in 20.3.2 [forward], paragraph 2, to:
-</p>
-
-<blockquote><pre>template &lt;class T&gt;  struct identity {
-    typedef T type;
-
-    <ins>requires ReferentType&lt;T&gt;</ins>
-      const T&amp; operator()(const T&amp; x) const;
-  };
-</pre></blockquote>
-<p>...</p>
-<blockquote><pre>  <ins>requires ReferentType&lt;T&gt;</ins>
-    const T&amp; operator()(const T&amp; x) const;
-</pre></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>
-The point here is to able to write <tt>T&amp;</tt> given <tt>T</tt> and <tt>ReferentType</tt> is
-precisely the concept that guarantees so, according to N2677
-(Foundational concepts). Because of this, it seems preferable than an
-explicit check for <tt>cv void</tt> using <tt>SameType/remove_cv</tt> as it was suggested
-in Sophia. In particular, Daniel remarked that there may be types other
-than <tt>cv void</tt> which aren't referent types (<tt>int[]</tt>, perhaps?).
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3>
-<p><b>Section:</b> 20.8.10.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-11  <b>Last modified:</b> 2009-07-21</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-Would anyone object to making the default constructor of <tt>shared_ptr</tt> (and
-<tt>weak_ptr</tt> and <tt>enable_shared_from_this) constexpr</tt>? This would enable
-static initialization for <tt>shared_ptr</tt> variables, eliminating another
-unfair advantage of raw pointers.
+Both proposal choices are discussed, the preferred choice of the author is
+to apply (A).
 </p>
 
 <p><i>[
@@ -10604,834 +8598,689 @@ San Francisco:
 
 <blockquote>
 <p>
-It's not clear to us that you can initialize a pointer with the literal
-0 in a constant expression. We need to ask CWG to make sure this works.
-Bjarne has been appointed to do this.
+There's an Option C: change the requirements table to use distance().
+</p>
+<p>
+LWG found Option C acceptable.
 </p>
 <p>
-Core got back to us and assured as that <tt>nullptr</tt> would do the job
-nicely here.
+Martin will draft the wording for Option C.
 </p>
 </blockquote>
 
 <p><i>[
-2009-05-01 Alisdair adds:
+post San Francisco:
 ]</i></p>
 
 
 <blockquote>
-<p>
-I don't believe that constexpr will buy anything in this case.
-<tt>shared_ptr/weak_ptr/enable_shared_from_this</tt> cannot be literal types as they
-have a non-trivial copy constructor.  As they do not produce literal types,
-then the constexpr default constructor will <em>not</em> guarantee constant
-initialization, and so not buy the hoped for optimization.
-</p>
-<p>
-I recommend referring this back to Core to see if we can get static
-initialization for types with constexpr constructors, even if they are not
-literal types.  Otherwise this should be closed as NAD.
-</p>
+Martin provided wording for Option C.
 </blockquote>
 
 <p><i>[
-2009-05-26 Daniel adds:
-]</i></p>
-
-
-<blockquote>
-If Alisdair's 2009-05-01 comment is correct, wouldn't that also make
-<tt>constexpr mutex()</tt> useless, because this class has a non-trivial
-destructor? (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>)
-</blockquote>
-
-<p><i>[
-2009-07-21 Alisdair adds:
+2009-07 Frankfurt
 ]</i></p>
 
 
 <blockquote>
 <p>
-The feedback from core is that this and similar uses of constexpr
-constructors to force static initialization should be supported.  If
-there are any problems with this in the working draught, we should file
-core issues.
+Other operational semantics (see, for example, Tables 82 and 83) are
+written in terms of a container's size() member. Daniel to update
+proposed resolution C.
 </p>
+<p><i>[
+Howard: Commented out options A and B.
+]</i></p>
 
-<p>
-Recommend we declare the default constructor constexpr as the issue suggests
-(proposed wording added).
-</p>
 </blockquote>
 
+<p><i>[
+2009-07-26 Daniel updated proposed resolution C.
+]</i></p>
 
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.8.10.2 [util.smartptr.shared] and 20.8.10.2.1 [util.smartptr.shared.const]:
-</p>
-
-<blockquote><pre><ins>consexpr</ins> shared_ptr();
-</pre></blockquote>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
-<p>
-Change 20.8.10.3 [util.smartptr.weak] and 20.8.10.3.1 [util.smartptr.weak.const]:
-</p>
 
-<blockquote><pre><ins>consexpr</ins> weak_ptr();
-</pre></blockquote>
+<blockquote>
+Mark NAD Editorial. Addressed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2986.pdf">N2986</a>.
+</blockquote>
 
-<p>
-Change 20.8.10.5 [util.smartptr.enab] (2 places):
-</p>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
-<blockquote><pre><ins>consexpr</ins> enable_shared_from_this();
-</pre></blockquote>
 
+<blockquote>
+Reopened.
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2986.pdf">N2986</a>
+was rejected in full committee on procedural grounds.
+</blockquote>
 
 
 
+<p><b>Proposed resolution:</b></p>
 
 
-<hr>
-<h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3>
-<p><b>Section:</b> 30.4.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-18  <b>Last modified:</b> 2009-05-30</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.class">active issues</a> in [thread.mutex.class].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.class">issues</a> in [thread.mutex.class].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-[Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
-</p>
 <p>
-Currently <tt>std::mutex</tt> doesn't support static initialization. This is a
-regression with respect to <tt>pthread_mutex_t</tt>, which does. I believe that
-we should strive to eliminate such regressions in expressive power where
-possible, both to ease migration and to not provide incentives to (or
-force) people to forego the C++ primitives in favor of pthreads.
+Option (C):
 </p>
+<blockquote>
 
 <p><i>[
-Sophia Antipolis:
+The changes are relative to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>
+but concept-free.
 ]</i></p>
 
 
-<blockquote>
+<ol>
+<li>
 <p>
-We believe this is implementable on POSIX, because the initializer-list
-feature and the constexpr feature make this work. Double-check core
-language about static initialization for this case. Ask core for a core
-issue about order of destruction of statically-initialized objects wrt.
-dynamically-initialized objects (should come afterwards). Check
-non-POSIX systems for implementability.
+In 23.2.1 [container.requirements.general] change Table 80 -- Container requirements as indicated:
 </p>
+
+<ol type="a">
+<li>
 <p>
-If ubiquitous implementability cannot be assured, plan B is to introduce
-another constructor, make this constexpr, which is
-conditionally-supported. To avoid ambiguities, this new constructor needs
-to have an additional parameter.
+Change the text in the Assertion/note column in the row for "<tt>X u</tt>;"
+as follows:
 </p>
-</blockquote>
-
-<p><i>[
-Post Summit:
-]</i></p>
-
 
 <blockquote>
+post: <tt>u.<del>size() == 0</del><ins>empty() == true</ins></tt>
+</blockquote>
+</li>
+
+<li>
 <p>
-Jens: constant initialization seems to be ok core-language wise
-</p>
-<p>
-Consensus: Defer to threading experts, in particular a Microsoft platform expert.
-</p>
-<p>
-Lawrence to send e-mail to Herb Sutter, Jonathan Caves, Anthony Wiliams,
-Paul McKenney, Martin Tasker, Hans Boehm, Bill Plauger, Pete Becker,
-Peter Dimov to alert them of this issue.
-</p>
-<p>
-Lawrence: What about header file shared with C? The initialization
-syntax is different in C and C++.
+Change the text in the Assertion/note column in the row for "<tt>X();</tt>"
+as follows:
 </p>
+
+<blockquote>
+<tt>X().<del>size() == 0</del><ins>empty() == true</ins></tt>
+</blockquote>
+</li>
+
+<li>
 <p>
-Recommend Keep in Review
+Change the text in the Operational Semantics column in the row for
+"<tt>a == b</tt>" as follows:
 </p>
+<blockquote>
+<tt>==</tt> is an equivalence relation.
+<tt><del>a.size()</del><ins>distance(a.begin(), a.end())</ins> ==
+   <del>b.size()</del><ins>distance(b.begin(), b.end())</ins> &amp;&amp;
+equal(a.begin(), a.end(), b.begin())</tt>
 </blockquote>
+</li>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<li>
+<p>
+Change the text in the Operational Semantics column in the row for
+"<tt>a.size()</tt>" as follows:
+</p>
 
 <blockquote>
-Keep in Review status pending feedback from members of the Concurrency subgroup.
+<tt><del>a.end() - a.begin()</del><ins>distance(a.begin(), a.end())</ins></tt>
 </blockquote>
+</li>
 
-<p><i>[
-See related comments from Alisdiar and Daniel in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>.
-]</i></p>
+<li>
+<p>
+Change the text in the Operational Semantics column in the row for
+"<tt>a.max_size()</tt>" as follows:
+</p>
 
+<blockquote>
+<tt><del>size()</del><ins>distance(begin(), end())</ins></tt> of the largest
+possible container
+</blockquote>
+</li>
 
+<li>
+<p>
+Change the text in the Operational Semantics column in the row for
+"<tt>a.empty()</tt>" as follows:
+</p>
 
+<blockquote>
+<tt><del>a.size() == 0</del><ins>a.begin() == a.end()</ins></tt>
+</blockquote>
+</li>
+</ol>
+</li>
 
-<p><b>Proposed resolution:</b></p>
+<li>
 <p>
-Change 30.4.1.1 [thread.mutex.class]:
+In 23.2.1 [container.requirements.general] change Table 82 -- Allocator-aware container requirements as indicated:
 </p>
 
-<blockquote><pre>class mutex {
-public:
-  <ins>constexpr</ins> mutex();
-  ...
-</pre></blockquote>
-
+<ol type="a">
+<li>
+<p>
+Change the text in the Assertion/note column in the row for "<tt>X() /
+X u;</tt>" as follows:
+</p>
 
+<blockquote>
+<i>Requires:</i> <tt>A</tt> is <tt>DefaultConstructible</tt> post: <tt><del>u.size() ==
+0</del><ins>u.empty() == true</ins></tt>, <tt>get_allocator() == A()</tt>
+</blockquote>
+</li>
 
+<li>
+<p>
+Change the text in the Assertion/note column in the row for "<tt>X(m) /
+X u(m);</tt>" as follows:
+</p>
 
+<blockquote>
+post: <tt><del>u.size() == 0</del><ins>u.empty() == true</ins>,
+get_allocator() == m</tt>
+</blockquote>
+</li>
+</ol>
+</li>
 
-<hr>
-<h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3>
-<p><b>Section:</b> 20.8.9.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-05-14  <b>Last modified:</b> 2009-07-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single">active issues</a> in [unique.ptr.single].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
+<li>
 <p>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (including recent updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>) proposes a useful
-extension point for <tt>unique_ptr</tt> by granting support for an optional
-<tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt>
-(In the following: <tt>pointer</tt>).
+In 23.2.3 [sequence.reqmts] change Table 83 -- Sequence container requirements as indicated:
 </p>
+
+<ol type="a">
+<li>
 <p>
-Unfortunately no requirements are specified for the type <tt>pointer</tt> which has
-impact on at least two key features of <tt>unique_ptr</tt>:
+Change the text in the Assertion/note column in the row for "<tt>X(n,
+t) / X a(n, t)</tt>" as follows:
 </p>
 
-<ol>
-<li>Operational fail-safety.</li>
-<li>(Well-)Definedness of expressions.</li>
-</ol>
+<blockquote>
+post: <tt><del>size()</del><ins>distance(begin(), end())</ins> == n [..]</tt>
+</blockquote>
+</li>
 
+<li>
 <p>
-<tt>Unique_ptr</tt> specification makes great efforts to require that essentially *all*
-operations cannot throw and therefore adds proper wording to the affected
-operations of the deleter as well. If user-provided <tt>pointer</tt>-emulating types
-("smart pointers") will be allowed, either *all* throw-nothing clauses have to
-be replaced by weaker "An exception is thrown only if <tt>pointer</tt>'s {op} throws
-an exception"-clauses or it has to be said explicitly that all used
-operations of
-<tt>pointer</tt> are required *not* to throw. I understand the main focus of <tt>unique_ptr</tt>
-to be as near as possible to the advantages of native pointers which cannot
-fail and thus strongly favor the second choice. Also, the alternative position
-would make it much harder to write safe and simple template code for
-<tt>unique_ptr</tt>. Additionally, I assume that a general statement need to be given
-that all of the expressions of <tt>pointer</tt> used to define semantics are required to
-be well-formed and well-defined (also as back-end for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>).
+Change the text in the Assertion/note column in the row for "<tt>X(i,
+j) / X a(i, j)</tt>" as follows:
 </p>
 
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
 <blockquote>
+[..] post: <del><tt>size() ==</tt> distance between <tt>i</tt> and
+<tt>j</tt></del><ins><tt>distance(begin(), end()) == distance(i, j)</tt></ins> [..]
+</blockquote>
+</li>
+
+<li>
 <p>
-Howard: We maybe need a core concept <tt>PointerLike</tt>, but we don't need the
-arithmetic (see <tt>shared_ptr</tt> vs. <tt>vector&lt;T&gt;::iterator</tt>.
+Change the text in the Assertion/note column in the row for
+"<tt>a.clear()</tt>" as follows:
 </p>
+<blockquote>
+<tt><ins>a.</ins>erase(<ins>a.</ins>begin(), <ins>a.</ins>end())</tt> post:
+<tt><del>size() == 0</del><ins>a.empty() == true</ins></tt>
+</blockquote>
+</li>
+</ol>
+</li>
+
+<li>
 <p>
-Howard will go through and enumerate the individual requirements wrt. <tt>pointer</tt> for each member function.
+In 23.2.4 [associative.reqmts] change Table 85 -- Associative container requirements as indicated:
 </p>
-</blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+Not every occurrence of <tt>size()</tt> was replaced, because all current
+associative containers
+have a <tt>size</tt>. The following changes ensure consistency regarding the
+semantics of "<tt>erase</tt>"
+for all tables and adds some missing objects
 ]</i></p>
 
 
+<ol type="a">
+<li>
+<p>
+Change the text in the Complexity column in the row for
+"<tt>a.insert(i, j)</tt>" as follows:
+</p>
 <blockquote>
-Move to Ready.
+<tt>N log(<ins>a.</ins>size() + N)</tt> <del>(<tt>N</tt> is the distance from <tt>i</tt> to
+<tt>j</tt>)</del><ins> where <tt>N == distance(i, j)</tt></ins>
 </blockquote>
+</li>
 
-
-
-<p><b>Proposed resolution:</b></p>
+<li>
 <p>
-Add the following sentence just at the end of the newly proposed
-20.8.9.2 [unique.ptr.single]/p. 3:
+Change the text in the Complexity column in the row for
+"<tt>a.erase(k)</tt>" as follows:
 </p>
-
 <blockquote>
-<tt>unique_ptr&lt;T, D&gt;::pointer</tt>'s operations shall be well-formed, shall have well
-defined behavior, and shall not throw exceptions.
+<tt>log(<ins>a.</ins>size()) + <ins>a.</ins>count(k)</tt>
 </blockquote>
+</li>
 
+<li>
+<p>
+Change the text in the Complexity column in the row for
+"<tt>a.erase(q1, q2)</tt>" as follows:
+</p>
 
+<blockquote>
+<tt>log(<ins>a.</ins>size()) + N</tt> where <tt>N</tt> <del>is the distance from <tt>q1</tt>
+to <tt>q2</tt></del>
+   <ins><tt>== distance(q1, q2)</tt></ins>.
+</blockquote>
+</li>
 
+<li>
+<p>
+Change the text in the Assertion/note column in the row for
+"<tt>a.clear()</tt>" as follows:
+</p>
 
+<blockquote>
+<tt><ins>a.</ins>erase(a.begin(),a.end())</tt> post: <tt><del>size() ==
+0</del><ins>a.empty() == true</ins></tt>
+</blockquote>
+</li>
 
-<hr>
-<h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3>
-<p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17  <b>Last modified:</b> 2009-07-27</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-       <p>
-
-The fix for
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>,
-now integrated into the working paper, overlooks a couple of minor
-problems.
-
-       </p>
-       <p>
-
-First, being an unformatted function once again, <code>flush()</code>
-is required to create a sentry object whose constructor must, among
-other things, flush the tied stream. When two streams are tied
-together, either directly or through another intermediate stream
-object, flushing one will also cause a call to <code>flush()</code> on
-the other tied stream(s) and vice versa, ad infinitum. The program
-below demonstrates the problem.
-
-       </p>
-       <p>
-
-Second, as Bo Persson notes in his
-comp.lang.c++.moderated <a href="http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/f2187794e9cc036d/305df31dc583054a">post</a>,
-for streams with the <code>unitbuf</code> flag set such
-as <code>std::stderr</code>, the destructor of the sentry object will
-again call <code>flush()</code>. This seems to create an infinite
-recursion for <code>std::cerr &lt;&lt; std::flush;</code>
-
-       </p>
-       <blockquote>
-           <pre>#include &lt;iostream&gt;
+<li>
+<p>
+Change the text in the Complexity column in the row for "<tt>a.clear()</tt>"
+as follows:
+</p>
 
-int main ()
-{
-   std::cout.tie (&amp;std::cerr);
-   std::cerr.tie (&amp;std::cout);
-   std::cout &lt;&lt; "cout\n";
-   std::cerr &lt;&lt; "cerr\n";
-} 
-</pre>
+<blockquote>
+linear in <tt><ins>a.</ins>size()</tt>
 </blockquote>
+</li>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<li>
+<p>
+Change the text in the Complexity column in the row for
+"<tt>a.count(k)</tt>" as follows:
+</p>
 
 <blockquote>
-We agree with the proposed resolution.
-Move to Review.
+<tt>log(<ins>a.</ins>size()) + <ins>a.</ins>count(k)</tt>
 </blockquote>
+</li>
+</ol>
+</li>
 
+<li>
+<p>
+In 23.2.5 [unord.req] change Table 87 -- Unordered associative container requirements as indicated:
+</p>
 <p><i>[
-2009-05-26 Daniel adds:
+The same rational as for Table 85 applies here
 ]</i></p>
 
 
-<blockquote>
-<p>
-I think that the most recently suggested change in
-27.7.2.4 [ostream::sentry] need some further word-smithing. As
-written, it would make the behavior undefined, if under
-conditions when <tt>pubsync()</tt> should be called, but when
-in this scenario <tt>os.rdbuf()</tt> returns 0.
-</p>
+<ol type="a">
+<li>
 <p>
-This case is explicitly handled in <tt>flush()</tt> and needs to be
-taken care of. My suggested fix is:
+Change the text in the Assertion/note column in the row for
+"<tt>a.clear()</tt>" as follows:
 </p>
 
 <blockquote>
-If <tt>((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception()</tt>
-<ins><tt>&amp;&amp; os.rdbuf() != 0</tt></ins>) is true, calls <del><tt>os.flush()</tt></del>
-<ins><tt>os.rdbuf()-&gt;pubsync()</tt></ins>.
+[..] Post: <tt>a.<del>size() == 0</del><ins>empty() == true</ins></tt>
+</blockquote>
+</li>
+</ol>
+</li>
+</ol>
+
+
 </blockquote>
 
+
+
+
+
+<hr>
+<h3><a name="865"></a>865. More algorithms that throw away information</h3>
+<p><b>Section:</b> 25.3.6 [alg.fill], 25.3.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-07-13  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Two secondary questions are:
+In regard to library defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a> I found some more algorithms which
+unnecessarily throw away information. These are typically algorithms,
+which sequentially write into an <tt>OutputIterator</tt>, but do not return the
+final value of this output iterator. These cases are:
 </p>
 
 <ol>
 <li>
-Should <tt>pubsync()</tt> be invoked in any case or shouldn't a
-base requirement for this trial be that <tt>os.good() == true</tt>
-as required in the original <tt>flush()</tt> case?
-</li>
+<pre>template&lt;class OutputIterator, class Size, class T&gt;
+void fill_n(OutputIterator first, Size n, const T&amp; value);</pre></li>
+
 <li>
-Since <tt>uncaught_exception()</tt> is explicitly tested, shouldn't
-a return value of -1 of <tt>pubsync()</tt> produce <tt>setstate(badbit)</tt>
-(which may throw <tt>ios_base::failure</tt>)?
-</li>
+<pre>template&lt;class OutputIterator, class Size, class Generator&gt;
+void generate_n(OutputIterator first, Size n, Generator gen);</pre></li>
 </ol>
-</blockquote>
+<p>
+In both cases the minimum requirements on the iterator are
+<tt>OutputIterator</tt>, which means according to the requirements of
+24.2.2 [output.iterators]/2 that only single-pass iterations are guaranteed.
+So, if users of <tt>fill_n</tt> and <tt>generate_n</tt> have *only* an <tt>OutputIterator</tt>
+available, they have no chance to continue pushing further values
+into it, which seems to be a severe limitation to me.
+</p>
 
 <p><i>[
-2009-07 Frankfurt:
+Post Summit Daniel "conceptualized" the wording.
 ]</i></p>
 
 
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
 <blockquote>
 <p>
-Daniel volunteered to modify the proposed resolution to address his two questions.
+Alisdair likes the idea, but has concerns about the specific wording
+about the returns clauses.
 </p>
 <p>
-Move back to Open.
+Alan notes this is a feature request.
+</p>
+<p>
+Bill notes we have made similar changes to other algorithms.
+</p>
+<p>
+Move to Open.
 </p>
 </blockquote>
 
 <p><i>[
-2009-07-26 Daniel provided wording.  Moved to Review.
+2009-07 Frankfurt
 ]</i></p>
 
 
+<blockquote>
+We have a consensus for moving forward on this issue, but Daniel needs
+to deconceptify it.
+</blockquote>
+
+<p><i>[
+2009-07-25 Daniel provided non-concepts wording.
+]</i></p>
 
 
-<p><b>Proposed resolution:</b></p>
 <p><i>[
-based on
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>
-numbering
+2009-10 Santa Cruz:
 ]</i></p>
 
 
+<blockquote>
+Moved to Ready.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
 <ol>
 <li>
 <p>
-Just before 27.5.4.2 [basic.ios.members]/2 insert a new paragraph:
+Replace the current declaration of <tt>fill_n</tt> in 25 [algorithms]/2, header
+<tt>&lt;algorithm&gt;</tt> synopsis and in 25.3.6 [alg.fill] by
+</p>
+
+<blockquote><pre>template&lt;class OutputIterator, class Size, class T&gt;
+  <del>void</del><ins>OutputIterator</ins> fill_n(OutputIterator first, Size n, const T&amp; value);
+</pre></blockquote>
+
+<p>
+Just after the effects clause add a new returns clause saying:
 </p>
 
 <blockquote>
-<ins><i>Requires:</i> If <tt>(tiestr != 0)</tt> is <tt>true</tt>, <tt>tiestr</tt> must not be reachable
-by traversing the linked list of tied stream objects starting from
-<tt>tiestr-&gt;tie()</tt>.</ins>
+<ins><i>Returns:</i> For <tt>fill_n</tt> and positive <tt>n</tt>, returns <tt>first + n</tt>. Otherwise
+returns <tt>first</tt> for <tt>fill_n</tt>.</ins>
 </blockquote>
 </li>
 
 <li>
 <p>
-Change 27.7.2.4 [ostream::sentry]/4 as indicated:
+Replace the current declaration of <tt>generate_n</tt> in 25 [algorithms]/2,
+header <tt>&lt;algorithm&gt;</tt> synopsis and in 25.3.7 [alg.generate] by
+</p>
+
+<blockquote><pre>template&lt;class OutputIterator, class Size, class Generator&gt;
+  <del>void</del><ins>OutputIterator</ins> generate_n(OutputIterator first, Size n, Generator gen);
+</pre></blockquote>
+
+<p>
+Just after the effects clause add a new returns clause saying:
 </p>
 
 <blockquote>
-If <tt>((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception()<ins>&amp;&amp;
-os.good()</ins>)</tt> is <tt>true</tt>, calls <del><tt>os.flush()</tt></del>
-<ins><tt>os.rdbuf()-&gt;pubsync()</tt>. If that function returns -1 sets
-<tt>badbit</tt> in <tt>os.rdstate()</tt> without propagating an exception</ins>.
+<ins>For <tt>generate_n</tt> and positive <tt>n</tt>, returns <tt>first + n</tt>. Otherwise
+returns <tt>first</tt> for <tt>generate_n</tt>.</ins>
 </blockquote>
 </li>
-
 </ol>
 
 
-   
+
+
 
 
 
 <hr>
-<h3><a name="836"></a>836. 
-       effects of <code>money_base::space</code> and
-       <code>money_base::none</code> on <code>money_get</code>
-   </h3>
-<p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17  <b>Last modified:</b> 2009-07-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a></p>
+<h3><a name="868"></a>868. default construction and value-initialization</h3>
+<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-22  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/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="http://www.open-std.org/jtc1/sc22/wg21/docs/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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>. This issue is
+related with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>.
+</p>
 
-       <p>
+<p><i>[
+San Francisco:
+]</i></p>
 
-In paragraph 2, 22.4.6.1.2 [locale.money.get.virtuals] specifies the following:
 
-       </p>
-       <blockquote>
-
-Where <code>space</code> or <code>none</code> appears in the format
-pattern, except at the end, optional white space (as recognized
-by <code>ct.is</code>) is consumed after any required space.
-
-       </blockquote>
-       <p>
-
-This requirement can be (and has been) interpreted two mutually
-exclusive ways by different readers. One possible interpretation
-is that:
-
-       </p>
-       <blockquote>
-           <ol>
-               <li>
-
-where <code>money_base::space</code> appears in the format, at least
-one space is required, and
-
-               </li>
-               <li>
-
-where <code>money_base::none</code> appears in the format, space is
-allowed but not required.
-
-               </li>
-           </ol>
-       </blockquote>
-       <p>
-
-The other is that:
-
-       </p>
-       <blockquote>
-
-where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional.
-
-       </blockquote>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#886">886</a> tuple construction
+</p>
+</blockquote>
 
 <p><i>[
-San Francisco:
+2009-07 Frankfurt
 ]</i></p>
 
 
 <blockquote>
-Martin will revise the proposed resolution.
+<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 Frankfurt:
+2009-07-18 Ganesh updated the proposed wording.
 ]</i></p>
 
 
 <blockquote>
 <p>
-There is a noun missing from the proposed resolution. It's not clear
-that the last sentence would be helpful, even if the word were not
-missing:
+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>
-<blockquote>
-In either case, any required MISSINGWORD followed by all optional whitespace (as recognized by ct.is()) is consumed.
-</blockquote>
 <p>
-Strike this sentence and move to Review.
+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><b>Proposed resolution:</b></p>
-       <p>
-
-I propose to change the text to make it clear that the first
-interpretation is intended, that is, to make following change to
-22.4.6.1.2 [locale.money.get.virtuals], p2:
-
-       </p>
-
-       <blockquote>
-
-When <code><ins>money_base::</ins>space</code>
-or <code><ins>money_base::</ins>none</code> appears <ins>as the last
-element </ins>in the format pattern, <del>except at the end, optional
-white space (as recognized by <code>ct.is</code>) is consumed after
-any required space.</del> <ins>no white space is consumed. Otherwise,
-where <code>money_base::space</code> appears in any of the initial
-elements of the format pattern, at least one white space character is
-required. Where <code>money_base::none</code> appears in any of the
-initial elements of the format pattern, white space is allowed but not
-required.</ins>
-If <code>(str.flags() &amp; str.showbase)</code> is <code>false</code>, ...
-
-       </blockquote>
-   
-
-
-
-<hr>
-<h3><a name="838"></a>838. 
-   can an <i>end-of-stream</i> iterator become a <i>non-end-of-stream</i> one?
- </h3>
-<p><b>Section:</b> 24.6.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17  <b>Last modified:</b> 2009-07-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-   <p>
-
-From message c++std-lib-20003...
-
-   </p>
-   <p>
-
-The description of <code>istream_iterator</code> in
-24.6.1 [istream.iterator], p1 specifies that objects of the
-class become the <i>end-of-stream</i> (EOS) iterators under the
-following condition (see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a> another problem
-with this paragraph):
-
-   </p>
-   <blockquote>
-
-If the end of stream is reached (<code>operator void*()</code> on the
-stream returns <code>false</code>), the iterator becomes equal to
-the <i>end-of-stream</i> iterator value.
-
-   </blockquote>
-   <p>
-
-One possible implementation approach that has been used in practice is
-for the iterator to set its <code>in_stream</code> pointer to 0 when
-it reaches the end of the stream, just like the default ctor does on
-initialization. The problem with this approach is that
-the <i>Effects</i> clause for <code>operator++()</code> says the
-iterator unconditionally extracts the next value from the stream by
-evaluating <code>*in_stream &gt;&gt; value</code>, without checking
-for <code>(in_stream == 0)</code>.
-
-   </p>
-   <p>
-
-Conformance to the requirement outlined in the <i>Effects</i> clause
-can easily be verified in programs by setting <code>eofbit</code>
-or <code>failbit</code> in <code>exceptions()</code> of the associated
-stream and attempting to iterate past the end of the stream: each
-past-the-end access should trigger an exception. This suggests that
-some other, more elaborate technique might be intended.
-
-   </p>
-   <p>
-
-Another approach, one that allows <code>operator++()</code> to attempt
-to extract the value even for EOS iterators (just as long
-as <code>in_stream</code> is non-0) is for the iterator to maintain a
-flag indicating whether it has reached the end of the stream. This
-technique would satisfy the presumed requirement implied by
-the <i>Effects</i> clause mentioned above, but it isn't supported by
-the exposition-only members of the class (no such flag is shown). This
-approach is also found in existing practice.
-
-   </p>
-   <p>
-
-The inconsistency between existing implementations raises the question
-of whether the intent of the specification is that a non-EOS iterator
-that has reached the EOS become a non-EOS one again after the
-stream's <code>eofbit</code> flag has been cleared? That is, are the
-assertions in the program below expected to pass?
-
-   </p>
-   <blockquote>
-     <pre>   sstream strm ("1 ");
-   istream_iterator eos;
-   istream_iterator it (strm);
-   int i;
-   i = *it++
-   assert (it == eos);
-   strm.clear ();
-   strm &lt;&lt; "2 3 ";
-   assert (it != eos);
-   i = *++it;
-   assert (3 == i);
-     </pre>
-   </blockquote>
-   <p>
-
-Or is it intended that once an iterator becomes EOS it stays EOS until
-the end of its lifetime?
-
-   </p>
- 
- <p><i>[
-San Francisco:
-]</i></p>
-
 
 <blockquote>
 <p>
-We like the direction of the proposed resolution. We're not sure about
-the wording, and we need more time to reflect on it,
+Places where changes are <u>not</u> being
+proposed
 </p>
 <p>
-Move to Open. Detlef to rewrite the proposed resolution in such a way
-that no reference is made to exposition only members of
-<tt>istream_iterator</tt>.
+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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>):
 </p>
+<ul>
+    <li><p>20.8.14.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-07 Frankfurt:
+2009-08-18 Daniel adds:
 ]</i></p>
 
 
 <blockquote>
-Move to Ready.
-</blockquote>
-
-
-
- <p><b>Proposed resolution:</b></p>
-   <p>
-
-The discussion of this issue on the reflector suggests that the intent
-of the standard is for an <code>istreambuf_iterator</code> that has
-reached the EOS to remain in the EOS state until the end of its
-lifetime. Implementations that permit EOS iterators to return to a
-non-EOS state may only do so as an extension, and only as a result of
-calling <code>istream_iterator</code> member functions on EOS
-iterators whose behavior is in this case undefined.
-
-   </p>
-   <p>
-
-To this end we propose to change 24.6.1 [istream.iterator], p1,
-as follows:
-
-   </p>
-   <blockquote>
-
-The result of operator-&gt; on an end<ins>-</ins>of<ins>-</ins>stream
-is not defined. For any other iterator value a <code>const T*</code>
-is returned.<ins> Invoking <code>operator++()</code> on
-an <i>end-of-stream</i> iterator is undefined.</ins> It is impossible
-to store things into istream iterators...
-
-   </blockquote>
-   <p>
-
-Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so:
-
-   </p>
-   <blockquote>
-
-<pre>istream_iterator();</pre>
-
-<i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br>
-<ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins>
-
-<pre>istream_iterator(istream_type &amp;s);</pre>
-
-<i>Effects</i>: Initializes <code>in_stream</code> with &amp;s. value
-may be initialized during construction or the first time it is
-referenced.<br>
-<ins><i>Postcondition</i>: <code>in_stream == &amp;s</code>.</ins>
-
-<pre>istream_iterator(const istream_iterator &amp;x);</pre>
-
-<i>Effects</i>: Constructs a copy of <code>x</code>.<br>
-<ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins>
-
-<pre>istream_iterator&amp; operator++();</pre>
-
-<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
-<i>Effects</i>: <code>*in_stream &gt;&gt; value</code>.
-
-<pre>istream_iterator&amp; operator++(int);</pre>
-
-<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
-<i>Effects</i>:
-   <blockquote><pre>istream_iterator tmp (*this);
-*in_stream &gt;&gt; value;
-return tmp;
-     </pre>
-     </blockquote>
-   </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>
 
-<hr>
-<h3><a name="847"></a>847. string exception safety guarantees</h3>
-<p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Hervé Brönnimann <b>Opened:</b> 2008-06-05  <b>Last modified:</b> 2009-07-16</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
+<ol>
+<li>
 <p>
-In March, on comp.lang.c++.moderated, I asked what were the
-string exception safety guarantees are, because I cannot see
-*any* in the working paper, and any implementation I know offers
-the strong exception safety guarantee (string unchanged if a
-member throws exception). The closest the current draft comes to
-offering any guarantees is 21.4 [basic.string], para 3:
+21.4.1 [string.require]/2:
 </p>
 
 <blockquote>
-The class template <tt>basic_string</tt> conforms to the requirements
-for a Sequence Container (23.1.1), for a Reversible Container (23.1),
-and for an Allocator-aware container (91). The iterators supported by
-<tt>basic_string</tt> are random access iterators (24.1.5).
+"[..] The <tt>Allocator</tt> object used shall be a copy of the <tt>Allocator&gt;</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>
-However, the chapter 23 only says, on the topic of exceptions:  23.2 [container.requirements],
-para 10:
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>,
+X [rand.req.eng], Table 109, expression "<tt>T()</tt>":
 </p>
-
 <blockquote>
-<p>
-Unless otherwise specified (see 23.2.2.3 and 23.2.6.4) all container types defined in this clause meet the following 
-additional requirements:
-</p>
-
-<ul>
-<li>if an exception is thrown by...</li>
-</ul>
+Pre-/post-condition: "Creates an engine with the same initial state as
+all other default-constructed engines of type <tt>X</tt>."
 </blockquote>
 
 <p>
-I take it  as saying that this paragraph has *no* implication on
-<tt>std::basic_string</tt>, as <tt>basic_string</tt> isn't defined in Clause 23 and
-this paragraph does not define a *requirement* of Sequence
-nor Reversible Container, just of the models defined in Clause 23.
-In addition, LWG Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a> proposes to remove 23.2 [container.requirements], para 3.
+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>
-Finally, the fact that no operation on Traits should throw
-exceptions has no bearing, except to suggest (since the only
-other throws should be allocation, <tt>out_of_range</tt>, or <tt>length_error</tt>)
-that the strong exception guarantee can be achieved.
+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>
-The reaction in that group by Niels Dekker, Martin Sebor, and
-Bo Persson, was all that this would be worth an LWG issue.
+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>
-A related issue is that <tt>erase()</tt> does not throw.  This should be
-stated somewhere (and again, I don't think that the 23.2 [container.requirements], para 1
-applies here).
+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>
 
-<p><i>[
-San Francisco:
-]</i></p>
-
-
-<blockquote>
-Implementors will study this to confirm that it is actually possible.
 </blockquote>
 
 <p><i>[
-Daniel adds 2009-02-14:
+2009-08-18 Alisdair adds:
 ]</i></p>
 
 
 <blockquote>
-The proposed resolution of paper
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2815.html">N2815</a>
-interacts with this issue (the paper does not refer to this issue).
+<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-07 Frankfurt:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
@@ -11443,346 +9292,330 @@ Move to Ready.
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add a blanket statement in 21.4.1 [string.require]:
+Change 20.2.1 [utility.arg.requirements] para 2:
 </p>
 
 <blockquote>
-<p>
-- if any member function or operator of <tt>basic_string&lt;charT, traits, Allocator&gt;</tt>
-throws, that function or operator has no effect.
-</p>
-<p>
-- no <tt>erase()</tt> or <tt>pop_back()</tt> function throws.
-</p>
+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>
-As far as I can tell, this is achieved by any implementation.  If I made a
-mistake and it is not possible to offer this guarantee, then
-either state all the functions for which this is possible
-(certainly at least <tt>operator+=</tt>, <tt>append</tt>, <tt>assign</tt>, and <tt>insert</tt>),
-or add paragraphs to Effects clauses wherever appropriate.
+Change 23.3.2.1 [deque.cons] para 5:
 </p>
 
-
-
-
-
-<hr>
-<h3><a name="851"></a>851. simplified array construction</h3>
-<p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Benjamin Kosnik <b>Opened:</b> 2008-06-05  <b>Last modified:</b> 2009-07-25</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-This is an issue that came up on the libstdc++ list, where a
-discrepancy between "C" arrays and C++0x's <tt>std::array</tt> was pointed
-out.
-</p>
+<blockquote>
+<i>Effects:</i> Constructs a deque with n
+<del>default constructed</del><ins>value-initialized</ins>
+elements. 
+</blockquote>
 
 <p>
-In "C," this array usage is possible:
+Change 23.3.2.2 [deque.capacity] para 1:
 </p>
 
-<blockquote><pre>int ar[] = {1, 4, 6};
-</pre></blockquote>
+<blockquote>
+<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>
-But for C++, 
+Change 23.3.3.1 [forwardlist.cons] para 5:
 </p>
 
-<blockquote><pre>std::array&lt;int&gt; a = { 1, 4, 6 }; // error
-</pre></blockquote>
+<blockquote>
+<i>Effects:</i> Constructs a forward_list object with n <del>default
+constructed</del><ins>value-initialized</ins>
+elements.
+</blockquote>
 
 <p>
-Instead, the second parameter of the <tt>array</tt> template must be
-explicit, like so:
+Change 23.3.3.4 [forwardlist.modifiers] para 21:
 </p>
 
-<blockquote><pre>std::array&lt;int, 3&gt; a = { 1, 4, 6 };
-</pre></blockquote>
+<blockquote>
+<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>
-Doug Gregor proposes the following solution, that assumes
-generalized initializer lists.
+Change 23.3.4.1 [list.cons] para 5:
 </p>
 
-<blockquote><pre>template&lt;typename T, typename... Args&gt;
-inline array&lt;T, sizeof...(Args)&gt; 
-make_array(Args&amp;&amp;... args) 
-{ return { std::forward&lt;Args&gt;(args)... };  }
-</pre></blockquote>
+<blockquote>
+<i>Effects:</i> Constructs a list with n <del>default
+constructed</del><ins>value-initialized</ins>
+elements. 
+</blockquote>
 
 <p>
-Then, the way to build an <tt>array</tt> from a list of unknown size is:
+Change 23.3.4.2 [list.capacity] para 15:
 </p>
 
-<blockquote><pre>auto a = make_array&lt;T&gt;(1, 4, 6);
-</pre></blockquote>
-
-<p><i>[
-San Francisco:
-]</i></p>
+<blockquote>
+<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>
+<i>Effects:</i> Constructs a vector with n
+<del>default constructed</del><ins>value-initialized</ins>
+elements. 
+</blockquote>
+
 <p>
-Benjamin: Move to Ready?
+Change 23.3.6.2 [vector.capacity] para 24:
 </p>
+
+<blockquote>
+<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="870"></a>870. Do unordered containers not support function pointers for predicate/hasher?</h3>
+<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-17  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Bjarne: I'm not convinced this is useful enough to add, so I'd like us
-to have time to reflect on it.
+Good ol' associative containers allow both function pointers and
+function objects as feasible
+comparators, as described in 23.2.4 [associative.reqmts]/2:
 </p>
+
+<blockquote>
+Each associative container is parameterized on <tt>Key</tt> and an ordering
+relation <tt>Compare</tt> that
+induces a strict weak ordering (25.3) on elements of Key. [..]. The
+object of type <tt>Compare</tt> is
+called the comparison object of a container. This comparison object
+may be a pointer to
+function or an object of a type with an appropriate function call operator.[..]
+</blockquote>
+
 <p>
-Alisdair: the constraints are wrong, they should be
+The corresponding wording for unordered containers is not so clear,
+but I read it to disallow
+function pointers for the hasher and I miss a clear statement for the
+equality predicate, see
+23.2.5 [unord.req]/3+4+5:
 </p>
-<blockquote><pre>template&lt;ValueType T, ValueType... Args&gt;
-requires Convertible&lt;Args, T&gt;...
-array&lt;T, sizeof...(Args)&gt; make_array(Args&amp;&amp;... args);
-</pre></blockquote>
+
+<blockquote>
 <p>
-Alidair: this would be useful if we had a constexpr version.
+Each unordered associative container is parameterized by <tt>Key</tt>, by a
+function object <tt>Hash</tt> that
+acts as a hash function for 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>.[..]
 </p>
 <p>
-Bjarne: this is probably useful for arrays with a small number of
-elements, but it's not clearly useful otherwise.
+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>.
 </p>
 <p>
-Consensus is to move to Open.
+Two values <tt>k1</tt> and <tt>k2</tt> of type <tt>Key</tt> are considered equal if the
+container's equality function object
+returns <tt>true</tt> when passed those values.[..]
 </p>
 </blockquote>
 
-<p><i>[
-2009-06-07 Daniel adds:
-]</i></p>
-
-
-<blockquote>
 <p>
-I suggest a fix and a simplification of the current proposal: Recent
-prototyping by
-Howard showed, that a fix is required because narrowing conversion
-8.5.4 [dcl.init.list]/6 b.3
-would severely limit the possible distribution of argument types, e.g.
-the expression
-<tt>make_array&lt;double&gt;(1, 2.0)</tt> is ill-formed, because the narrowing
-happens <em>inside</em> the
-function body where no constant expressions exist anymore. Furthermore
-given e.g.
+and table 97 says in the column "assertion...post-condition" for the
+expression X::hasher:
 </p>
-<blockquote><pre>int f();
-double g();
-</pre></blockquote>
+
+<blockquote>
+<tt>Hash</tt> shall be a unary function object type such that the expression
+<tt>hf(k)</tt> has type <tt>std::size_t</tt>.
+</blockquote>
+
 <p>
-we probably want to support
+Note that 20.7 [function.objects]/1 defines as "Function objects are
+objects with an <tt>operator()</tt> defined.[..]"
 </p>
-<blockquote><pre>make_array&lt;double&gt;(f(), g());
-</pre></blockquote>
-
 <p>
-as well. To make this feasible, the currently suggested expansion
+Does this restriction exist by design or is it an oversight? If an
+oversight, I suggest that to apply
+the following
 </p>
 
-<blockquote><pre>{ std::forward&lt;Args&gt;(args)... }
-</pre></blockquote>
+<p><i>[
+2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
+]</i></p>
 
-<p>
-needs to be replaced by
-</p>
 
-<blockquote><pre>{ static_cast&lt;T&gt;(std::forward&lt;Args&gt;(args))... }
-</pre></blockquote>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
-<p>
-which is safe, because we already ensure convertibility via the
-element-wise <tt>Convertible&lt;Args, T&gt;</tt> requirement. Some other fixes are
-necessary: The <tt>ValueType</tt> requirement for the function <em>parameters</em>
-is invalid, because all lvalue arguments will deduce to an lvalue-reference,
-thereby no longer satisfying this requirement.
-</p>
 
-<p>
-The suggested simplification is to provide a default-computed effective
-type for the result array based on common_type and decay, in
-unconstrained form:
-</p>
+<blockquote>
+Ask Daniel to provide proposed wording that: makes it explicit that
+function pointers are function objects at the beginning of 20.7 [function.objects]; fixes the "requirements" for typedefs in
+20.7.5 [refwrap] to instead state that the function objects
+defined in that clause have these typedefs, but not that these typedefs
+are requirements on function objects; remove the wording that explicitly
+calls out that associative container comparators may be function
+pointers.
+</blockquote>
 
-<blockquote><pre>template&lt;typename... Args&gt;
-array&lt;typename decay&lt;typename common_type&lt;Args...&gt;::type&gt;::type,
-sizeof...(Args)&gt;
-make_array(Args&amp;&amp;... args);
-</pre></blockquote>
 
-<p>
-The approach used below is similar to that of <tt>make_pair</tt> and <tt>make_tuple</tt>
-using a symbol <tt>C</tt> to represent the decayed common type [Note: Special
-handling of <tt>reference_wrapper</tt> types is intentionally <em>not</em> provided, because
-our target has so satisfy <tt>ValueType</tt>, thus under the revised proposal only
-an all-<tt>reference_wrapper</tt>-arguments would be well-formed and an array of
-<tt>reference_wrapper</tt> will be constructed]. I do currently not suggest to
-add new concepts reflecting <tt>decay</tt> and <tt>common_type</tt>, but an implementor will
-need something like this to succeed. Note that we use a similar fuzziness for
-<tt>make_pair</tt> and <tt>make_tuple</tt> currently. This fuzziness is not related to
-the currently
-missing <tt>Constructible&lt;Vi, Ti&amp;&amp;&gt;</tt> requirement for those functions. The following
-proposal fixes that miss for <tt>make_array</tt>. If the corresponding <tt>C</tt> type
-deduction is
-explicitly wanted for standardization, here the implementation
-</p>
-
-<blockquote><pre>auto concept DC&lt;typename... T&gt; {
-  typename type = typename decay&lt;typename common_type&lt;T...&gt;::type&gt;::type;
-}
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-where <tt>C</tt> is identical to <tt>DC&lt;Args...&gt;::type</tt> in the proposed resolution below.
-</p>
-<p>
-I intentionally added no further type relation between type and the concept
-template parameters, but instead added this requirement below to make
-the specification as transparent as possible. As written this concept is
-satisfied, if the corresponding associated type exists.
+In 23.2.5 [unord.req]/3, just after the second sentence which is written as
 </p>
 
-<p><b>Suggested Resolution:</b></p>
+<blockquote>
+Additionally, <tt>unordered_map</tt> and <tt>unordered_multimap</tt> associate an
+arbitrary mapped type <tt>T</tt> with the <tt>Key</tt>.
+</blockquote>
 
-<ol>
-<li>
 <p>
-Add to the array synopsis in 23.3 [sequences]:
+add one further sentence:
 </p>
-<blockquote><pre><ins>
-template&lt;ReferentType... Args&gt;
-requires ValueType&lt;C&gt; &amp;&amp; IdentityOf&lt;Args&gt; &amp;&amp; Constructible&lt;C, Args&amp;&amp;&gt;...
-array&lt;C, sizeof...(Args)&gt;
-make_array(Args&amp;&amp;... args);
-</ins>
-</pre></blockquote>
-</li>
 
-<li>
+<blockquote>
+Both <tt>Hash</tt> and <tt>Pred</tt> may be pointers to function or objects of a type
+with an appropriate function call operator.
+</blockquote>
+
 <p>
-Append after 23.3.1.7 [array.tuple] Tuple interface to class template array
-the following new section:
+[Note1: Since the detailed requirements for <tt>Pred</tt> and <tt>Hash</tt> are given in
+p.4 and p.5, it an alternative resolution
+would be to insert a new paragraph just after p.5, which contains the
+above proposed sentence]
 </p>
-<blockquote>
 <p>
-23.4.1.7 Array creation functions [array.creation]
+[Note2: I do not propose a change of above quoted element in table 97,
+because the mis-usage of the
+notion of "function object" seems already present in the standard at
+several places, even if it includes
+function pointers, see e.g. 25 [algorithms]/7. The important point is
+that in those places a statement is
+given that the actually used symbol, like "Predicate" applies for
+function pointers as well]
 </p>
 
-<pre><ins>
-template&lt;ReferentType... Args&gt;
-requires ValueType&lt;C&gt; &amp;&amp; IdentityOf&lt;Args&gt; &amp;&amp; Constructible&lt;C, Args&amp;&amp;&gt;...
-array&lt;C, sizeof...(Args)&gt;
-make_array(Args&amp;&amp;... args);</ins>
-</pre>
+
+<p><b>Rationale:</b></p>
+<p><i>[
+San Francisco:
+]</i></p>
+
 
 <blockquote>
-<p><ins>
-Let <tt>C</tt> be <tt>decay&lt;common_type&lt;Args...&gt;::type&gt;::type</tt>.
-</ins></p>
-<p>
-<ins><i>Returns:</i> an <tt>array&lt;C, sizeof...(Args)&gt;</tt> initialized with
-<tt>{ static_cast&lt;C&gt;(std::forward&lt;Args&gt;(args))... }</tt>.
-</ins></p>
-</blockquote>
+This is fixed by
+<a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
 </blockquote>
 
-</li>
 
-</ol>
 
-</blockquote>
 
-<p><i>[
-2009-07 Frankfurt:
-]</i></p>
 
 
-<blockquote>
+<hr>
+<h3><a name="871"></a>871. Iota's requirements on T are too strong</h3>
+<p><b>Section:</b> 26.7.5 [numeric.iota] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-20  <b>Last modified:</b> 2009-10-22</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-The proposed resolution uses concepts.
+According to the recent WP
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>,
+26.7.5 [numeric.iota]/1, the requires clause
+of <tt>std::iota</tt> says:
 </p>
+
+<blockquote>
+<tt>T</tt> shall meet the requirements of <tt>CopyConstructible</tt> and <tt>Assignable</tt> types, and
+shall be convertible to <tt>ForwardIterator</tt>'s value type.[..]
+</blockquote>
+
 <p>
-Daniel to rewrite the proposed resolution.
+Neither <tt>CopyConstructible</tt> nor <tt>Assignable</tt> is needed, instead <tt>MoveConstructible</tt>
+seems to be the correct choice. I guess the current wording resulted as an
+artifact from comparing it with similar numerical algorithms like <tt>accumulate</tt>.
 </p>
+
 <p>
-Leave Open.
+Note: If this function will be conceptualized, the here proposed
+<tt>MoveConstructible</tt>
+requirement can be removed, because this is an implied requirement of
+function arguments, see
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2710.pdf">N2710</a>/[temp.req.impl]/3, last bullet.
 </p>
-</blockquote>
 
 <p><i>[
-2009-07-25 Daniel provides rewritten proposed resolution.
+post San Francisco:
 ]</i></p>
 
 
+<blockquote>
+Issue pulled by author prior to review.
+</blockquote>
 
+<p><i>[
+2009-07-30 Daniel reopened:
+]</i></p>
 
-<p><b>Proposed resolution:</b></p>
 
-<ol>
-<li>
-<p>
-Add to the array synopsis in 23.3 [sequences]:
-</p>
+<blockquote>
+with the absence of concepts, this issue (closed) is valid again and I
+suggest to reopen it.
+I also revised by proposed resolution based on N2723 wording:
+</blockquote>
 
-<blockquote><pre><ins>template&lt;class... Args&gt;
-  array&lt;<i>CT</i>, sizeof...(Args)&gt;
-  make_array(Args&amp;&amp;... args);</ins>
-</pre></blockquote>
-</li>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
-<li>
-<p>
-Append after 23.3.1.7 [array.tuple] "Tuple interface to class template array" the
-following new section:
-</p>
 
 <blockquote>
-<p>
-<ins>XX.X.X.X Array creation functions [array.creation]</ins>
-</p>
+Change 'convertible' to 'assignable', Move To Ready.
+</blockquote>
 
-<pre><ins>
-template&lt;class... Args&gt;
-array&lt;<i>CT</i>, sizeof...(Args)&gt;
-make_array(Args&amp;&amp;... args)
-</ins></pre>
 
-<blockquote>
-<p>
-<ins>Let <i>CT</i> be <tt>decay&lt;common_type&lt;Args...&gt;::type&gt;::type</tt>.</ins>
-</p>
+
+<p><b>Proposed resolution:</b></p>
 <p>
-<ins><i>Returns:</i> An <tt>array&lt;<i>CT</i>, sizeof...(Args)&gt;</tt> initialized with <tt>{
-static_cast&lt;<i>CT</i>&gt;(std::forward&lt;Args&gt;(args))... }</tt>.</ins>
+Change the first sentence of 26.7.5 [numeric.iota]/1:
 </p>
 
-<p><ins>
-[<i>Example:</i>
-</ins></p>
-<blockquote><pre><ins>
-int i = 0; int&amp; ri = i;
-make_array(42u, i, 2.78, ri);
-</ins></pre></blockquote>
-<p><ins>
-returns an array of type
-</ins></p>
-<blockquote><pre><ins>
-array&lt;double, 4&gt;
-</ins></pre></blockquote>
-
-<p><ins>
-&#8212;<i>end example</i>]</ins>
-</p>
-</blockquote>
+<blockquote>
+<i>Requires:</i> <tt>T</tt> shall <del>meet the requirements of <tt>CopyConstructible</tt> and
+<tt>Assignable</tt> types, and shall</del> be
+assignable to <tt>ForwardIterator</tt>'s value type. [..]
 </blockquote>
-</li>
-
-</ol>
 
 
 
@@ -11792,158 +9625,104 @@ array&lt;double, 4&gt;
 
 
 <hr>
-<h3><a name="854"></a>854. <tt>default_delete</tt> converting constructor underspecified</h3>
-<p><b>Section:</b> 20.8.9.1.1 [unique.ptr.dltr.dflt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-18  <b>Last modified:</b> 2009-07-26</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="872"></a>872. <tt>move_iterator::operator[]</tt> has wrong return type</h3>
+<p><b>Section:</b> 24.5.3.3.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2008-08-21  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-No relationship between <tt>U</tt> and <tt>T</tt> in the converting constructor for <tt>default_delete</tt> template.
+<tt>move_iterator</tt>'s <tt>operator[]</tt> is declared as:
 </p>
+
+<blockquote><pre>reference operator[](difference_type n) const;
+</pre></blockquote>
+
 <p>
-Requirements: <tt>U*</tt> is convertible to <tt>T*</tt> and <tt>has_virtual_destructor&lt;T&gt;</tt>;
-the latter should also become a concept.
-</p>
-<p>
-Rules out cross-casting.
-</p>
-<p>
-The requirements for <tt>unique_ptr</tt> conversions should be the same as those on the deleter.
+This has the same problem that <tt>reverse_iterator</tt>'s <tt>operator[]</tt> used to
+have: if the underlying iterator's <tt>operator[]</tt> returns a proxy, the
+implicit conversion to <tt>value_type&amp;&amp;</tt> could end up referencing a temporary
+that has already been destroyed. This is essentially the same issue that
+we dealt with for <tt>reverse_iterator</tt> in DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>.
 </p>
 
 <p><i>[
-Howard adds 2008-11-26:
+2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
 ]</i></p>
 
 
-<blockquote>
-<p>
-I believe we need to be careful to not outlaw the following use case, and
-I believe the current proposed wording
-(<tt>requires Convertible&lt;U*, T*&gt; &amp;&amp; HasVirtualDestructor&lt;T&gt;</tt>) does so:
-</p>
-
-<blockquote><pre>#include &lt;memory&gt;
-
-int main()
-{
-    std::unique_ptr&lt;int&gt; p1(new int(1));
-    std::unique_ptr&lt;const int&gt; p2(move(p1));
-    int i = *p2;
-<font color="#c80000">//    *p2 = i;  // should not compile</font>
-}
-</pre></blockquote>
-
-<p>
-I've removed "<tt>&amp;&amp; HasVirtualDestructor&lt;T&gt;</tt>" from the
-<tt>requires</tt> clause in the proposed wording.
-</p>
-
-</blockquote>
-
 <p><i>[
-Post Summit:
+2009-08-15 Howard adds:
 ]</i></p>
 
 
 <blockquote>
-<p>
-Alisdair: This issue has to stay in review pending a paper constraining
-<tt>unique_ptr</tt>.
-</p>
-<p>
-Consensus: We agree with the resolution, but <tt>unique_ptr</tt> needs
-to be constrained, too.
-</p>
-<p>
-Recommend Keep in Review.
-</p>
+I recommend closing this as  a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a> which addresses
+this issue for both <tt>move_iterator</tt> and <tt>reverse_iterator</tt>.
 </blockquote>
 
 <p><i>[
-Batavia (2009-05):
+2009-10 Santa Cruz:
 ]</i></p>
 
+
 <blockquote>
-Keep in Review status for the reasons cited.
+Move to Ready. Note that if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a> is reopened, it may yield a
+better resolution, but <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a> is currently marked NAD.
 </blockquote>
 
-<p><i>[
-2009-07 Frankfurt:
-]</i></p>
 
 
-<blockquote>
-<p>
-The proposed resolution uses concepts. Howard needs to rewrite the
-proposed resolution.
-</p>
+<p><b>Proposed resolution:</b></p>
 <p>
-Move back to Open.
+In 24.5.3.1 [move.iterator] and 24.5.3.3.12 [move.iter.op.index], change the declaration of
+<tt>move_iterator</tt>'s <tt>operator[]</tt> to:
 </p>
-</blockquote>
 
-<p><i>[
-2009-07-26 Howard provided rewritten proposed wording and moved to Review.
-]</i></p>
+<blockquote><pre><del>reference</del> <ins><i>unspecified</i></ins> operator[](difference_type n) const;
+</pre></blockquote>
 
 
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Add after 20.8.9.1.1 [unique.ptr.dltr.dflt], p1:
-</p>
+<p><b>Rationale:</b></p>
+<p><i>[
+San Francisco:
+]</i></p>
+
 
-<blockquote><pre>template &lt;class U&gt; default_delete(const default_delete&lt;U&gt;&amp; other);
-</pre>
 <blockquote>
-<p>
--1- <i>Effects:</i> ...
-</p>
-<p><ins>
-<i>Remarks:</i> This constructor shall participate in overload resolution
-if and only if <tt>U*</tt> is implicitly convertible to <tt>T*</tt>.
-</ins></p>
-</blockquote>
+NAD Editorial, see
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2777.pdf">N2777</a>.
 </blockquote>
 
 
 
 
-
-
 <hr>
-<h3><a name="857"></a>857. <tt>condition_variable::time_wait</tt> return <tt>bool</tt> error prone</h3>
-<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-06-13  <b>Last modified:</b> 2009-07-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="885"></a>885. pair assignment</h3>
+<p><b>Section:</b> 20.3.4 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-07-17</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>
-The meaning of the <tt>bool</tt> returned by <tt>condition_variable::timed_wait</tt> is so
-obscure that even the class' designer can't deduce it correctly. Several
-people have independently stumbled on this issue.
-</p>
-<p>
-It might be simpler to change the return type to a scoped enum:
-</p>
-<blockquote><pre>enum class timeout { not_reached, reached };
+<blockquote><pre>20.2.3 pairs
+Missing assignemnt operator:
+template&lt;class U , class V&gt;
+  requires CopyAssignable&lt;T1, U&gt; &amp;&amp; CopyAssignable&lt;T2, V&gt;
+    pair&amp; operator=(pair&lt;U , V&gt; const &amp; p );
 </pre></blockquote>
 
 <p>
-That's the same cost as returning a <tt>bool</tt>, but not subject to mistakes. Your example below would be:
+Well, that's interesting. This assignment operator isn't in the
+current working paper, either. Perhaps we deemed it acceptable to
+build a temporary of type <tt>pair</tt> from <tt>pair&lt;U, V&gt;</tt>, then move-assign
+from that temporary?
+</p>
+<p>
+It sounds more like an issue waiting to be opened, unless you want to plug
+it now.  As written we risk moving from lvalues.
 </p>
 
-<blockquote><pre>if (cv.wait_until(lk, time_limit) == timeout::reached )
-  throw time_out();
-</pre></blockquote>
-
-<p><i>[
-Beman to supply exact wording.
-]</i></p>
-
-
 <p><i>[
 San Francisco:
 ]</i></p>
@@ -11951,376 +9730,349 @@ San Francisco:
 
 <blockquote>
 <p>
-There is concern that the enumeration names are just as confusing, if
-not more so, as the bool. You might have awoken because of a signal or a
-spurious wakeup, for example.
-</p>
-<p>
-Group feels that this is a defect that needs fixing.
-</p>
-<p>
-Group prefers returning an enum over a void return.
+Would be NAD if better ctors fixed it.
 </p>
 <p>
-Howard to provide wording.
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>.
 </p>
 </blockquote>
 
 <p><i>[
-2009-06-14 Beman provided wording.
+post San Francisco:
 ]</i></p>
 
 
+<blockquote>
+Possibly NAD Editorial, solved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
+</blockquote>
+
 <p><i>[
-2009-07 Frankfurt:
+2009-05-25 Alisdair adds:
 ]</i></p>
 
 
 <blockquote>
-Move to Ready.
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a> was something I reported while reviewing the library concepts
+documents ahead of San Francisco.  The missing operator was added as part of
+the paper adopted at that meeting
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>)
+and I can confirm this operator is
+present in the current working paper.  I recommend NAD.
+</blockquote>
+
+<p><i>[
+2009-07 Frankfurt
+]</i></p>
+
+
+<blockquote>
+We agree with the intent, but we need to wait for the dust to settle on concepts.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change Condition variables 30.5 [thread.condition], Header
-condition_variable synopsis, as indicated:
 </p>
 
-<blockquote><pre>namespace std {
-  class condition_variable;
-  class condition_variable_any;
 
-  <ins>enum class cv_status { no_timeout, timeout };</ins>
-}
-</pre></blockquote>
 
+
+
+<hr>
+<h3><a name="887"></a>887. issue with condition::wait_...</h3>
+<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Change Class condition_variable 30.5.1 [thread.condition.condvar] as indicated:
+The Posix/C++ working group has identified an inconsistency between
+Posix and the C++ working draft in that Posix requires the clock to be
+identified at creation, whereas C++ permits identifying the clock at the
+call to wait.  The latter cannot be implemented with the former.
 </p>
 
-<blockquote><pre>class condition_variable { 
-public:
-  ...
-  template &lt;class Clock, class Duration&gt;
-    <del>bool</del> <ins>cv_status</ins> wait_until(unique_lock&lt;mutex&gt;&amp; lock,
-                    const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
-  template &lt;class Clock, class Duration, class Predicate&gt;
-    bool wait_until(unique_lock&lt;mutex&gt;&amp; lock,
-                    const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time,
-                    Predicate pred);
-
-  template &lt;class Rep, class Period&gt;
-    <del>bool</del> <ins>cv_status</ins> wait_for(unique_lock&lt;mutex&gt;&amp; lock,
-                  const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
-  template &lt;class Rep, class Period, class Predicate&gt;
-    bool wait_for(unique_lock&lt;mutex&gt;&amp; lock,
-                  const chrono::duration&lt;Rep, Period&gt;&amp; rel_time,
-                  Predicate pred);
-  ...
-};
+<p><i>[
+San Francisco:
+]</i></p>
 
-...
 
-template &lt;class Clock, class Duration&gt;
-  <del>bool</del> <ins>cv_status</ins> wait_until(unique_lock&lt;mutex&gt;&amp; lock,
-                  const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
-</pre>
 <blockquote>
 <p>
--15- <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
+Howard recommends NAD with the following explanation:
 </p>
-<ul>
-<li>
-no other thread is waiting on this <tt>condition_variable</tt> object or
-</li>
-<li>
-<tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
-arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
-<tt>wait_for</tt> or <tt>wait_until</tt>.).
-</li>
-</ul>
 
 <p>
--16- <i>Effects:</i>
+The intent of the current wording is for the <tt>condtion_variable::wait_until</tt>
+be able to handle user-defined clocks as well as clocks the system knows about.
+This can be done by providing overloads for the known clocks, and another
+overload for unknown clocks which synchs to a known clock before waiting.
+For example:
 </p>
 
-<ul>
-<li>
-Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
-</li>
-<li>
-When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
-</li>
-<li>
-The function will unblock when signaled by a call to <tt>notify_one()</tt>,
-a call to <tt>notify_all()</tt>, <del>by 
-the current time exceeding <tt>abs_time</tt></del> <ins>if <tt>Clock::now() &gt;= abs_time</tt></ins>,
-or spuriously.
-</li>
-<li>
-If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior
-to exiting the function scope.
-</li>
-</ul>
+<blockquote><pre>template &lt;class Duration&gt;
+bool
+condition_variable::wait_until(unique_lock&lt;mutex&gt;&amp; lock,
+                               const chrono::time_point&lt;chrono::system_clock, Duration&gt;&amp; abs_time)
+{
+    using namespace chrono;
+    nanoseconds d = __round_up&lt;nanoseconds&gt;(abs_time.time_since_epoch());
+    __do_timed_wait(lock.mutex()-&gt;native_handle(), time_point&lt;system_clock, nanoseconds&gt;(d));
+    return system_clock::now() &lt; abs_time;
+}
+
+template &lt;class Clock, class Duration&gt;
+bool
+condition_variable::wait_until(unique_lock&lt;mutex&gt;&amp; lock,
+                               const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time)
+{
+    using namespace chrono;
+    system_clock::time_point    s_entry = system_clock::now();
+    typename Clock::time_point  c_entry = Clock::now();
+    nanoseconds dn = __round_up&lt;nanoseconds&gt;(abs_time.time_since_epoch() -
+                                              c_entry.time_since_epoch());
+    __do_timed_wait(lock.mutex()-&gt;native_handle(), s_entry + dn);
+    return Clock::now() &lt; abs_time;
+}
+</pre></blockquote>
 
 <p>
--17- <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
+In the above example, <tt>system_clock</tt> is the only clock which the underlying
+condition variable knows how to deal with.  One overload just passes that clock
+through.  The second overload (approximately) converts the unknown clock into
+a <tt>system_clock  time_point</tt> prior to passing it down to the native
+condition variable.
 </p>
 
 <p>
--18- <i>Returns:</i> <del><tt>Clock::now() &lt; abs_time</tt></del>
-<ins><tt>cv_status::timeout</tt> if the function unblocked because <tt>abs_time</tt>
-was reached, otherwise <tt>cv_status::no_timeout</tt></ins>.
+On Posix systems vendors are free to add implementation defined constructors which
+take a clock.  That clock can be stored in the condition_variable, and converted
+to (or not as necessary) as shown above.
 </p>
 
 <p>
--19- <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition
-cannot be achieved.
+If an implementation defined constructor takes a clock (for example), then part
+of the semantics for that implementation defined ctor might include that a
+<tt>wait_until</tt> using a clock other than the one constructed with results
+in an error (exceptional condition) instead of a conversion to the stored clock.
+Such a design is up to the vendor as once an implementation defined ctor is used,
+the vendor is free to specifiy the behavior of waits and/or notifies however
+he pleases (when the cv is constructed in an implementation defined manner).
 </p>
+</blockquote>
+
+<p><i>[
+Post Summit:
+]</i></p>
 
+
+<blockquote>
 <p>
--20- <i>Error conditions:</i>
+"POSIX people will review the proposed NAD resolution at their upcoming NY
+meeting.
 </p>
 
-<ul>
-<li>
-<tt>operation_not_permitted</tt> &#8212; if the thread does not own the lock.
-</li>
-<li>
-equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
-</li>
-</ul>
-</blockquote>
-
-<pre>template &lt;class Rep, class Period&gt;
-  <del>bool</del> <ins>cv_status</ins> wait_for(unique_lock&lt;mutex&gt;&amp; lock,
-                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
-
-</pre>
-<blockquote>
-<p>
--21- <i><del>Effects</del> <ins>Returns</ins>:</i>
-</p>
-<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
-</pre></blockquote>
 <p>
-<del>-22- <i>Returns:</i> <tt>false</tt> if the call is returning because the time
-duration specified by <tt>rel_time</tt> has elapsed, 
-otherwise <tt>true</tt>.</del>
+See the minutes at: <a href="http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009">http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009</a>.
 </p>
+</blockquote>
 
 <p><i>[
-This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> in detail, but does
-not do so in spirit.  If both issues are accepted, there is a logical merge.
+2009-07 Frankfurt
 ]</i></p>
 
+
+<blockquote>
+Move to NAD.
 </blockquote>
 
-<pre>template &lt;class Clock, class Duration, class Predicate&gt; 
-  bool wait_until(unique_lock&lt;mutex&gt;&amp; lock, 
-                  const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time, 
-                  Predicate pred);
-</pre>
+<p><i>[
+2009-07-18 Detlef reopens the issue:
+]</i></p>
+
 
 <blockquote>
 <p>
--23- <i>Effects:</i>
+On Friday afternoon in Frankfurt is was decided that 887 is NAD.
+This decision was mainly based on a sample implementation presented
+by Howard that implemented one clock on top of another.
+Unfortunately this implementation doesn't work for the probably most
+important case where a system has a monotonic clock and a real-time
+clock (or "wall time" clock):
 </p>
-<blockquote><pre>while (!pred()) 
-  if (<del>!</del>wait_until(lock, abs_time) <ins>== cv_status::timeout</ins>) 
-    return pred(); 
-return true;
-</pre></blockquote>
-
 <p>
--24- <i>Returns:</i> <tt>pred()</tt>.
+If the underlying "system_clock" is a monotonic clock, and
+the program waits on the real-time clock, and the real-time clock
+is set forward, the wait will unblock too late.
 </p>
 
 <p>
--25- [<i>Note:</i>
-The returned value indicates whether the predicate evaluates to
-<tt>true</tt> regardless of whether the timeout was triggered.
-&#8212; <i>end note</i>].
+If the underlying "system_clock" is a real-time clock, and the
+program waits on the monotonic clock, and the real-time clock
+is set back, the wait again will unblock too late.
 </p>
-</blockquote>
-</blockquote>
 
 <p>
-Change Class condition_variable_any 30.5.2 [thread.condition.condvarany] as indicated:
+Sorry that I didn't remember this on Friday, but it was Friday
+afternoon after a busy week...
 </p>
 
-<blockquote><pre>class condition_variable_any {
-public:
-  ...
-  template &lt;class Lock, class Clock, class Duration&gt;
-    <del>bool</del> <ins>cv_status</ins> wait_until(Lock&amp; lock,
-                    const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
-  template &lt;class Lock, class Clock, class Duration, class Predicate&gt;
-    bool wait_until(Lock&amp; lock,
-                    const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time,
-                    Predicate pred);
-
-  template &lt;class Lock, class Rep, class Period&gt;
-    <del>bool</del> <ins>cv_status</ins> wait_for(Lock&amp; lock,
-                  const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
-  template &lt;class Lock, class Rep, class Period, class Predicate&gt;
-    bool wait_for(Lock&amp; lock,
-                  const chrono::duration&lt;Rep, Period&gt;&amp; rel_time,
-                  Predicate pred);
-  ...
-};
+<p>
+So as the decision was made on a wrong asumption, I propose to re-open
+the issue.
+</p>
+</blockquote>
 
-...
+<p><i>[
+2009-07-26 Howard adds:
+]</i></p>
 
-template &lt;class Lock, class Clock, class Duration&gt;
-  <del>bool</del> <ins>cv_status</ins> wait_until(Lock&amp; lock,
-                  const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
-</pre>
 
 <blockquote>
-
 <p>
--13- <i>Effects:</i>
+Detlef correctly argues that <tt>condition_variable::wait_until</tt> could
+return "too late" in the context of clocks being adjusted during the wait.  I agree
+with his logic.  But I disagree that this makes this interface unimplementable
+on POSIX.
 </p>
 
-<ul>
-<li>
-Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
-</li>
-<li>
-When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
-</li>
-<li>
-The function will unblock when signaled by a call to <tt>notify_one()</tt>,
-a call to <tt>notify_all()</tt>, <del>by 
-the current time exceeding <tt>abs_time</tt></del> <ins>if <tt>Clock::now() &gt;= abs_time</tt></ins>,
-or spuriously.
-</li>
-<li>
-If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior
-to exiting the function scope.
-</li>
-</ul>
-
 <p>
--14- <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
+The POSIX spec also does not guarantee that <tt>pthread_cond_timedwait</tt> does
+not return "too late" when clocks are readjusted during the wait.  Indeed, the
+POSIX specification lacks any requirements at all concerning how soon
+<tt>pthread_cond_timedwait</tt> returns after a time out.  This is evidently a
+QOI issue by the POSIX standard.  Here is a quote of the most relevant normative
+text concerning <tt>pthread_cond_timedwait</tt> found
+<a href="http://www.unix.org/single_unix_specification/">here</a>.
 </p>
 
+<blockquote>
+The <tt>pthread_cond_timedwait()</tt> function shall be equivalent to
+<tt>pthread_cond_wait()</tt>, except that an error is returned if the absolute
+time specified by <tt>abstime</tt> passes (that is, system time equals or exceeds
+<tt>abstime</tt>) before the condition <tt>cond</tt> is signaled or broadcasted, or if the
+absolute time specified by <tt>abstime</tt> has already been passed at the time
+of the call.
+</blockquote>
+
 <p>
--15- <i>Returns:</i> <del><tt>Clock::now() &lt; abs_time</tt></del>
-<ins><tt>cv_status::timeout</tt> if the function unblocked because <tt>abs_time</tt>
-was reached, otherwise <tt>cv_status::no_timeout</tt></ins>.
+I.e. the POSIX specification speaks of the error code returned in case of a time
+out, but not on the timeliness of that return.
 </p>
 
 <p>
--16- <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition
-cannot be achieved.
+Might this simply be an oversight, or minor defect in the POSIX specification?
 </p>
 
 <p>
--17- <i>Error conditions:</i>
+I do not believe so.  This same section goes on to say in <em>non-normative</em>
+text:
 </p>
 
-<ul>
-<li>
-equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
-</li>
-</ul>
+<blockquote>
+For cases when the system clock is advanced discontinuously by an
+operator, it is expected that implementations process any timed wait
+expiring at an intervening time as if that time had actually occurred.
 </blockquote>
 
-<pre>template &lt;class Lock, class Rep, class Period&gt;
-  <del>bool</del> <ins>cv_status</ins> wait_for(Lock&amp; lock,
-                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
-
-</pre>
-
-<blockquote>
 <p>
--18- <i><del>Effects</del> <ins>Returns</ins>:</i>
+Here is non-normative wording encouraging the implementation to ignore an advancing
+underlying clock and subsequently causing an early (spurious) return.  There is
+no wording at all which addresses Detlef's example of a "late return".  With
+<tt>pthread_cond_timedwait</tt> this would be caused by setting the system clock
+backwards.  It seems reasonable to assume, based on the wording that is already
+in the POSIX spec, that again, the discontinuously changed clock would be ignored
+by <tt>pthread_cond_timedwait</tt>. 
 </p>
-<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
-</pre></blockquote>
 
 <p>
-<del>-19- <i>Returns:</i> <tt>false</tt> if the call is returning because the time
-duration specified by <tt>rel_time</tt> has elapsed, 
-otherwise <tt>true</tt>.</del>
+A noteworthy difference between <tt>pthread_cond_timedwait</tt> and
+<tt>condition_variable::wait_until</tt> is that the POSIX spec appears to
+say that <tt>ETIMEDOUT</tt> should be returned if <tt>pthread_cond_timedwait</tt>
+returns because of timeout signal, whether or not the system clock was discontinuously
+advanced during the wait.  In contrast <tt>condition_variable::wait_until</tt>
+always returns:
 </p>
 
-<p><i>[
-This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> in detail, but does
-not do so in spirit.  If both issues are accepted, there is a logical merge.
-]</i></p>
-
-
-</blockquote>
+<blockquote><pre><tt>Clock::now() &lt; abs_time</tt>
+</pre></blockquote>
 
-<pre>template &lt;class Lock, class Clock, class Duration, class Predicate&gt; 
-  bool wait_until(Lock&amp; lock, 
-                  const chrono::time_point&lt;Clock, Duration&gt;&amp; <del>rel_time</del> <ins>abs_time</ins>, 
-                  Predicate pred);
-</pre>
+<p>
+That is, the C++ spec requires that the clock be rechecked (detecting discontinuous
+adjustments during the wait) at the time of return.  <tt>condition_variable::wait_until</tt>
+may indeed return early or late.  But regardless it will return a value
+reflecting timeout status at the time of return (even if clocks have been adjusted).
+Of course the clock may be adjusted after the return value is computed but before the client has
+a chance to read the result of the return.  Thus there are no iron-clad guarantees
+here.
+</p>
 
-<blockquote>
 <p>
--20- <i>Effects:</i>
+<tt>condition_variable::wait_until</tt> (and <tt>pthread_cond_timedwait</tt>)
+is little more than a convenience function for making sure
+<tt>condition_variable::wait</tt> doesn't hang for an unreasonable amount of
+time (where the client gets to define "unreasonable").  I do not think it
+is in anyone's interest to try to make it into anything more than that.
 </p>
-<blockquote><pre>while (!pred()) 
-  if (<del>!</del>wait_until(lock, abs_time) <ins>== cv_status::timeout</ins>) 
-    return pred(); 
-return true;
-</pre></blockquote>
 
 <p>
--21- <i>Returns:</i> <tt>pred()</tt>.
+I maintain that this is a useful and flexible specification in the spirit of
+C++, and is implementable on POSIX.  The implementation technique described above
+is a reasonable approach.  There may also be higher quality approaches.  This
+specification, like the POSIX specification, gives a wide latitude for QOI.
 </p>
 
 <p>
--22- [<i>Note:</i>
-The returned value indicates whether the predicate evaluates to
-<tt>true</tt> regardless of whether the timeout was triggered.
-&#8212; <i>end note</i>].
+I continue to recommend NAD, but would not object to a clarifying note regarding
+the behavior of <tt>condition_variable::wait_until</tt>.  At the moment, I do
+not have good wording for such a note, but welcome suggestions.
 </p>
-</blockquote>
 
 </blockquote>
 
+<p><i>[
+2009-09-30: See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2969.html">N2969</a>.
+]</i></p>
 
 
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
 
+<blockquote>
+The LWG is in favor of Detlef to supply revision which adopts Option 2 from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2969.html">N2969</a>
+but is modified by saying that <tt>system_clock</tt> must be available for <tt>wait_until</tt>.
+</blockquote>
 
-<hr>
-<h3><a name="859"></a>859. Monotonic Clock is Conditionally Supported?</h3>
-<p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-06-23  <b>Last modified:</b> 2009-07-21</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
 
-<p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>.</p>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661</a>
-says that there is a class named <tt>monotonic_clock</tt>. It also says that this
-name may be a synonym for <tt>system_clock</tt>, and that it's conditionally
-supported. So the actual requirement is that it can be monotonic or not,
-and you can tell by looking at <tt>is_monotonic</tt>, or it might not exist at
-all (since it's conditionally supported). Okay, maybe too much
-flexibility, but so be it.
-</p>
-<p>
-A problem comes up in the threading specification, where several
-variants of <tt>wait_for</tt> explicitly use <tt>monotonic_clock::now()</tt>. What is the
-meaning of an effects clause that says
 </p>
 
-<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
-</pre></blockquote>
+
+
+
+
+<hr>
+<h3><a name="889"></a>889. thread::id comparisons</h3>
+<p><b>Section:</b> 30.3.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-10-22</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.id">issues</a> in [thread.thread.id].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 324</b></p>
 
 <p>
-when <tt>monotonic_clock</tt> is not required to exist?
+The <tt>thread::id</tt> type supports the full set of comparison operators.  This
+is substantially more than is required for the associative containers that
+justified them.  Please place an issue against the threads library.
 </p>
 
 <p><i>[
@@ -12330,1217 +10082,828 @@ San Francisco:
 
 <blockquote>
 <p>
-Nick: maybe instead of saying that chrono::monotonic_clock is
-conditionally supported, we could say that it's always there, but not
-necessarily supported..
-</p>
-<p>
-Beman: I'd prefer a typedef that identifies the best clock to use for
-wait_for locks.
-</p>
-<p>
-Tom: combine the two concepts; create a duration clock type, but keep
-the is_monotonic test.
-</p>
-<p>
-Howard: if we create a duration_clock type, is it a typedef or an
-entirely true type?
-</p>
-<p>
-There was broad preference for a typedef.
+Would depend on proposed extension to POSIX, or non-standard extension.
+What about hash? POSIX discussing op. POSIX not known to be considering
+support needed for hash, op.
 </p>
 <p>
-Move to Open. Howard to provide wording to add a typedef for
-duration_clock and to replace all uses of monotonic_clock in function
-calls and signatures with duration_clock.
+Group expresses support for putting ids in both unordered and ordered containers.
 </p>
 </blockquote>
 
 <p><i>[
-Howard notes post-San Francisco:
+post San Francisco:
 ]</i></p>
 
 
 <blockquote>
 <p>
-After further thought I do not believe that creating a <tt>duration_clock typedef</tt>
-is the best way to proceed.  An implementation may not need to use a
-<tt>time_point</tt> to implement the <tt>wait_for</tt> functions.
+Howard:  It turns out the current working paper
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
+<i>already has</i> <tt>hash&lt;thread::id&gt;</tt>
+(20.7 [function.objects], 20.7.16 [unord.hash]).  We simply
+overlooked it in the meeting.  It is a good thing we voted in favor of it
+(again). :-)
 </p>
-
 <p>
-For example, on POSIX systems <tt>sleep_for</tt> can be implemented in terms of
-<tt>nanosleep</tt> which takes only a duration in terms of nanoseconds.  The current
-working paper does not describe <tt>sleep_for</tt> in terms of <tt>sleep_until</tt>.
-And paragraph 2 of 30.2.4 [thread.req.timing] has the words strongly encouraging
-implementations to use monotonic clocks for <tt>sleep_for</tt>:
+Recommend NAD.
 </p>
 
-<blockquote>
-2 The member functions whose names end in <tt>_for</tt> take an argument that
-specifies a relative time. Implementations should use a monotonic clock to
-measure time for these functions.
 </blockquote>
 
-<p>
-I believe the approach taken in describing the effects of <tt>sleep_for</tt>
-and <tt>try_lock_for</tt> is also appropriate for <tt>wait_for</tt>.  I.e. these
-are not described in terms of their <tt>_until</tt> variants.
-</p>
+<p><i>[
+Post Summit:
+]</i></p>
 
+
+<blockquote>
+Recommend to close as NAD. For POSIX, see if we need to add a function to
+convert <tt>pthread_t</tt> to integer.
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+Post Summit, Alisdair adds:
 ]</i></p>
 
 
 <blockquote>
 <p>
-Beman will send some suggested wording changes to Howard.
+The recommendation for LWG-889/UK-324 is NAD, already specified.
 </p>
 <p>
-Move to Ready.
+It is not clear to me that the specification is complete.
+</p>
+<p>
+In particular, the synopsis of <tt>&lt;functional&gt;</tt> in 20.7 [function.objects] does not mention <tt>hash&lt; thread::id
+&gt;</tt> nor <tt>hash&lt; error_code &gt;</tt>, although their
+existence is implied by 20.7.16 [unord.hash], p1.
+</p>
+<p>
+I am fairly uncomfortable putting the declaration for the
+<tt>thread_id</tt> specialization into <tt>&lt;functional&gt;</tt> as
+<tt>id</tt> is a nested class inside <tt>std::thread</tt>, so it implies
+that <tt>&lt;functional&gt;</tt> would require the definition of the
+<tt>thread</tt> class template in order to forward declared
+<tt>thread::id</tt> and form this specialization.
+</p>
+<p>
+It seems better to me that the dependency goes the other way around
+(<tt>&lt;thread&gt;</tt> will more typically make use of
+<tt>&lt;functional&gt;</tt> than vice-versa) and the
+<tt>hash&lt;thread::id&gt;</tt> specialization be declared in the
+<tt>&lt;thread&gt;</tt> header.
+</p>
+<p>
+I think <tt>hash&lt;error_code&gt;</tt> could go into either
+<tt>&lt;system_error&gt;</tt> or <tt>&lt;functional&gt;</tt> and have no
+immediate preference either way.  However, it should clearly appear in
+the synopsis of one of these two.
+</p>
+<p>
+Recommend moving 889 back to open, and tying in a reference to UK-324.
 </p>
 </blockquote>
 
 <p><i>[
-2009-07-21 Beman added the requested wording changes to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>.
+Batavia (2009-05):
 ]</i></p>
 
+<blockquote>
+Howard observes that <tt>thread::id</tt> need not be a nested class;
+it could be a <tt>typedef</tt> for a more visible type.
+</blockquote>
 
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 30.5.1 [thread.condition.condvar], p21-22:
-</p>
+<p><i>[
+2009-05-24 Alisdair adds:
+]</i></p>
 
 <blockquote>
-<pre>template &lt;class Rep, class Period&gt; 
-  bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
-                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
-</pre>
-<blockquote>
-<p><ins>
-<i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
-</ins></p>
-<ul>
-<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
-<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
-arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
-<tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
-</ul>
-<p>
-21 <i>Effects:</i>
-</p>
-<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del>
-</pre></blockquote>
-<ul>
-<li><ins>
-Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
-</ins></li>
-
-<li><ins>
-When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
-</ins></li>
+I do not believe this is correct.  <tt>thread::id</tt> is explicitly documents as a
+nested class, rather than as an unspecified typedef analogous to an
+iterator.  If the intent is that this is not implemented as a nested class
+(under the as-if freedoms) then this is a novel form of standardese.
+</blockquote>
 
-<li><ins>
-The function will unblock when signaled by a call to <tt>notify_one()</tt>, a call
-to <tt>notify_all()</tt>, by 
-the elapsed time <tt>rel_time</tt> passing (30.2.4 [thread.req.timing]),
-or spuriously.
-</ins></li>
+<p><i>[
+2009-07 Frankfurt
+]</i></p>
 
-<li><ins>
-If the function exits via an exception, <tt>lock.unlock()</tt> shall be called 
-prior to exiting the function scope.
-</ins></li>
-</ul>
 
-<p><ins>
-<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
-</ins></p>
+<blockquote>
+Decided we want to move hash specialization for thread_id to the thread
+header. Alisdair to provide wording.
+</blockquote>
 
+<p><i>[
+2009-07-28 Alisdair provided wording, moved to Review.
+]</i></p>
 
-<p>
-22 <i>Returns:</i> <tt>false</tt> if the call is returning because the time
-duration specified by <tt>rel_time</tt> has elapsed, otherwise <tt>true</tt>.
-</p>
 
 <p><i>[
-This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a> in detail, but does
-not do so in spirit.  If both issues are accepted, there is a logical merge.
+2009-10 Santa Cruz:
 ]</i></p>
 
 
-<p><ins>
-<i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
-</ins></p>
+<blockquote>
+Add a strike for <tt>hash&lt;thread::id&gt;</tt>. Move to Ready
+</blockquote>
 
-<p><ins>
-<i>Error conditions:</i>
-</ins></p>
 
-<ul>
-<li><ins>
-<tt>operation_not_permitted</tt> -- if the thread does not own the lock.
-</ins></li>
-<li><ins>
-equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
-</ins></li>
-</ul>
 
-</blockquote>
-</blockquote>
+<p><b>Proposed resolution:</b></p>
 
 <p>
-Change 30.5.1 [thread.condition.condvar], p26-p29:
+Remove the following prototype from the synopsis in
+20.7 [function.objects]:
 </p>
 
-<blockquote>
-<pre>template &lt;class Rep, class Period, class Predicate&gt; 
-  bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
-                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, 
-                Predicate pred);
-</pre>
-<blockquote>
-<p><ins>
-<i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
-</ins></p>
-<ul>
-<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
-<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
-arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
-<tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
-</ul>
-<p>
-<i>26 Effects:</i>
-</p>
-<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del>
-</pre>
-<ul>
-<li><ins>
-Executes a loop:  Within the loop the function first evaluates <tt>pred()</tt>
-and exits the loop if the result of <tt>pred()</tt> is <tt>true</tt>.
-</ins></li>
-<li><ins>
-Atomically calls <tt>lock.unlock()</tt>
-and blocks on <tt>*this</tt>.
-</ins></li>
-<li><ins>
-When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
-</ins></li>
-<li><ins>
-The function will unblock when signaled by a call to <tt>notify_one()</tt>, a
-call to <tt>notify_all()</tt>, by the elapsed time <tt>rel_time</tt> passing (30.1.4
-[thread.req.timing]), or spuriously.
-</ins></li>
-<li><ins>
-If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
-prior to exiting the function scope.
-</ins></li>
-<li><ins>
-The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time
-duration specified by <tt>rel_time</tt> has elapsed.
-</ins></li>
-</ul>
-</blockquote>
+<blockquote><pre><del>
+template &lt;&gt; struct hash&lt;std::thread::id&gt;;
+</del></pre></blockquote>
 
 <p>
-27 [<i>Note:</i> There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>,
-even if the timeout has already expired. <i>-- end note</i>]
+Add to 30.3 [thread.threads], p1 Header <tt>&lt;thread&gt;</tt> synopsis:
 </p>
 
-<p><ins>
-<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
-</ins></p>
+<blockquote><pre><ins>template &lt;class T&gt; struct hash;
+template &lt;&gt; struct hash&lt;thread::id&gt;;</ins>
+</pre></blockquote>
 
 <p>
-28 <i>Returns:</i> <tt>pred()</tt>
+Add template specialization below class definition in 30.3.1.1 [thread.thread.id]
 </p>
 
+<blockquote><pre><ins>template &lt;&gt;
+struct hash&lt;thread::id&gt; : public unary_function&lt;thread::id, size_t&gt; {
+   size_t operator()(thread::id val) const;
+};</ins>
+</pre></blockquote>
+
 <p>
-29 [<i>Note:</i> The returned value indicates whether the predicate evaluates to
-<tt>true</tt> regardless of whether the timeout was triggered. <i>-- end note</i>]
+Extend note in p2 30.3.1.1 [thread.thread.id] with second sentence:
 </p>
 
-<p><ins>
-<i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
-</ins></p>
-
-<p><ins>
-<i>Error conditions:</i>
-</ins></p>
-
-<ul>
-<li><ins>
-<tt>operation_not_permitted</tt> -- if the thread does not own the lock.
-</ins></li>
-<li><ins>
-equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
-</ins></li>
-</ul>
-
-</blockquote>
+<blockquote>
+[<i>Note:</i> Relational operators allow <tt>thread::id</tt> objects to be used
+as keys in associative containers.
+<ins><tt>hash</tt> template specialization allow <tt>thread::id</tt> objects to be used as keys
+in unordered containers.</ins>
+&#8212; <i>end note</i>]
 </blockquote>
 
 <p>
-Change 30.5.2 [thread.condition.condvarany], p18-19:
+Add new paragraph to end of 30.3.1.1 [thread.thread.id]
 </p>
 
-<blockquote>
-<pre>template &lt;class Lock, class Rep, class Period&gt; 
-  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
+<blockquote><pre><ins>template &lt;&gt; struct hash&lt;thread::id&gt;;</ins>
 </pre>
-<blockquote>
-<p>
-18 <i>Effects:</i>
-</p>
-<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del>
-</pre></blockquote>
-
-<ul>
-<li><ins>
-Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
-</ins></li>
+<blockquote><ins>
+An explicit specializations of the class template hash (20.7.16 [unord.hash])
+shall be provided for the values of type <tt>thread::id</tt>
+suitable for use as keys in unordered associative containers (23.5 [unord]).
+</ins></blockquote>
+</blockquote>
 
-<li><ins>
-When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
-</ins></li>
 
-<li><ins>
-The function will unblock when signaled by a call to <tt>notify_one()</tt>, a call to
-<tt>notify_all()</tt>, by
-the elapsed time <tt>rel_time</tt> passing (30.2.4 [thread.req.timing]),
-or spuriously.
-</ins></li>
 
-<li><ins>
-If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
-prior to exiting the function scope.
-</ins></li>
-</ul>
 
-<p><ins>
-<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
-</ins></p>
 
+<hr>
+<h3><a name="891"></a>891. std::thread, std::call_once issue</h3>
+<p><b>Section:</b> 30.3.1.2 [thread.thread.constr], 30.4.5.2 [thread.once.callonce] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-10-24</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I notice that the vararg overloads of <tt>std::thread</tt> and <tt>std::call_once</tt>
+(N2723 30.3.1.2 [thread.thread.constr] and 30.4.5.2 [thread.once.callonce]) are no longer specified in terms of
+<tt>std::bind</tt>; instead, some of the <tt>std::bind</tt> wording has been inlined into
+the specification.
+</p>
+<p>
+There are two problems with this.
+</p>
 <p>
-19 <i>Returns:</i> <tt>false</tt> if the call is returning because the time duration
-specified by <tt>rel_time</tt> has elapsed, otherwise <tt>true</tt>.
+First, the specification (and implementation) in terms of <tt>std::bind</tt> allows, for example:
 </p>
 
-<p><ins>
-<i>Throws:</i> <tt>std::system_error</tt> when the returned value, effects,
-or postcondition cannot be achieved.
-</ins></p>
+<blockquote><pre>std::thread th( f, 1, std::bind( g ) );
+</pre></blockquote>
 
-<p><ins>
-<i>Error conditions:</i>
-</ins></p>
+<p>
+which executes <tt>f( 1, g() )</tt> in a thread. This can be useful. The
+"inlined" formulation changes it to execute <tt>f( 1, bind(g) )</tt> in a thread.
+</p>
+<p>
+Second, assuming that we don't want the above, the specification has copied the wording
+</p>
 
-<ul>
-<li><ins>
-equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
-</ins></li>
-</ul>
-</blockquote>
+<blockquote>
+<tt>INVOKE(func, w1, w2, ..., wN)</tt> (20.6.2) shall be a valid
+expression for some values <tt>w1, w2, ..., wN</tt>
 </blockquote>
 
 <p>
-Change 30.5.2 [thread.condition.condvarany], p23-p26:
+but this is not needed since we know that our argument list is args; it should simply be
 </p>
 
 <blockquote>
-<pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt; 
-  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);
-</pre>
-<blockquote>
-<p><ins>
-<i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
-</ins></p>
-<ul>
-<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
-<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
-arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
-<tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
-</ul>
-<p>
-<i>23 Effects:</i>
-</p>
-<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del>
-</pre>
-<ul>
-<li><ins>
-Executes a loop:  Within the loop the function first evaluates <tt>pred()</tt>
-and exits the loop if the result of <tt>pred()</tt> is <tt>true</tt>.
-</ins></li>
-<li><ins>
-Atomically calls <tt>lock.unlock()</tt>
-and blocks on <tt>*this</tt>.
-</ins></li>
-<li><ins>
-When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
-</ins></li>
-<li><ins>
-The function will unblock when signaled by a call to <tt>notify_one()</tt>, a
-call to <tt>notify_all()</tt>, by the elapsed time <tt>rel_time</tt> passing (30.1.4
-[thread.req.timing]), or spuriously.
-</ins></li>
-<li><ins>
-If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
-prior to exiting the function scope.
-</ins></li>
-<li><ins>
-The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time
-duration specified by <tt>rel_time</tt> has elapsed.
-</ins></li>
-</ul>
+<tt>INVOKE(func, args...)</tt> (20.6.2) shall be a valid expression
 </blockquote>
 
-<p>
-24 [<i>Note:</i> There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>,
-even if the timeout has already expired. <i>-- end note</i>]
-</p>
+<p><i>[
+Summit:
+]</i></p>
 
-<p><ins>
-<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
-</ins></p>
 
-<p>
-25 <i>Returns:</i> <tt>pred()</tt>
-</p>
+<blockquote>
+Move to open.
+</blockquote>
 
-<p>
-26 [<i>Note:</i> The returned value indicates whether the predicate evaluates to
-<tt>true</tt> regardless of whether the timeout was triggered. <i>-- end note</i>]
-</p>
+<p><i>[
+Post Summit Anthony provided proposed wording.
+]</i></p>
 
-<p><ins>
-<i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
-</ins></p>
 
-<p><ins>
-<i>Error conditions:</i>
-</ins></p>
+<p><i>[
+2009-07 Frankfurt
+]</i></p>
 
-<ul>
-<li><ins>
-<tt>operation_not_permitted</tt> -- if the thread does not own the lock.
-</ins></li>
-<li><ins>
-equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
-</ins></li>
-</ul>
 
+<blockquote>
+Leave Open. Await decision for thread variadic constructor.
 </blockquote>
-</blockquote>
-
 
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
 
+<blockquote>
+See proposed wording for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a> for this, for the formulation
+on how to solve this.  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a> modifies the thread constructor to
+have "pass by value" behavior with pass by reference efficiency through the use
+of the <tt>decay</tt> trait.  This same formula would be useful for <tt>call_once</tt>.
+</blockquote>
 
 
 
-<hr>
-<h3><a name="860"></a>860. Floating-Point State</h3>
-<p><b>Section:</b> 26 [numerics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-06-23  <b>Last modified:</b> 2009-03-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numerics">issues</a> in [numerics].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Proposed resolution:</b></p>
 <p>
-There are a number of functions that affect the floating point state.
-These function need to be thread-safe, but I'm unsure of the right
-approach in the standard, as we inherit them from C.
+Change paragraph 4 of 30.3.1.2 [thread.thread.constr] to:
 </p>
 
-<p><i>[
-San Francisco:
-]</i></p>
-
-
 <blockquote>
-<p>
-Nick: I think we already say that these functions do not introduce data
-races; see 17.6.5.6/20
-</p>
-<p>
-Pete: there's more to it than not introducing data races; are these
-states maintained per thread?
-</p>
-<p>
-Howard: 21.5/14 says that strtok and strerror are not required to avoid
-data races, and 20.9/2 says the same about asctime, gmtime, ctime, and
-gmtime.
-</p>
-<p>
-Nick: POSIX has a list of not-safe functions. All other functions are
-implicitly thread safe.
-</p>
-<p>
-Lawrence is to form a group between meetings to attack this issue. Nick
-and Tom volunteered to work with Lawrence.
-</p>
-<p>
-Move to Open.
-</p>
-</blockquote>
-
-<p><i>[
-Post Summit:
-]</i></p>
-
-
+<pre>template &lt;class F&gt; explicit thread(F f);
+template &lt;class F, class ...Args&gt; thread(F&amp;&amp; f, Args&amp;&amp;... args);
+</pre>
 <blockquote>
-<p>
-Hans: Sane oses seem ok. Sensible thing is implementable and makes sense.
-</p>
-<p>
-Nick: Default wording seems to cover this? Hole in POSIX, these
-functions need to be added to list of thread-unsafe functions.
-</p>
-<p>
-Lawrence: Not sufficient, not "thread-safe" per our definition, but
-think of state as a thread-local variable. Need something like "these
-functions only affect state in the current thread."
-</p>
-<p>
-Hans: Suggest the following wording: "The floating point environment is
-maintained per-thread."
-</p>
-<p>
-Walter: Any other examples of state being thread safe that are not
-already covered elsewhere?
-</p>
-<p>
-Have thread unsafe functions paper which needs to be updated. Should
-just fold in 26.3 [cfenv] functions.
-</p>
-<p>
-Recommend Open. Lawrence instead suggests leaving it open until we have
-suitable wording that may or may not include the thread local
-commentary.
-</p>
+-4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt>
+shall be <tt>CopyConstructible</tt> if an lvalue and otherwise
+<tt>MoveConstructible</tt>. <tt><i>INVOKE</i>(f, <del>w1, w2, ..., wN</del> <ins>args...</ins>)</tt>
+(20.6.2) shall be a valid expression<del> for some values <i>w1, w2, ...,
+wN</i>, where <tt>N == sizeof...(Args)</tt></del>.
+</blockquote>
 </blockquote>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
+Change paragraph 1 of 30.4.5.2 [thread.once.callonce] to:
 </p>
 
+<blockquote><pre>template&lt;class Callable, class ...Args&gt; 
+  void call_once(once_flag&amp; flag, Callable func, Args&amp;&amp;... args);
+</pre>
+<blockquote>
+-1- <i>Requires:</i> The template parameters <tt>Callable&gt;</tt> and each
+<tt>Ti</tt> in <tt>Args</tt> shall be <tt>CopyConstructible</tt> if an
+lvalue and otherwise <tt>MoveConstructible</tt>. <tt><i>INVOKE</i>(func,
+<del>w1, w2, ..., wN</del> <ins>args...</ins>)</tt> (20.6.2) shall be a
+valid expression<del> for some values <i>w1, w2, ..., wN</i>, where
+<tt>N == sizeof...(Args)</tt></del>.
+</blockquote>
+</blockquote>
+
 
 
 
 
 <hr>
-<h3><a name="861"></a>861. Incomplete specification of EqualityComparable for std::forward_list</h3>
-<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-06-24  <b>Last modified:</b> 2009-07-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="893"></a>893. std::mutex issue</h3>
+<p><b>Section:</b> 30.4.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-10-22</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.class">issues</a> in [thread.mutex.class].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a></p>
 <p><b>Discussion:</b></p>
 <p>
-Table 89, Container requirements, defines <tt>operator==</tt> in terms of the container
-member function <tt>size()</tt> and the algorithm <tt>std::equal</tt>:
-</p>
-
-<blockquote>
-<tt>==</tt> is an equivalence relation. <tt>a.size() == b.size() &amp;&amp;
-equal(a.begin(), a.end(), b.begin()</tt>
-</blockquote>
-
-<p>
-The new container <tt>forward_list</tt> does not provide a <tt>size</tt> member function
-by design but does provide <tt>operator==</tt> and <tt>operator!=</tt> without specifying it's semantic.
-</p>
-<p>
-Other parts of the (sequence) container requirements do also depend on
-<tt>size()</tt>, e.g. <tt>empty()</tt>
-or <tt>clear()</tt>, but this issue explicitly attempts to solve the missing
-<tt>EqualityComparable</tt> specification,
-because of the special design choices of <tt>forward_list</tt>.
+30.4.1.1 [thread.mutex.class]/27 (in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
+says that the behavior is undefined if:
 </p>
+<ul>
+<li>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or
+<tt>try_lock()</tt> on that object</li>
+</ul>
 <p>
-I propose to apply one of the following resolutions, which are described as:
+I don't believe that this is right. Calling <tt>lock()</tt> or <tt>try_lock()</tt> on a
+locked <tt>mutex</tt> is well defined in the general case. <tt>try_lock()</tt> is required
+to fail and return <tt>false</tt>. <tt>lock()</tt> is required to either throw an
+exception (and is allowed to do so if it detects deadlock) or to block
+until the <tt>mutex</tt> is free. These general requirements apply regardless of
+the current owner of the <tt>mutex</tt>; they should apply even if it's owned by
+the current thread.
 </p>
-
-<ol type="A">
-<li>
-Provide a definition, which is optimal for this special container without
-previous size test. This choice prevents two <tt>O(N)</tt> calls of <tt>std::distance()</tt>
-with the corresponding container ranges and instead uses a special
-<tt>equals</tt> implementation which takes two container ranges instead of 1 1/2.
-</li>
-<li>
-The simple fix where the usual test is adapted such that <tt>size()</tt> is replaced
-by <tt>distance</tt> with corresponding performance disadvantages.
-</li>
-</ol>
 <p>
-Both proposal choices are discussed, the preferred choice of the author is
-to apply (A).
+Making double <tt>lock()</tt> undefined behavior probably can be justified (even
+though I'd still disagree with the justification), but <tt>try_lock()</tt> on a
+locked <tt>mutex</tt> must fail.
 </p>
 
 <p><i>[
-San Francisco:
+Summit:
 ]</i></p>
 
-
 <blockquote>
 <p>
-There's an Option C: change the requirements table to use distance().
-</p>
-<p>
-LWG found Option C acceptable.
-</p>
-<p>
-Martin will draft the wording for Option C.
+Move to open. Proposed resolution:
 </p>
+<ul>
+<li>
+In 30.4.1 [thread.mutex.requirements] paragraph 12, change the error
+condition for <tt>resource_deadlock_would_occur</tt> to: "if the implementation
+detects that a deadlock would occur"
+</li>
+<li>
+Strike 30.4.1.1 [thread.mutex.class] paragraph 3 bullet 2 "a thread that owns a mutex object
+calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or"
+</li>
+</ul>
 </blockquote>
 
 <p><i>[
-post San Francisco:
+2009-07 Frankfurt
 ]</i></p>
 
 
 <blockquote>
-Martin provided wording for Option C.
+Move to Review. Alisdair to provide note.
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt
+2009-07-31 Alisdair provided note.
 ]</i></p>
 
 
-<blockquote>
-<p>
-Other operational semantics (see, for example, Tables 82 and 83) are
-written in terms of a container's size() member. Daniel to update
-proposed resolution C.
-</p>
 <p><i>[
-Howard: Commented out options A and B.
+2009-10 Santa Cruz:
 ]</i></p>
 
-</blockquote>
-
-<p><i>[
-2009-07-26 Daniel updated proposed resolution C.
-]</i></p>
 
+<blockquote>
+Moved to Ready.
+</blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
-
-
 <p>
-Option (C):
+In 30.4.1 [thread.mutex.requirements] paragraph 12 change:
 </p>
-<blockquote>
-
-<p><i>[
-The changes are relative to
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>
-but concept-free.
-]</i></p>
-
 
-<ol>
+<blockquote>
+<ul>
+<li>...</li>
 <li>
-<p>
-In 23.2.1 [container.requirements.general] change Table 80 -- Container requirements as indicated:
-</p>
+<tt>resource_deadlock_would_occur</tt> -- if the <del>current thread already owns the mutex and is able 
+to detect it</del> <ins>implementation detects that a deadlock would occur</ins>.
+</li>
+<li>...</li>
+</ul>
+</blockquote>
 
-<ol type="a">
-<li>
 <p>
-Change the text in the Assertion/note column in the row for "<tt>X u</tt>;"
-as follows:
+Strike 30.4.1.1 [thread.mutex.class] paragraph 3 bullet 2:
 </p>
-
 <blockquote>
-post: <tt>u.<del>size() == 0</del><ins>empty() == true</ins></tt>
-</blockquote>
+<p>
+-3- The behavior of a program is undefined if:
+</p>
+<ul>
+<li>...</li>
+<li>
+<del>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or</del>
 </li>
+<li>...</li>
+</ul>
+</blockquote>
 
-<li>
 <p>
-Change the text in the Assertion/note column in the row for "<tt>X();</tt>"
-as follows:
+Add the following note after p3 30.4.1.1 [thread.mutex.class]
 </p>
 
 <blockquote>
-<tt>X().<del>size() == 0</del><ins>empty() == true</ins></tt>
+[<i>Note:</i> a program may deadlock if the thread that owns a <tt>mutex</tt>
+object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object. If the program can
+detect the deadlock, a <tt>resource_deadlock_would_occur</tt> error condition may
+be observed. &#8212; <i>end note</i>]
 </blockquote>
-</li>
 
-<li>
+
+
+
+
+
+<hr>
+<h3><a name="896"></a>896. Library thread safety issue</h3>
+<p><b>Section:</b> 20.8.15.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2008-09-16  <b>Last modified:</b> 2009-10-25</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Change the text in the Operational Semantics column in the row for
-"<tt>a == b</tt>" as follows:
+It is unclear whether <tt>shared_ptr</tt> is thread-safe in the sense that
+multiple threads may simultaneously copy a <tt>shared_ptr</tt>.  However this
+is a critical piece of information for the client, and it has significant
+impact on usability for many applications.  (Detlef Vollman thinks it
+is currently clear that it is not thread-safe.  Hans Boehm thinks
+it currently requires thread safety, since the <tt>use_count</tt> is not an
+explicit field, and constructors and assignment take a const reference
+to an existing <tt>shared_ptr</tt>.)
 </p>
-<blockquote>
-<tt>==</tt> is an equivalence relation.
-<tt><del>a.size()</del><ins>distance(a.begin(), a.end())</ins> ==
-   <del>b.size()</del><ins>distance(b.begin(), b.end())</ins> &amp;&amp;
-equal(a.begin(), a.end(), b.begin())</tt>
-</blockquote>
-</li>
 
-<li>
 <p>
-Change the text in the Operational Semantics column in the row for
-"<tt>a.size()</tt>" as follows:
+Pro thread-safety:
 </p>
-
-<blockquote>
-<tt><del>a.end() - a.begin()</del><ins>distance(a.begin(), a.end())</ins></tt>
-</blockquote>
-</li>
-
-<li>
 <p>
-Change the text in the Operational Semantics column in the row for
-"<tt>a.max_size()</tt>" as follows:
+Many multi-threaded usages are impossible.  A thread-safe version can
+be used to destroy an object when the last thread drops it, something
+that is often required, and for which we have no other easy mechanism.
 </p>
-
-<blockquote>
-<tt><del>size()</del><ins>distance(begin(), end())</ins></tt> of the largest
-possible container
-</blockquote>
-</li>
-
-<li>
 <p>
-Change the text in the Operational Semantics column in the row for
-"<tt>a.empty()</tt>" as follows:
+Against thread-safety:
+</p>
+<p>
+The thread-safe version is well-known to be far more expensive, even
+if used by a single thread.  Many applications, including all single-threaded
+ones, do not care.
 </p>
 
-<blockquote>
-<tt><del>a.size() == 0</del><ins>a.begin() == a.end()</ins></tt>
-</blockquote>
-</li>
-</ol>
-</li>
+<p><i>[
+San Francisco:
+]</i></p>
 
-<li>
+
+<blockquote>
 <p>
-In 23.2.1 [container.requirements.general] change Table 82 -- Allocator-aware container requirements as indicated:
+Beman: this is a complicated issue, and would like to move this to Open
+and await comment from Peter Dimov; we need very careful and complete
+rationale for any decision we make; let's go slow
 </p>
-
-<ol type="a">
-<li>
 <p>
-Change the text in the Assertion/note column in the row for "<tt>X() /
-X u;</tt>" as follows:
+Detlef: I think that <tt>shared_ptr</tt> should not be thread-safe.
 </p>
-
-<blockquote>
-<i>Requires:</i> <tt>A</tt> is <tt>DefaultConstructible</tt> post: <tt><del>u.size() ==
-0</del><ins>u.empty() == true</ins></tt>, <tt>get_allocator() == A()</tt>
-</blockquote>
-</li>
-
-<li>
 <p>
-Change the text in the Assertion/note column in the row for "<tt>X(m) /
-X u(m);</tt>" as follows:
+Hans: When you create a thread with a lambda, it in some cases makes it
+very difficult for the lambda to reference anything in the heap. It's
+currently ambiguous as to whether you can use a <tt>shared_ptr</tt> to get at an
+object.
 </p>
-
-<blockquote>
-post: <tt><del>u.size() == 0</del><ins>u.empty() == true</ins>,
-get_allocator() == m</tt>
-</blockquote>
-</li>
-</ol>
-</li>
-
-<li>
 <p>
-In 23.2.3 [sequence.reqmts] change Table 83 -- Sequence container requirements as indicated:
+Leave in Open. Detlef will submit an alternative proposed resolution
+that makes <tt>shared_ptr</tt> explicitly unsafe.
+</p>
+<p>
+A third option is to support both threadsafe and non-safe share_ptrs,
+and to let the programmer decide which behavior they want.
 </p>
 
-<ol type="a">
-<li>
 <p>
-Change the text in the Assertion/note column in the row for "<tt>X(n,
-t) / X a(n, t)</tt>" as follows:
+Beman:  Peter, do you support the PR?
 </p>
 
+<p>
+Peter:
+</p>
 <blockquote>
-post: <tt><del>size()</del><ins>distance(begin(), end())</ins> == n [..]</tt>
-</blockquote>
-</li>
-
-<li>
 <p>
-Change the text in the Assertion/note column in the row for "<tt>X(i,
-j) / X a(i, j)</tt>" as follows:
+Yes, I support the proposed resolution, and I certainly oppose any
+attempts to <tt>make shared_ptr</tt> thread-unsafe.
+</p>
+<p>
+I'd mildly prefer if
 </p>
-
 <blockquote>
-[..] post: <del><tt>size() ==</tt> distance between <tt>i</tt> and
-<tt>j</tt></del><ins><tt>distance(begin(), end()) == distance(i, j)</tt></ins> [..]
+[<i>Note:</i> This is true in spite of that fact that such functions often
+modify <tt>use_count()</tt> <i>--end note</i>]
 </blockquote>
-</li>
-
-<li>
 <p>
-Change the text in the Assertion/note column in the row for
-"<tt>a.clear()</tt>" as follows:
+is changed to
 </p>
 <blockquote>
-<tt><ins>a.</ins>erase(<ins>a.</ins>begin(), <ins>a.</ins>end())</tt> post:
-<tt><del>size() == 0</del><ins>a.empty() == true</ins></tt>
+[<i>Note:</i> This is true in spite of that fact that such functions often
+cause a change in <tt>use_count()</tt> <i>--end note</i>]
 </blockquote>
-</li>
-</ol>
-</li>
-
-<li>
 <p>
-In 23.2.4 [associative.reqmts] change Table 85 -- Associative container requirements as indicated:
+(or something along these lines) to emphasise that <tt>use_count()</tt> is not,
+conceptually, a variable, but a return value.
 </p>
+</blockquote>
+
+</blockquote>
 
 <p><i>[
-Not every occurrence of <tt>size()</tt> was replaced, because all current
-associative containers
-have a <tt>size</tt>. The following changes ensure consistency regarding the
-semantics of "<tt>erase</tt>"
-for all tables and adds some missing objects
+2009-07 Frankfurt
 ]</i></p>
 
 
-<ol type="a">
-<li>
+<blockquote>
 <p>
-Change the text in the Complexity column in the row for
-"<tt>a.insert(i, j)</tt>" as follows:
+Vote: Do we want one thread-safe shared pointer or two? If two, one
+would allow concurrent construction and destruction of shared pointers,
+and one would not be thread-safe. If one, then it would be thread-safe.
 </p>
-<blockquote>
-<tt>N log(<ins>a.</ins>size() + N)</tt> <del>(<tt>N</tt> is the distance from <tt>i</tt> to
-<tt>j</tt>)</del><ins> where <tt>N == distance(i, j)</tt></ins>
-</blockquote>
-</li>
-
-<li>
 <p>
-Change the text in the Complexity column in the row for
-"<tt>a.erase(k)</tt>" as follows:
+No concensus on that vote.
 </p>
-<blockquote>
-<tt>log(<ins>a.</ins>size()) + <ins>a.</ins>count(k)</tt>
-</blockquote>
-</li>
-
-<li>
 <p>
-Change the text in the Complexity column in the row for
-"<tt>a.erase(q1, q2)</tt>" as follows:
+Hans to improve wording in consultation with Pete. Leave Open.
 </p>
-
-<blockquote>
-<tt>log(<ins>a.</ins>size()) + N</tt> where <tt>N</tt> <del>is the distance from <tt>q1</tt>
-to <tt>q2</tt></del>
-   <ins><tt>== distance(q1, q2)</tt></ins>.
 </blockquote>
-</li>
 
-<li>
-<p>
-Change the text in the Assertion/note column in the row for
-"<tt>a.clear()</tt>" as follows:
-</p>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
 
 <blockquote>
-<tt><ins>a.</ins>erase(a.begin(),a.end())</tt> post: <tt><del>size() ==
-0</del><ins>a.empty() == true</ins></tt>
+Move to Ready. Ask Editor to clear up wording a little when integrating to
+make it clear that the portion after the first comma only applies for
+the presence of data races.
 </blockquote>
-</li>
 
-<li>
-<p>
-Change the text in the Complexity column in the row for "<tt>a.clear()</tt>"
-as follows:
-</p>
+<p><i>[
+2009-10-24 Hans adds:
+]</i></p>
+
 
 <blockquote>
-linear in <tt><ins>a.</ins>size()</tt>
-</blockquote>
-</li>
+<p>
+I think we need to pull 896 back from ready, unfortunately.  My wording
+doesn't say the right thing.
+</p>
 
-<li>
 <p>
-Change the text in the Complexity column in the row for
-"<tt>a.count(k)</tt>" as follows:
+I suspect we really want to say something along the lines of:
 </p>
 
 <blockquote>
-<tt>log(<ins>a.</ins>size()) + <ins>a.</ins>count(k)</tt>
+For purposes of determining the presence of a data race, member
+functions access and modify only the <tt>shared_ptr</tt> and
+<tt>weak_ptr</tt> objects themselves and not objects they refer to.
+Changes in <tt>use_count()</tt> do not reflect modifications that can
+introduce data races.
 </blockquote>
-</li>
-</ol>
-</li>
 
-<li>
 <p>
-In 23.2.5 [unord.req] change Table 87 -- Unordered associative container requirements as indicated:
+But I think this needs further discussion by experts to make sure this
+is right.
 </p>
-<p><i>[
-The same rational as for Table 85 applies here
-]</i></p>
-
 
-<ol type="a">
-<li>
 <p>
-Change the text in the Assertion/note column in the row for
-"<tt>a.clear()</tt>" as follows:
+Detlef and I agree continue to disagree on the resolution, but I think
+we agree that it would be good to try to expedite this so that it can be
+in CD2, since it's likely to generate NB comments no matter what we do.
+And lack of clarity of intent is probably the worst option.  I think it
+would be good to look at this between meetings.
 </p>
-
-<blockquote>
-[..] Post: <tt>a.<del>size() == 0</del><ins>empty() == true</ins></tt>
-</blockquote>
-</li>
-</ol>
-</li>
-</ol>
-
-
 </blockquote>
 
 
 
-
-
-<hr>
-<h3><a name="865"></a>865. More algorithms that throw away information</h3>
-<p><b>Section:</b> 25.4.6 [alg.fill], 25.4.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-07-13  <b>Last modified:</b> 2009-07-25</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Proposed resolution:</b></p>
 <p>
-In regard to library defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a> I found some more algorithms which
-unnecessarily throw away information. These are typically algorithms,
-which sequentially write into an <tt>OutputIterator</tt>, but do not return the
-final value of this output iterator. These cases are:
+Make it explicitly thread-safe, in this weak sense, as I believe was intended:
 </p>
-
-<ol>
-<li>
-<pre>template&lt;class OutputIterator, class Size, class T&gt;
-void fill_n(OutputIterator first, Size n, const T&amp; value);</pre></li>
-
-<li>
-<pre>template&lt;class OutputIterator, class Size, class Generator&gt;
-void generate_n(OutputIterator first, Size n, Generator gen);</pre></li>
-</ol>
 <p>
-In both cases the minimum requirements on the iterator are
-<tt>OutputIterator</tt>, which means according to the requirements of
-24.2.3 [output.iterators]/2 that only single-pass iterations are guaranteed.
-So, if users of <tt>fill_n</tt> and <tt>generate_n</tt> have *only* an <tt>OutputIterator</tt>
-available, they have no chance to continue pushing further values
-into it, which seems to be a severe limitation to me.
+Insert in 20.8.15.2 [util.smartptr.shared], before p5:
 </p>
-
-<p><i>[
-Post Summit Daniel "conceptualized" the wording.
-]</i></p>
-
-
-<p><i>[
-Batavia (2009-05):
-]</i></p>
-
 <blockquote>
 <p>
-Alisdair likes the idea, but has concerns about the specific wording
-about the returns clauses.
-</p>
-<p>
-Alan notes this is a feature request.
-</p>
-<p>
-Bill notes we have made similar changes to other algorithms.
+For purposes of determining the presence of a data race,
+member functions do not modify <tt>const shared_ptr</tt> and
+const <tt>weak_ptr</tt> arguments, nor any objects they
+refer to.  [<i>Note:</i> This is true in spite of that fact that such functions often
+cause a change in <tt>use_count()</tt> <i>--end note</i>]
 </p>
+</blockquote>
 <p>
-Move to Open.
+On looking at the text, I'm not sure we need a similar disclaimer
+anywhere else, since nothing else has the problem with the modified
+<tt>use_count()</tt>.  I think Howard arrived at a similar conclusion.
 </p>
-</blockquote>
-
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
-
-
-<blockquote>
-We have a consensus for moving forward on this issue, but Daniel needs
-to deconceptify it.
-</blockquote>
-
-<p><i>[
-2009-07-25 Daniel provided non-concepts wording.
-]</i></p>
 
 
 
 
-<p><b>Proposed resolution:</b></p>
 
-<ol>
-<li>
+<hr>
+<h3><a name="900"></a>900. stream move-assignment</h3>
+<p><b>Section:</b> 27.9.1.8 [ifstream.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-09-20  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Replace the current declaration of <tt>fill_n</tt> in 25 [algorithms]/2, header
-<tt>&lt;algorithm&gt;</tt> synopsis and in 25.4.6 [alg.fill] by
+It
+appears that we have an issue similar to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a> regarding the move-assignment of
+stream types. For example, when assigning to an <tt>std::ifstream</tt>,
+<tt>ifstream1</tt>, it seems preferable to close the file originally held by
+<tt>ifstream1</tt>:
 </p>
 
-<blockquote><pre>template&lt;class OutputIterator, class Size, class T&gt;
-  <del>void</del><ins>OutputIterator</ins> fill_n(OutputIterator first, Size n, const T&amp; value);
+<blockquote><pre>ifstream1 = std::move(ifstream2); 
 </pre></blockquote>
 
 <p>
-Just after the effects clause add a new returns clause saying:
+The current Draft
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
+specifies that the move-assignment of
+stream types like <tt>ifstream</tt> has the same effect as a swap:
 </p>
 
 <blockquote>
-<ins><i>Returns:</i> For <tt>fill_n</tt> and positive <tt>n</tt>, returns <tt>first + n</tt>. Otherwise
-returns <tt>first</tt> for <tt>fill_n</tt>.</ins>
-</blockquote>
-</li>
-
-<li>
-<p>
-Replace the current declaration of <tt>generate_n</tt> in 25 [algorithms]/2,
-header <tt>&lt;algorithm&gt;</tt> synopsis and in 25.4.7 [alg.generate] by
-</p>
-
-<blockquote><pre>template&lt;class OutputIterator, class Size, class Generator&gt;
-  <del>void</del><ins>OutputIterator</ins> generate_n(OutputIterator first, Size n, Generator gen);
-</pre></blockquote>
-
 <p>
-Just after the effects clause add a new returns clause saying:
+Assign and swap 27.9.1.8 [ifstream.assign]
 </p>
-
+<pre>basic_ifstream&amp; operator=(basic_ifstream&amp;&amp; rhs); 
+</pre>
 <blockquote>
-<ins>For <tt>generate_n</tt> and positive <tt>n</tt>, returns <tt>first + n</tt>. Otherwise
-returns <tt>first</tt> for <tt>generate_n</tt>.</ins>
+<i>Effects:</i> <tt>swap(rhs)</tt>.
+</blockquote>
 </blockquote>
-</li>
-</ol>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="868"></a>868. default construction and value-initialization</h3>
-<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-22  <b>Last modified:</b> 2009-07-19</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</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="http://www.open-std.org/jtc1/sc22/wg21/docs/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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>. This issue is
-related with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>.
-</p>
 
 <p><i>[
-San Francisco:
+Batavia (2009-05):
 ]</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.
+Howard agrees with the analysis and the direction proposed.
 </p>
 <p>
-This issue relates to Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#886">886</a> tuple construction
+Move to Open pending specific wording to be supplied by Howard.
 </p>
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt
+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>
+Howard is going to write wording.
 </blockquote>
 
 <p><i>[
-2009-07-18 Ganesh updated the proposed wording.
+2009-07-26 Howard provided wording.
 ]</i></p>
 
 
-<blockquote>
-<p>
-Howard:  Moved back to Review.  Note that X [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>
+<p><i>[
+2009-09-13 Niels adds:
+]</i></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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>):
-</p>
-<ul>
-       <li><p>20.8.9.2.1 [unique.ptr.single.ctor] para 3 e 7</p></li>
-       <li><p>24.5.1.2.1 [reverse.iter.cons] para 1</p></li>
-       <li><p>24.5.2.2.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>
+Note: The proposed change of 27.9.1.3 [filebuf.assign]/1 depends on the
+resolution of LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1204">1204</a>, which allows implementations to assume that
+<tt>*this</tt> and <tt>rhs</tt> refer to different objects.
 </blockquote>
 
+<p><i>[
+2009 Santa Cruz:
+]</i></p>
+
+
+<blockquote>
+Leave as Open.  Too closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a> to move on at this time.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
-<p>
-Change X [utility.arg.requirements] para 2:
-</p>
-
-<blockquote>
-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 5:
+Change 27.8.1.2 [stringbuf.assign]/1:
 </p>
 
+<blockquote><pre>basic_stringbuf&amp; operator=(basic_stringbuf&amp;&amp; rhs);
+</pre>
 <blockquote>
-<i>Effects:</i> Constructs a deque with n
-<del>default constructed</del><ins>value-initialized</ins>
-elements. 
+-1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
+<ins>After the move assignment <tt>*this</tt> reflects the same observable
+state it would have if it had been move constructed from <tt>rhs</tt>
+(27.8.1.1 [stringbuf.cons]).
+</ins>
+</blockquote>
 </blockquote>
 
 <p>
-Change 23.3.2.2 [deque.capacity] para 1:
+Change 27.8.2.2 [istringstream.assign]/1:
 </p>
 
+<blockquote><pre>basic_istringstream&amp; operator=(basic_istringstream&amp;&amp; rhs);
+</pre>
 <blockquote>
-<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.
+-1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
+<ins>Move assigns the base and members of <tt>*this</tt> with the respective
+base and members of <tt>rhs</tt>.
+</ins>
+</blockquote>
 </blockquote>
 
 <p>
-Change 23.3.3.1 [forwardlist.cons] para 5:
+Change 27.8.3.2 [ostringstream.assign]/1:
 </p>
 
+<blockquote><pre>basic_ostringstream&amp; operator=(basic_ostringstream&amp;&amp; rhs);
+</pre>
 <blockquote>
-<i>Effects:</i> Constructs a forward_list object with n <del>default
-constructed</del><ins>value-initialized</ins>
-elements.
+-1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
+<ins>Move assigns the base and members of <tt>*this</tt> with the respective
+base and members of <tt>rhs</tt>.
+</ins>
+</blockquote>
 </blockquote>
 
 <p>
-Change 23.3.3.4 [forwardlist.modifiers] para 21:
+Change 27.8.5.1 [stringstream.assign]/1:
 </p>
 
+<blockquote><pre>basic_stringstream&amp; operator=(basic_stringstream&amp;&amp; rhs);
+</pre>
 <blockquote>
-<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.
+-1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
+<ins>Move assigns the base and members of <tt>*this</tt> with the respective
+base and members of <tt>rhs</tt>.
+</ins>
+</blockquote>
 </blockquote>
 
 <p>
-Change 23.3.4.1 [list.cons] para 5:
+Change 27.9.1.3 [filebuf.assign]/1:
 </p>
 
+<blockquote><pre>basic_filebuf&amp; operator=(basic_filebuf&amp;&amp; rhs);
+</pre>
 <blockquote>
-<i>Effects:</i> Constructs a list with n <del>default
-constructed</del><ins>value-initialized</ins>
-elements. 
+-1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
+<ins>Begins by calling <tt>this-&gt;close()</tt>.
+After the move assignment <tt>*this</tt> reflects the same observable
+state it would have if it had been move constructed from <tt>rhs</tt>
+(27.9.1.2 [filebuf.cons]).
+</ins>
+</blockquote>
 </blockquote>
 
 <p>
-Change 23.3.4.2 [list.capacity] para 15:
+Change 27.9.1.8 [ifstream.assign]/1:
 </p>
 
+<blockquote><pre>basic_ifstream&amp; operator=(basic_ifstream&amp;&amp; rhs);
+</pre>
 <blockquote>
-<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.
+-1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
+<ins>Move assigns the base and members of <tt>*this</tt> with the respective
+base and members of <tt>rhs</tt>.</ins>
+</blockquote>
 </blockquote>
 
 <p>
-Change 23.3.6.1 [vector.cons] para 3:
+Change 27.9.1.12 [ofstream.assign]/1:
 </p>
 
+<blockquote><pre>basic_ofstream&amp; operator=(basic_ofstream&amp;&amp; rhs);
+</pre>
 <blockquote>
-<i>Effects:</i> Constructs a vector with n
-<del>default constructed</del><ins>value-initialized</ins>
-elements. 
+-1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
+<ins>Move assigns the base and members of <tt>*this</tt> with the respective
+base and members of <tt>rhs</tt>.</ins>
+</blockquote>
 </blockquote>
 
 <p>
-Change 23.3.6.2 [vector.capacity] para 24:
+Change 27.9.1.16 [fstream.assign]/1:
 </p>
 
+<blockquote><pre>basic_fstream&amp; operator=(basic_fstream&amp;&amp; rhs);
+</pre>
 <blockquote>
-<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.
+-1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
+<ins>Move assigns the base and members of <tt>*this</tt> with the respective
+base and members of <tt>rhs</tt>.</ins>
+</blockquote>
 </blockquote>
 
 
@@ -13549,429 +10912,424 @@ elements to the sequence.
 
 
 <hr>
-<h3><a name="870"></a>870. Do unordered containers not support function pointers for predicate/hasher?</h3>
-<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-17  <b>Last modified:</b> 2009-07-28</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
+<h3><a name="910"></a>910. Effects of MoveAssignable</h3>
+<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-09-29  <b>Last modified:</b> 2009-11-03</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
+<p><b>Addresses UK 150</b></p>
+
 <p>
-Good ol' associative containers allow both function pointers and
-function objects as feasible
-comparators, as described in 23.2.4 [associative.reqmts]/2:
+The description of the effect of <tt>operator=</tt> in the <tt>MoveAssignable</tt>
+concept, given in paragraph 7 is:
 </p>
 
+<blockquote><pre>result_type  T::operator=(T&amp;&amp;  rv);  // inherited from HasAssign&lt;T, T&amp;&amp;&gt;
+</pre>
+
 <blockquote>
-Each associative container is parameterized on <tt>Key</tt> and an ordering
-relation <tt>Compare</tt> that
-induces a strict weak ordering (25.3) on elements of Key. [..]. The
-object of type <tt>Compare</tt> is
-called the comparison object of a container. This comparison object
-may be a pointer to
-function or an object of a type with an appropriate function call operator.[..]
+<i>Postconditions:</i> the constructed <tt>T</tt> object is equivalent to the value of
+<tt>rv</tt> before the assignment. [<i>Note:</i> there is no
+requirement on the value of <tt>rv</tt> after the assignment.  <i>--end note</i>]
+</blockquote>
 </blockquote>
 
 <p>
-The corresponding wording for unordered containers is not so clear,
-but I read it to disallow
-function pointers for the hasher and I miss a clear statement for the
-equality predicate, see
-23.2.5 [unord.req]/3+4+5:
+The sentence contains a typo (what is the "constructed <tt>T</tt> object"?)
+probably due to a cut&amp;paste from <tt>MoveConstructible</tt>. Moreover, the
+discussion of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a> shows that the postcondition is too generic
+and might not reflect the user expectations. An implementation of the
+move assignment that just calls <tt>swap()</tt> would always fulfill the
+postcondition as stated, but might have surprising side-effects in case
+the source rvalue refers to an object that is not going to be
+immediately destroyed. See LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a> for another example. Due to
+the sometimes intangible nature of the "user expectation", it seems
+difficult to have precise normative wording that could cover all cases
+without introducing unnecessary restrictions. However a non-normative
+clarification could be a very helpful warning sign that swapping is not
+always the correct thing to do.
 </p>
 
-<blockquote>
-<p>
-Each unordered associative container is parameterized by <tt>Key</tt>, by a
-function object <tt>Hash</tt> that
-acts as a hash function for 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>.[..]
-</p>
-<p>
-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>.
-</p>
-<p>
-Two values <tt>k1</tt> and <tt>k2</tt> of type <tt>Key</tt> are considered equal if the
-container's equality function object
-returns <tt>true</tt> when passed those values.[..]
-</p>
-</blockquote>
+<p><i>[
+2009-05-09 Alisdair adds:
+]</i></p>
 
-<p>
-and table 97 says in the column "assertion...post-condition" for the
-expression X::hasher:
-</p>
 
 <blockquote>
-<tt>Hash</tt> shall be a unary function object type such that the expression
-<tt>hf(k)</tt> has type <tt>std::size_t</tt>.
-</blockquote>
-
 <p>
-Note that 20.7 [function.objects]/1 defines as "Function objects are
-objects with an <tt>operator()</tt> defined.[..]"
+Issue 910 is exactly the reason BSI advanced the Editorial comment UK-150.
 </p>
 <p>
-Does this restriction exist by design or is it an oversight? If an
-oversight, I suggest that to apply
-the following
+The post-conditions after assignment are at a minimum that the object
+referenced by rv must be safely destructible, and the transaction should not
+leak resources.  Ideally it should be possible to simply assign rv a new
+valid state after the call without invoking undefined behaviour, but any
+other use of the referenced object would depend upon additional guarantees
+made by that type.
 </p>
+</blockquote>
 
 <p><i>[
-2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
+2009-05-09 Howard adds:
 ]</i></p>
 
 
-
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
 <p>
-In 23.2.5 [unord.req]/3, just after the second sentence which is written as
+The intent of the rvalue reference work is that the moved from <tt>rv</tt> is
+a valid object.  Not one in a singular state.  If, for example, the moved from
+object is a <tt>vector</tt>, one should be able to do anything on that moved-from
+<tt>vector</tt> that you can do with any other <tt>vector</tt>.  However you would
+first have to query it to find out what its current state is.  E.g. it might have <tt>capacity</tt>,
+it might not.  It might have a non-zero <tt>size</tt>, it might not.  But regardless,
+you can <tt>push_back</tt> on to it if you want.
 </p>
 
-<blockquote>
-Additionally, <tt>unordered_map</tt> and <tt>unordered_multimap</tt> associate an
-arbitrary mapped type <tt>T</tt> with the <tt>Key</tt>.
-</blockquote>
+<p>
+That being said, most standard code is now conceptized.  That is, the concepts
+list the only operations that can be done with templated types - whether or not
+the values have been moved from.
+</p>
 
 <p>
-add one further sentence:
+Here is user-written code which must be allowed to be legal:
 </p>
+<blockquote><pre>#include &lt;vector&gt;
+#include &lt;cstdio&gt;
 
-<blockquote>
-Both <tt>Hash</tt> and <tt>Pred</tt> may be pointers to function or objects of a type
-with an appropriate function call operator.
-</blockquote>
+template &lt;class Allocator&gt;
+void
+inspect(std::vector&lt;double, Allocator&gt;&amp;&amp; v)
+{
+    std::vector&lt;double, Allocator&gt; result(move(v));
+    std::printf("moved from vector has %u size and %u capacity\n", v.size(), v.capacity());
+    std::printf("The contents of the vector are:\n");
+    typedef typename std::vector&lt;double, Allocator&gt;::iterator I;
+    for (I i = v.begin(), e = v.end(); i != e; ++i)
+        printf("%f\n", *i);
+}
+
+int main()
+{
+    std::vector&lt;double&gt; v1(100, 5.5);
+    inspect(move(v1));
+}
+</pre></blockquote>
 
 <p>
-[Note1: Since the detailed requirements for <tt>Pred</tt> and <tt>Hash</tt> are given in
-p.4 and p.5, it an alternative resolution
-would be to insert a new paragraph just after p.5, which contains the
-above proposed sentence]
+The above program does not treat the moved-from <tt>vector</tt> as singular.  It
+only treats it as a <tt>vector</tt> with an unknown value.
 </p>
 <p>
-[Note2: I do not propose a change of above quoted element in table 97,
-because the mis-usage of the
-notion of "function object" seems already present in the standard at
-several places, even if it includes
-function pointers, see e.g. 25 [algorithms]/7. The important point is
-that in those places a statement is
-given that the actually used symbol, like "Predicate" applies for
-function pointers as well]
+I believe the current proposed wording is consistent with my view on this.
 </p>
+</blockquote>
 
-
-<p><b>Rationale:</b></p>
 <p><i>[
-San Francisco:
+Batavia (2009-05):
 ]</i></p>
 
-
 <blockquote>
-This is fixed by
-<a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
+We agree that the proposed resolution
+is an improvement over the current wording.
 </blockquote>
 
+<p><i>[
+2009-07 Frankfurt:
+]</i></p>
 
 
-
-
-
-<hr>
-<h3><a name="871"></a>871. Iota's requirements on T are too strong</h3>
-<p><b>Section:</b> 26.7.5 [numeric.iota] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-20  <b>Last modified:</b> 2009-07-30</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-According to the recent WP
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>,
-26.7.5 [numeric.iota]/1, the requires clause
-of <tt>std::iota</tt> says:
-</p>
-
 <blockquote>
-<tt>T</tt> shall meet the requirements of <tt>CopyConstructible</tt> and <tt>Assignable</tt> types, and
-shall be convertible to <tt>ForwardIterator</tt>'s value type.[..]
+Need to look at again without concepts.
 </blockquote>
 
-<p>
-Neither <tt>CopyConstructible</tt> nor <tt>Assignable</tt> is needed, instead <tt>MoveConstructible</tt>
-seems to be the correct choice. I guess the current wording resulted as an
-artifact from comparing it with similar numerical algorithms like <tt>accumulate</tt>.
-</p>
-
-<p>
-Note: If this function will be conceptualized, the here proposed
-<tt>MoveConstructible</tt>
-requirement can be removed, because this is an implied requirement of
-function arguments, see
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2710.pdf">N2710</a>/[temp.req.impl]/3, last bullet.
-</p>
-
 <p><i>[
-post San Francisco:
+2009-07 Frankfurt:
 ]</i></p>
 
 
 <blockquote>
-Issue pulled by author prior to review.
+Walter will consult with Dave and Doug.
 </blockquote>
 
 <p><i>[
-2009-07-30 Daniel reopened:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-with the absence of concepts, this issue (closed) is valid again and I
-suggest to reopen it.
-I also revised by proposed resolution based on N2723 wording:
+We believe this is handled by the resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1204">1204</a>,
+but there is to much going on in this area to be sure.  Defer for now.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change the first sentence of 26.7.5 [numeric.iota]/1:
+In  [concept.copymove], replace the postcondition in paragraph 7 with:
 </p>
 
 <blockquote>
-<i>Requires:</i> <tt>T</tt> shall <del>meet the requirements of <tt>CopyConstructible</tt> and
-<tt>Assignable</tt> types, and shall</del> be
-convertible to <tt>ForwardIterator</tt>'s value type. [..]
-</blockquote>
-
-
-
+<i>Postconditions:</i> <tt>*this</tt> is equivalent to the value of <tt>rv</tt> before the
+assignment. [<i>Note:</i> there is no requirement on the value of <tt>rv</tt> after the
+assignment, but the
+effect should be unsurprising to the user even in case <tt>rv</tt> is not
+immediately destroyed. This may require that resources previously owned
+by <tt>*this</tt> are released instead of transferred to <tt>rv</tt>. <i>-- end note</i>]
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="872"></a>872. <tt>move_iterator::operator[]</tt> has wrong return type</h3>
-<p><b>Section:</b> 24.5.2.2.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2008-08-21  <b>Last modified:</b> 2009-07-28</p>
+<h3><a name="911"></a>911. I/O streams and <tt>move/swap</tt> semantic</h3>
+<p><b>Section:</b> 27.7.1 [input.streams], 27.7.2 [output.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-09-29  <b>Last modified:</b> 2009-10-20</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-<tt>move_iterator</tt>'s <tt>operator[]</tt> is declared as:
+Class template <tt>basic_istream</tt>, <tt>basic_ostream</tt> and <tt>basic_iostream</tt>
+implements public move constructors, move assignment operators and <tt>swap</tt>
+method and free functions. This might induce both the user and the
+compiler to think that those types are <tt>MoveConstructible</tt>, <tt>MoveAssignable</tt>
+and <tt>Swappable</tt>. However, those class templates fail to fulfill the user
+expectations. For example:
 </p>
 
-<blockquote><pre>reference operator[](difference_type n) const;
+<blockquote><pre>std::ostream os(std::ofstream("file.txt"));
+assert(os.rdbuf() == 0); // buffer object is not moved to os, file.txt has been closed
+
+std::vector&lt;std::ostream&gt; v;
+v.push_back(std::ofstream("file.txt"));
+v.reserve(100); // causes reallocation
+assert(v[0].rdbuf() == 0); // file.txt has been closed!
+
+std::ostream&amp;&amp; os1 = std::ofstream("file1.txt");
+os1 = std::ofstream("file2.txt");
+os1 &lt;&lt; "hello, world"; // still writes to file1.txt, not to file2.txt!
+
+std::ostream&amp;&amp; os1 = std::ofstream("file1.txt");
+std::ostream&amp;&amp; os2 = std::ofstream("file2.txt");
+std::swap(os1, os2);
+os1 &lt;&lt; "hello, world"; // writes to file1.txt, not to file2.txt!
 </pre></blockquote>
 
 <p>
-This has the same problem that <tt>reverse_iterator</tt>'s <tt>operator[]</tt> used to
-have: if the underlying iterator's <tt>operator[]</tt> returns a proxy, the
-implicit conversion to <tt>value_type&amp;&amp;</tt> could end up referencing a temporary
-that has already been destroyed. This is essentially the same issue that
-we dealt with for <tt>reverse_iterator</tt> in DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>.
+This is because the move constructor, the move assignment operator and
+<tt>swap</tt> are all implemented through calls to <tt>std::basic_ios</tt> member
+functions <tt>move()</tt> and <tt>swap()</tt> that do not move nor swap the controlled
+stream buffers. That can't happen because the stream buffers may have
+different types.
+</p>
+
+<p>
+Notice that for <tt>basic_streambuf</tt>, the member function <tt>swap()</tt> is
+protected. I believe that is correct and all of <tt>basic_istream</tt>,
+<tt>basic_ostream</tt>, <tt>basic_iostream</tt> should do the same as the move ctor, move
+assignment operator and swap member function are needed by the derived
+<tt>fstream</tt>s and <tt>stringstream</tt>s template. The free swap functions for
+<tt>basic_(i|o|io)stream</tt> templates should be removed for the same reason.
 </p>
 
 <p><i>[
-2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
+Batavia (2009-05):
 ]</i></p>
 
-
-
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
 <p>
-In 24.5.2.1 [move.iterator] and 24.5.2.2.12 [move.iter.op.index], change the declaration of
-<tt>move_iterator</tt>'s <tt>operator[]</tt> to:
+We note that the rvalue swap functions have already been removed.
 </p>
+<p>
+Bill is unsure about making the affected functions protected;
+he believes they may need to be public.
+</p>
+<p>
+We are also unsure about removing the lvalue swap functions as proposed.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
 
-<blockquote><pre><del>reference</del> <ins><i>unspecified</i></ins> operator[](difference_type n) const;
-</pre></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
 <p><i>[
-San Francisco:
+2009-07 Frankfurt:
 ]</i></p>
 
 
 <blockquote>
-NAD Editorial, see
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2777.pdf">N2777</a>.
+<p>
+It's not clear that the use case is compelling.
+</p>
+<p>
+Howard: This needs to be implemented and tested.
+</p>
 </blockquote>
 
+<p><i>[
+2009-07-26 Howard adds:
+]</i></p>
 
 
-
-<hr>
-<h3><a name="876"></a>876. <tt>basic_string</tt> access operations should give stronger guarantees</h3>
-<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-22  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-During the Sophia Antipolis meeting it was decided to split-off some
-parts of the
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2647.html">n2647</a>
-("Concurrency modifications for <tt>basic_string</tt>")
-proposal into a separate issue, because these weren't actually
-concurrency-related. The here proposed changes refer to the recent
-update document
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm">n2668</a>
-and attempt to take advantage of the
-stricter structural requirements.
-</p>
+<blockquote>
 <p>
-Indeed there exists some leeway for more guarantees that would be
-very useful for programmers, especially if interaction with transactionary
-or exception-unaware C API code is important. This would also allow
-compilers to take advantage of more performance optimizations, because
-more functions can have throw() specifications. This proposal uses the
-form of "Throws: Nothing" clauses to reach the same effect, because
-there already exists a different issue in progress to clean-up the current
-existing "schizophrenia" of the standard in this regard.
+I started out thinking I would recommend NAD for this one.  I've turned around
+to agree with the proposed resolution (which I've updated to the current draft).
+I did not fully understand Ganesh's rationale, and attempt to describe my
+improved understanding below.
 </p>
+
 <p>
-Due to earlier support for copy-on-write, we find the following
-unnecessary limitations for C++0x:
+The move constructor, move assignment operator, and swap function are different
+for <tt>basic_istream</tt>, <tt>basic_ostream</tt> and <tt>basic_iostream</tt>
+than other classes.  A timely conversation with Daniel reminded me of this long
+forgotten fact.  These members are sufficiently different that they would be
+extremely confusing to use in general, but they are very much needed for derived
+clients.
 </p>
 
-<ol>
+<ul>
 <li>
-Missing no-throw guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
-a pointer to their guts, which is a non-failure operation. This should
-be spelled out. It is also noteworthy to mention that the same
-guarantees should also be given by the size query functions,
-because the combination of pointer to content and the length is
-typically needed during interaction with low-level API.
+The move constructor moves everything but the <tt>rdbuf</tt> pointer.
 </li>
 <li>
-Missing complexity guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
-a pointer to their guts, which is guaranteed O(1). This should be
-spelled out.
+The move assignment operator moves everything but the <tt>rdbuf</tt> pointer.
 </li>
 <li>
-Missing reading access to the terminating character: Only the
-const overload of <tt>operator[]</tt> allows reading access to the terminator
-char. For more intuitive usage of strings, reading access to this
-position should be extended to the non-const case. In contrast
-to C++03 this reading access should now be homogeneously
-an lvalue access.
+The swap function swaps everything but the <tt>rdbuf</tt> pointer.
 </li>
-</ol>
+</ul>
 
 <p>
-The proposed resolution is split into a main part (A) and a
-secondary part (B) (earlier called "Adjunct Adjunct Proposal").
-(B) extends (A) by also making access to index position
-size() of the at() overloads a no-throw operation. This was
-separated, because this part is theoretically observable in
-specifically designed test programs.
+The reason for this behavior is that for the std-derived classes (stringstreams,
+filestreams), the <tt>rdbuf</tt> pointer points back into the class itself
+(self referencing).  It can't be swapped or moved.  But this fact isn't born out
+at the <tt>stream</tt> level.  Rather it is born out at the <tt>fstream</tt>/<tt>sstream</tt>
+level.  And the lower levels just need to deal with that fact by not messing around
+with the <tt>rdbuf</tt> pointer which is stored down at the lower levels.
 </p>
 
-<p><i>[
-San Francisco:
-]</i></p>
-
-
-<blockquote>
-<p>
-We oppose part 1 of the issue but hope to address <tt>size()</tt> in
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>.
-</p>
-<p>
-We do not support part B. 4 of the issue because of the breaking API change.
-</p>
 <p>
-We support part A. 2 of the issue.
+In a nutshell, it is very confusing for all of those who are not so intimately
+related with streams that they've implemented them.  And it is even fairly
+confusing for some of those who have (including myself).  I do not think it is
+safe to swap or move <tt>istreams</tt> or <tt>ostreams</tt> because this will
+(by necessary design) separate stream state from streambuffer state.  Derived
+classes (such as <tt>fstream</tt> and <tt>stringstream</tt> must be used to
+keep the stream state and stream buffer consistently packaged as one unit during
+a move or swap.
 </p>
+
 <p>
-On support part A. 3 of the issue:
+I've implemented this proposal and am living with it day to day.
 </p>
-<blockquote>
-Pete's broader comment: now that we know that basic_string will be a
-block of contiguous memory, we should just rewrite its specification
-with that in mind. The expression of the specification will be simpler
-and probably more correct as a result.
-</blockquote>
+
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt
+2009 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-<p>
-Move proposed resolution A to Ready.
-</p>
-<p><i>[
-Howard: Commented out part B.
-]</i></p>
-
+Leave Open.  Pablo expected to propose alternative wording which would rename
+move construction, move assignment and swap, and may or may not make them
+protected.  This will impact issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
-<ol type="A">
-<li>
-<ol>
-<li>
-<p>In 21.4.4 [string.capacity], just after p. 1 add a new paragraph:
-</p>
-<blockquote>
-<i>Throws:</i> Nothing.
-</blockquote>
-
-</li>
-<li>
 <p>
-In 21.4.5 [string.access] <em>replace</em> p. 1 by the following <em>4</em> paragraghs:
+27.7.1.1 [istream]: make the following member functions protected:
 </p>
 
-<blockquote>
+<blockquote><pre>basic_istream(basic_istream&amp;&amp;  rhs);
+basic_istream&amp;  operator=(basic_istream&amp;&amp;  rhs);
+void  swap(basic_istream&amp;  rhs);
+</pre></blockquote>
+
 <p>
-<i>Requires:</i> <tt>pos &#8804; size()</tt>.
+Ditto: remove the swap free function signature
 </p>
+
+<blockquote><pre><del>// swap: 
+template &lt;class charT, class traits&gt; 
+  void swap(basic_istream&lt;charT, traits&gt;&amp; x, basic_istream&lt;charT, traits&gt;&amp; y);</del>
+</pre></blockquote>
+
 <p>
-<i>Returns:</i> If <tt>pos &lt; size()</tt>, returns <tt>*(begin() + pos)</tt>. Otherwise, returns
-a reference to a <tt>charT()</tt> that shall not be modified.
+27.7.1.1.2 [istream.assign]: remove paragraph 4
 </p>
+
+<blockquote><pre><del>template &lt;class charT, class traits&gt; 
+  void swap(basic_istream&lt;charT, traits&gt;&amp; x, basic_istream&lt;charT, traits&gt;&amp; y);</del>
+</pre>
+<blockquote>
+<del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
+</blockquote>
+</blockquote>
+
 <p>
-<i>Throws:</i> Nothing.
+27.7.1.5 [iostreamclass]: make the following member function protected:
 </p>
+
+<blockquote><pre>basic_iostream(basic_iostream&amp;&amp;  rhs);
+basic_iostream&amp;  operator=(basic_iostream&amp;&amp;  rhs);
+void  swap(basic_iostream&amp;  rhs);
+</pre></blockquote>
+
 <p>
-<i>Complexity:</i> Constant time.
+Ditto: remove the swap free function signature
 </p>
-</blockquote>
 
-</li>
-<li>
+<blockquote><pre><del>template &lt;class charT, class traits&gt; 
+  void swap(basic_iostream&lt;charT, traits&gt;&amp; x, basic_iostream&lt;charT, traits&gt;&amp; y);</del>
+</pre></blockquote>
+
 <p>
-In 21.4.7.1 [string.accessors] replace the now <em>common</em> returns
-clause of <tt>c_str()</tt> and <tt>data()</tt> by the following <em>three</em> paragraphs:
+27.7.1.5.3 [iostream.assign]: remove paragraph 3
 </p>
+
+<blockquote><pre><del>template &lt;class charT, class traits&gt; 
+  void swap(basic_iostream&lt;charT, traits&gt;&amp; x, basic_iostream&lt;charT, traits&gt;&amp; y);</del>
+</pre>
 <blockquote>
+<del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
+</blockquote>
+</blockquote>
+
 <p>
-<i>Returns:</i> A pointer <tt>p</tt> such that <tt>p+i == &amp;operator[](i)</tt> for each <tt>i</tt>
-in <tt>[0, size()]</tt>.
+27.7.2.1 [ostream]: make the following member function protected:
 </p>
+
+<blockquote><pre>basic_ostream(basic_ostream&amp;&amp;  rhs);
+basic_ostream&amp;  operator=(basic_ostream&amp;&amp;  rhs);
+void  swap(basic_ostream&amp;  rhs);
+</pre></blockquote>
+
 <p>
-<i>Throws:</i> Nothing.
+Ditto: remove the swap free function signature
 </p>
+
+<blockquote><pre><del>// swap: 
+template &lt;class charT, class traits&gt; 
+  void swap(basic_ostream&lt;charT, traits&gt;&amp; x, basic_ostream&lt;charT, traits&gt;&amp; y);</del>
+</pre></blockquote>
+
 <p>
-<i>Complexity:</i> Constant time.
+27.7.2.3 [ostream.assign]: remove paragraph 4 
 </p>
-</blockquote>
-</li>
-</ol>
-</li>
 
-</ol>
+<blockquote><pre><del>template &lt;class charT, class traits&gt; 
+  void swap(basic_ostream&lt;charT, traits&gt;&amp; x, basic_ostream&lt;charT, traits&gt;&amp; y);</del>
+</pre>
+<blockquote>
+<del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
+</blockquote>
+</blockquote>
 
 
 
@@ -13979,210 +11337,293 @@ in <tt>[0, size()]</tt>.
 
 
 <hr>
-<h3><a name="879"></a>879. Atomic load const qualification</h3>
-<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alexander Chemeris <b>Opened:</b> 2008-08-24  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
+<h3><a name="915"></a>915. <tt>minmax</tt> with <tt>initializer_list</tt> should return
+<tt>pair</tt> of <tt>T</tt>, not <tt>pair</tt> of <tt>const T&amp;</tt></h3>
+<p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The <tt>atomic_address</tt> type and <tt>atomic&lt;T*&gt;</tt> specialization provide atomic
-updates to pointers.  However, the current specification requires
-that the types pointer be to non-const objects.  This restriction
-is unnecessary and unintended.
+It seems that the proposed changes for
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2772.pdf">N2772</a>
+were not clear enough in
+this point:
 </p>
 
-<p><i>[
-Summit:
-]</i></p>
-
 <blockquote>
-Move to review.  Lawrence will first check with Peter whether the
-current examples are sufficient, or whether they need to be expanded to
-include all cases.
-</blockquote>
-
+25.4.7 [alg.min.max], before p.23 + p.24 + before p. 27 + p. 28 say that the return
+type of the <tt>minmax</tt> overloads with an <tt>initializer_list</tt> is
+<tt>pair&lt;const T&amp;, const T&amp;&gt;</tt>,
+which is inconsistent with the decision for the other <tt>min/max</tt> overloads which take
+a <tt>initializer_list</tt> as argument and return a <tt>T</tt>, not a <tt>const T&amp;</tt>.
+Doing otherwise for <tt>minmax</tt> would easily lead to unexpected life-time
+problems by using <tt>minmax</tt> instead of <tt>min</tt> and <tt>max</tt> separately.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
 <p><i>[
 2009-07 Frankfurt
 ]</i></p>
 
 
 <blockquote>
-<p>
-Lawrence will handle all issues relating to atomics in a single paper.
-</p>
-<p>
-LWG will defer discussion on atomics until that paper appears.
-</p>
-<p>
-Move to Open.
-</p>
+Moved from Tentatively Ready to Open only because the wording needs to be
+tweaked for concepts removal.
 </blockquote>
 
+<p><i>[
+2009-08-18 Daniel adds:
+]</i></p>
 
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Add const qualification to the pointer values of the <tt>atomic_address</tt>
-and <tt>atomic&lt;T*&gt;</tt> specializations.  E.g.
-</p>
-
-<blockquote><pre>typedef struct atomic_address {
-   void store(<ins>const</ins> void*, memory_order = memory_order_seq_cst) volatile;
-   void* exchange( <ins>const</ins> void*, memory_order = memory_order_seq_cst) volatile;
-   bool compare_exchange( <ins>const</ins> void*&amp;, <ins>const</ins> void*,
-                          memory_order, memory_order) volatile;
-   bool compare_exchange( <ins>const</ins> void*&amp;, <ins>const</ins> void*,
-                          memory_order = memory_order_seq_cst ) volatile;
-   void* operator=(<ins>const</ins> void*) volatile;
-} atomic_address;
-
-void atomic_store(volatile atomic_address*, <ins>const</ins> void*);
-void atomic_store_explicit(volatile atomic_address*, <ins>const</ins> void*,
-                          memory_order);
-void* atomic_exchange(volatile atomic_address*<ins>, const void*</ins>);
-void* atomic_exchange_explicit(volatile atomic_address*, <ins>const</ins> void*,
-                              memory_order);
-bool atomic_compare_exchange(volatile atomic_address*,
-                            <ins>const</ins> void**, <ins>const</ins> void*);
-bool atomic_compare_exchange_explicit(volatile atomic_address*,
-                                     <ins>const</ins> void**, <ins>const</ins> void*,
-                                     memory_order, memory_order);
-</pre></blockquote>
+<blockquote>
+Recommend NAD since the proposed changes have already been performed
+as part of editorial work of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>.
+</blockquote>
 
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
 
+<blockquote>
+Can't find initializer_list form of minmax anymore, only variadic
+version. Seems like we had an editing clash with concepts. Leave Open,
+at least until editorial issues resolved. Bring this to Editor's
+attention.
+</blockquote>
 
 
-<hr>
-<h3><a name="880"></a>880. Missing atomic exchange parameter</h3>
-<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-08-24  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a></p>
-<p><b>Discussion:</b></p>
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
 <p>
-The <tt>atomic_exchange</tt> and <tt>atomic_exchange_explicit</tt> functions seem to
-be inconsistently missing parameters.
+In 25 [algorithms]/2, header <tt>&lt;algorithm&gt;</tt> synopsis change as indicated:
 </p>
 
-<p><i>[
-Post Summit:
-]</i></p>
-
+<blockquote><pre>template&lt;<del>class</del><ins>LessThanComparable</ins> T&gt;
+<ins>requires CopyConstructible&lt;T&gt;</ins>
+pair&lt;<del>const </del>T<del>&amp;</del>, <del>const </del>T<del>&amp;</del>&gt;
+minmax(initializer_list&lt;T&gt; t);
 
-<blockquote>
+template&lt;class T, <del>class</del><ins>StrictWeakOrder&lt;auto, T&gt;</ins> Compare&gt;
+<ins>requires CopyConstructible&lt;T&gt;</ins>
+pair&lt;<del>const </del>T<del>&amp;</del>, <del>const </del>T<del>&amp;</del>&gt;
+minmax(initializer_list&lt;T&gt; t, Compare comp);
+</pre></blockquote>
+</li>
+<li>
 <p>
-Lawrence: Need to write up a list for Pete with details.
+In 25.4.7 [alg.min.max] change as indicated (Begin: Just before p.20):
 </p>
+<blockquote><pre>template&lt;<del>class</del><ins>LessThanComparable</ins> T&gt;
+  <ins>requires CopyConstructible&lt;T&gt;</ins>
+  pair&lt;<del>const </del>T<del>&amp;</del>, <del>const </del>T<del>&amp;</del>&gt;
+  minmax(initializer_list&lt;T&gt; t);
+</pre>
+<blockquote>
 <p>
-Detlef: Should not be New, we already talked about in Concurrency group.
+<del>-20- <i>Requires:</i> <tt>T</tt> is <tt>LessThanComparable</tt> and
+<tt>CopyConstructible</tt>.</del>
 </p>
 <p>
-Recommend Open.
+-21- <i>Returns:</i> <tt>pair&lt;<del>const </del>T<del>&amp;</del>, <del>const
+</del>T<del>&amp;</del>&gt;(x, y)</tt> where <tt>x</tt> is the
+smallest value and <tt>y</tt> the largest value in the <tt>initializer_list</tt>.
 </p>
 </blockquote>
 
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
-
+<p>[..]</p>
+<pre>template&lt;class T, <del>class</del><ins>StrictWeakOrder&lt;auto, T&gt;</ins> Compare&gt;
+  <ins>requires CopyConstructible&lt;T&gt;</ins>
+  pair&lt;<del>const </del>T<del>&amp;</del>, <del>const </del>T<del>&amp;</del>&gt;
+  minmax(initializer_list&lt;T&gt; t, Compare comp);
+</pre>
 
 <blockquote>
 <p>
-Lawrence will handle all issues relating to atomics in a single paper.
-</p>
-<p>
-LWG will defer discussion on atomics until that paper appears.
+<del>-24- <i>Requires:</i> type <tt>T</tt> is <tt>LessThanComparable</tt> and <tt>CopyConstructible</tt>.</del>
 </p>
 <p>
-Move to Open.
+-25- <i>Returns:</i> <tt>pair&lt;<del>const </del>T<del>&amp;</del>, <del>const
+</del>T<del>&amp;</del>&gt;(x, y)</tt> where <tt>x</tt> is the
+smallest value and <tt>y</tt> largest value in the <tt>initializer_list</tt>.
 </p>
 </blockquote>
+</blockquote>
+</li>
+</ol>
 
 
 
-<p><b>Proposed resolution:</b></p>
+
+
+
+<hr>
+<h3><a name="920"></a>920. Ref-qualification support in the library</h3>
+<p><b>Section:</b> 20.7.14 [func.memfn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Bronek Kozicki <b>Opened:</b> 2008-10-06  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.memfn">issues</a> in [func.memfn].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1230">1230</a></p>
+<p><b>Discussion:</b></p>
 <p>
-Add the appropriate parameters.  For example,
+Daniel Krügler wrote:
 </p>
 
-<blockquote><pre>bool atomic_exchange(volatile atomic_bool*<ins>, bool</ins>);
-bool atomic_exchange_explicit(volatile atomic_bool*, bool<ins>, memory_order</ins>);
+<blockquote>
+<p>
+Shouldn't above list be completed for &amp;- and &amp;&amp;-qualified
+member functions This would cause to add:
+</p>
+<blockquote><pre>template&lt;Returnable R, class T, CopyConstructible... Args&gt;
+unspecified mem_fn(R (T::* pm)(Args...) &amp;);
+template&lt;Returnable R, class T, CopyConstructible... Args&gt;
+unspecified mem_fn(R (T::* pm)(Args...) const &amp;);
+template&lt;Returnable R, class T, CopyConstructible... Args&gt;
+unspecified mem_fn(R (T::* pm)(Args...) volatile &amp;);
+template&lt;Returnable R, class T, CopyConstructible... Args&gt;
+unspecified mem_fn(R (T::* pm)(Args...) const volatile &amp;);
+template&lt;Returnable R, class T, CopyConstructible... Args&gt;
+unspecified mem_fn(R (T::* pm)(Args...) &amp;&amp;);
+template&lt;Returnable R, class T, CopyConstructible... Args&gt;
+unspecified mem_fn(R (T::* pm)(Args...) const &amp;&amp;);
+template&lt;Returnable R, class T, CopyConstructible... Args&gt;
+unspecified mem_fn(R (T::* pm)(Args...) volatile &amp;&amp;);
+template&lt;Returnable R, class T, CopyConstructible... Args&gt;
+unspecified mem_fn(R (T::* pm)(Args...) const volatile &amp;&amp;);
 </pre></blockquote>
 
+</blockquote>
+
+<p>
+yes, absolutely. Thanks for spotting this. Without this change <tt>mem_fn</tt>
+cannot be initialized from pointer to ref-qualified member function. I
+believe semantics of such function pointer is well defined.
+</p>
 
+<p><i>[
+Post Summit Daniel provided wording.
+]</i></p>
 
 
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
-<hr>
-<h3><a name="881"></a>881. shared_ptr conversion issue</h3>
-<p><b>Section:</b> 20.8.10.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-08-30  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
+<blockquote>
+<p>
+We need to think about whether we really want to go down the proposed path
+of combinatorial explosion.
+Perhaps a Note would suffice.
+</p>
+<p>
+We would really like to have an implementation before proceeding.
+</p>
 <p>
-We've changed <tt>shared_ptr&lt;Y&gt;</tt> to not convert to <tt>shared_ptr&lt;T&gt;</tt> when <tt>Y*</tt>
-doesn't convert to <tt>T*</tt> by resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>. This only fixed the
-converting copy constructor though.
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
-later added move support, and
-the converting move constructor is not constrained.
+Move to Open, and recommend this be deferred until after the next
+Committee Draft has been issued.
 </p>
+</blockquote>
 
 <p><i>[
-San Francisco:
+2009-10-10 Daniel updated wording to post-concepts.
 ]</i></p>
 
 
 <blockquote>
-We might be able to move this to NAD, Editorial once shared_ptr is
-conceptualized, but we want to revisit this issue to make sure.
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1230">1230</a> has a similar proposed resolution
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
+Move to Ready.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
 <p>
-Moved to Ready.
+Change 20.7 [function.objects]/2, header
+<tt>&lt;functional&gt;</tt> synopsis as follows:
 </p>
+
+<blockquote><pre>// 20.7.14, member function adaptors:
+template&lt;class R, class T&gt; <i>unspecified</i> mem_fn(R T::*);
+
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...));</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const);</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) volatile);</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile);</ins>
+
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) &amp;);</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const &amp;);</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) volatile &amp;);</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile &amp;);</ins>
+
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) &amp;&amp;);</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const &amp;&amp;);</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) volatile &amp;&amp;);</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile &amp;&amp;);</ins>
+</pre></blockquote>
+</li>
+
+<li>
 <p>
-This issue now represents the favored format for specifying constrained templates.
+Change the prototype list of 20.7.14 [func.memfn] as follows [NB: The
+following text, most notably p.2 and p.3 which
+discuss influence of the cv-qualification on the definition of the
+base class's first template parameter remains
+unchanged. ]:
 </p>
-</blockquote>
 
+<blockquote><pre>template&lt;class R, class T&gt; <i>unspecified</i> mem_fn(R T::* pm);
 
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...));</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const);</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile);</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile);</ins>
 
-<p><b>Proposed resolution:</b></p>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &amp;);</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &amp;);</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &amp;);</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &amp;);</ins>
+
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &amp;&amp;);</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &amp;&amp;);</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &amp;&amp;);</ins>
+<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &amp;&amp;);</ins>
+</pre></blockquote>
+</li>
+
+<li>
 <p>
-We need to change the Requires clause of the move constructor:
+Remove 20.7.14 [func.memfn]/5:
 </p>
 
-<blockquote><pre>shared_ptr(shared_ptr&amp;&amp; r); 
-template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt;&amp;&amp; r); 
-</pre>
 <blockquote>
-<i><del>Requires</del> <ins>Remarks</ins>:</i> <del>For the second constructor <tt>Y*</tt> shall be
-convertible to <tt>T*</tt>.</del>
-<ins>
-The second constructor shall not participate in overload resolution
-unless <tt>Y*</tt> is convertible to <tt>T*</tt>.
-</ins>
+<del><i>Remarks:</i> Implementations may implement <tt>mem_fn</tt> as a set of
+overloaded function templates.</del>
 </blockquote>
-</blockquote>
-
-<p>
-in order to actually make the example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a> compile
-(it now resolves to the move constructor).
-</p>
+</li>
+</ol>
 
 
 
@@ -14190,728 +11631,703 @@ in order to actually make the example in <a href="http://www.open-std.org/jtc1/s
 
 
 <hr>
-<h3><a name="883"></a>883. swap circular definition</h3>
-<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-10  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
+<h3><a name="921"></a>921. Rational Arithmetic should use template aliases</h3>
+<p><b>Section:</b> 20.4.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2008-10-07  <b>Last modified:</b> 2009-10-21</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.ratio">issues</a> in [ratio.ratio].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
+<p>
+The compile-time functions that operate on <tt>ratio&lt;N,D&gt;</tt> require the
+cumbersome and error-prone "evaluation" of a <tt>type</tt> member using a
+meta-programming style that predates the invention of template aliases.
+Thus, multiplying three ratios <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> requires the expression:
+</p>
+
+<blockquote><pre>ratio_multiply&lt;a, ratio_multiply&lt;b, c&gt;::type&gt;::type
+</pre></blockquote>
 
 <p>
-Note in particular that Table 90 "Container Requirements" gives
-semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>, yet for all
-containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a
-circular definition.
+The simpler expression:
+</p>
+
+<blockquote><pre>ratio_multiply&lt;a, ratio_multiply&lt;b, c&gt;&gt;
+</pre></blockquote>
+
+<p>
+Could be used by if template aliases were employed in the definitions.
 </p>
 
 <p><i>[
-San Francisco:
+Post Summit:
 ]</i></p>
 
 
 <blockquote>
-Robert to propose a resolution along the lines of "Postcondition: "a =
-b, b = a" This will be a little tricky for the hash containers, since
-they don't have <tt>operator==</tt>.
+<p>
+Jens: not a complete proposed resolution: "would need to make similar change"
+</p>
+<p>
+Consensus: We agree with the direction of the issue.
+</p>
+<p>
+Recommend Open.
+</p>
 </blockquote>
 
 <p><i>[
-Post Summit Anthony Williams provided proposed wording.
-]</i></p>
-
-
-<p><i>[
-2009-07 Frankfurt
+2009-05-11 Daniel adds:
 ]</i></p>
 
 
 <blockquote>
-Moved to Ready with minor edits (which have been made).
+<p>
+Personally I'm <em>not</em> in favor for the addition of:
+</p>
+<blockquote><pre>typedef ratio type;
+</pre></blockquote>
+<p>
+For a reader of the
+standard it's usage or purpose is unclear. I haven't seen similar examples
+of attempts to satisfy non-feature complete compilers.
+</p>
 </blockquote>
 
+<p><i>[
+2009-05-11 Pablo adds:
+]</i></p>
 
 
-<p><b>Proposed resolution:</b></p>
+<blockquote>
 <p>
-In table 80 in section 23.2.1 [container.requirements.general],
-replace the postcondition of <tt>a.swap(b)</tt> with the following:
+The addition of type to the <tt>ratio</tt> template allows the previous style
+(i.e., in the prototype implementations) to remain valid and permits the
+use of transitional library implementations for C++03 compilers.  I do
+not feel strongly about its inclusion, however, and leave it up to the
+reviewers to decide.
 </p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
 <blockquote>
-<table border="1">
-<caption>Table 80 -- Container requirements</caption>
-<tbody><tr>
-<th>Expression</th>
-<th>Return type</th>
-<th>Operational semantics</th>
-<th>Assertion/note pre-/post-conidtion</th>
-<th>Complexity</th>
-</tr>
-<tr>
-<td>...</td>
-<td>...</td>
-<td>...</td>
-<td>...</td>
-<td>...</td>
-</tr>
-<tr>
-<td><tt>a.swap(b);</tt></td>
-<td><tt>void</tt></td>
-<td>&nbsp;</td>
-<td><del><tt>swap(a,b)</tt></del>
-<ins>Exchange the contents of <tt>a</tt> and <tt>b</tt>.</ins></td>
-<td>(Note A)</td>
-</tr>
-</tbody></table>
+Bill asks for additional discussion in the issue
+that spells out more details of the implementation.
+Howard points us to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>
+which has at least most of the requested details.
+Tom is strongly in favor of overflow-checking at compile time.
+Pete points out that there is no change of functionality implied.
+We agree with the proposed resolution,
+but recommend moving the issue to Review
+to allow time to improve the discussion if needed.
 </blockquote>
 
-<p>
-Remove the reference to swap from the paragraph following the table.
-</p>
+<p><i>[
+2009-07-21 Alisdair adds:
+]</i></p>
+
 
 <blockquote>
-Notes: the algorithms <del><tt>swap()</tt>, </del><tt>equal()</tt> and
-<tt>lexicographical_compare()</tt> are defined in Clause 25. ...
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1121">1121</a> for a potentially incompatible proposal.
 </blockquote>
 
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
 
+<blockquote>
+Move to Ready.
+</blockquote>
 
 
 
-<hr>
-<h3><a name="885"></a>885. pair assignment</h3>
-<p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<blockquote><pre>20.2.3 pairs
-Missing assignemnt operator:
-template&lt;class U , class V&gt;
-  requires CopyAssignable&lt;T1, U&gt; &amp;&amp; CopyAssignable&lt;T2, V&gt;
-    pair&amp; operator=(pair&lt;U , V&gt; const &amp; p );
-</pre></blockquote>
+<p><b>Proposed resolution:</b></p>
 
+ 
+ <ol start="0">
+<li>
 <p>
-Well, that's interesting. This assignment operator isn't in the
-current working paper, either. Perhaps we deemed it acceptable to
-build a temporary of type <tt>pair</tt> from <tt>pair&lt;U, V&gt;</tt>, then move-assign
-from that temporary?
+In 20.4 [ratio]/3 change as indicated:
+</p>
+
+<blockquote><pre>// ratio arithmetic
+template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_add<ins> = <em>see below</em></ins>;
+template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_subtract<ins> = <em>see below</em></ins>;
+template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_multiply<ins> = <em>see below</em></ins>;
+template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_divide<ins> = <em>see below</em></ins>;
+</pre></blockquote>
+</li>
+<li>
+<p>
+In 20.4.1 [ratio.ratio], change as indicated:
 </p>
+<blockquote><pre>namespace std {
+  template &lt;intmax_t N, intmax_t D = 1&gt;
+  class ratio {
+  public:
+    <ins>typedef ratio type;</ins>
+    static const intmax_t num;
+    static const intmax_t den;
+  };
+}
+</pre></blockquote>
+</li>
+<li>
 <p>
-It sounds more like an issue waiting to be opened, unless you want to plug
-it now.  As written we risk moving from lvalues.
+In 20.4.2 [ratio.arithmetic] change as indicated:
 </p>
 
-<p><i>[
-San Francisco:
-]</i></p>
-
+<blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_add<ins> = <em>see below</em></ins><del>{
+  typedef <em>see below</em> type;
+}</del>;
+</pre>
 
 <blockquote>
 <p>
-Would be NAD if better ctors fixed it.
+1 The <del>nested typedef</del> type <tt><ins>ratio_add&lt;R1, R2&gt;</ins></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>.
 </p>
+</blockquote>
+</blockquote>
+<blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_subtract<ins> = <em>see below</em></ins><del>{
+  typedef <em>see below</em> type;
+}</del>;
+</pre>
+<blockquote>
 <p>
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>.
+2 The <del>nested typedef</del> type <tt><ins>ratio_subtract&lt;R1, R2&gt;</ins></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>.
 </p>
 </blockquote>
-
-<p><i>[
-post San Francisco:
-]</i></p>
-
-
+</blockquote>
+<blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_multiply<ins> = <em>see below</em></ins><del>{
+  typedef <em>see below</em> type;
+}</del>;
+</pre>
 <blockquote>
-Possibly NAD Editorial, solved by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
+<p>
+3 The <del>nested typedef</del> type <tt><ins>ratio_multiply&lt;R1, R2&gt;</ins></tt>
+shall be a synonym for <tt>ratio&lt;T1, T2&gt;</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>.
+</p>
 </blockquote>
-
-<p><i>[
-2009-05-25 Alisdair adds:
-]</i></p>
-
-
+</blockquote>
+<blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_divide<ins> = <em>see below</em></ins><del>{
+  typedef <em>see below</em> type;
+}</del>;
+</pre>
 <blockquote>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a> was something I reported while reviewing the library concepts
-documents ahead of San Francisco.  The missing operator was added as part of
-the paper adopted at that meeting
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>)
-and I can confirm this operator is
-present in the current working paper.  I recommend NAD.
+<p>
+4 The <del>nested typedef</del> type <tt><ins>ratio_divide&lt;R1, R2&gt;</ins></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</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::num</tt>.
+</p>
 </blockquote>
-
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
-
-
+</blockquote>
+</li>
+<li>
+<p>
+In 20.9.3.1 [time.duration.cons]/4 change as indicated:
+</p>
 <blockquote>
-We agree with the intent, but we need to wait for the dust to settle on concepts.
+<p>
+<i>Requires:</i> <tt>treat_as_floating_point&lt;rep&gt;::value</tt> shall be true or
+<tt>ratio_divide&lt;Period2, period&gt;::<del>type::</del>den</tt> shall be 1.[..]
+</p>
 </blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
+</li>
+<li>
+<p>
+In 20.9.3.7 [time.duration.cast]/2 change as indicated:
+</p>
+<blockquote>
 <p>
+<i>Returns:</i> Let CF be <tt>ratio_divide&lt;Period, typename
+ToDuration::period&gt;<del>::type</del></tt>, and [..]
 </p>
+</blockquote>
+</li>
+</ol>
 
 
 
 
 
 <hr>
-<h3><a name="886"></a>886. tuple construction</h3>
-<p><b>Section:</b> 20.5.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="929"></a>929. Thread constructor</h3>
+<p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-10-23  <b>Last modified:</b> 2009-10-25</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>
-20.5.2.1 [tuple.cnstr]:
-</p>
-<blockquote>
-<i>Effects:</i> Default initializes each element.
-</blockquote>
 
-<p>
-Could be clarified to state each "non-trivial" element.  Otherwise
-we have a conflict with Core deinfition of default initialization -
-trivial types do not get initialized (rather than initialization
-having no effect)
-</p>
+<p><b>Addresses UK 323</b></p>
 
 <p>
-I'm going to punt on this one, because it's not an issue that's
-related to concepts. I suggest bringing it to Howard's attention on
-the reflector.
+The <tt>thread</tt> constructor for starting a new thread with a function and
+arguments is overly constrained by the signature requiring rvalue
+references for <tt>func</tt> and <tt>args</tt> and the <tt>CopyConstructible</tt> requirements
+for the elements of <tt>args</tt>. The use of an rvalue reference for the
+function restricts the potential use of a plain function name, since
+the type of the bound parameter will be deduced to be a function
+reference and decay to pointer-to-function will not happen. This
+therefore complicates the implementation in order to handle a simple
+case. Furthermore, the use of rvalue references for args prevents the
+array to pointer decay. Since arrays are not <tt>CopyConstructible</tt> or even
+<tt>MoveConstructible</tt>, this essentially prevents the passing of arrays as
+parameters. In particular it prevents the passing of string literals.
+Consequently a simple case such as
 </p>
 
-<p><i>[
-San Francisco:
-]</i></p>
-
+<blockquote><pre>void f(const char*);
+std::thread t(f,"hello");
+</pre></blockquote>
 
-<blockquote>
 <p>
-Text in draft doesn't mean anything, changing to "non-trivial" makes it
-meaningful.
+is ill-formed since the type of the string literal is <tt>const char[6]</tt>.
 </p>
+
 <p>
-We prefer "value initializes". Present implementations use
-value-initialization. Users who don't want value initialization have
-alternatives.
+By changing the signature to take all parameters by value we can
+eliminate the <tt>CopyConstructible</tt> requirement and permit the use of
+arrays, as the parameter passing semantics will cause the necessary
+array-to-pointer decay. They will also cause the function name to
+decay to a pointer to function and allow the implementation to handle
+functions and function objects identically.
 </p>
+
 <p>
-Request resolution text from Alisdair.
+The new signature of the <tt>thread</tt> constructor for a function and
+arguments is thus:
 </p>
 
+<blockquote><pre>template&lt;typename F,typename... Args&gt;
+thread(F,Args... args);
+</pre></blockquote>
+
 <p>
-This issue relates to Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a> default construction and value-initialization.
+Since the parameter pack <tt>Args</tt> can be empty, the single-parameter
+constructor that takes just a function by value is now redundant.
 </p>
-</blockquote>
 
 <p><i>[
-2009-05-04 Alisdair provided wording and adds:
+Howard adds:
 ]</i></p>
 
 
 <blockquote>
 <p>
-Note: This <em>IS</em> a change of semantic from TR1, although one the room agreed
-with during the discussion.  To preserve TR1 semantics, this would have been
-worded:
+I agree with everything Anthony says in this issue.  However I believe we
+can optimize in such a way as to get the pass-by-value behavior with the
+pass-by-rvalue-ref performance.  The performance difference is that the latter
+removes a <tt>move</tt> when passing in an lvalue.
 </p>
-<blockquote><pre>requires DefaultConstructible&lt;Types&gt;... tuple();
-</pre>
-<blockquote>
--2-   <i>Effects:</i> Default-initializes each non-trivial element.
-</blockquote>
-</blockquote>
-
-
-</blockquote>
-
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
 
+<p>
+This circumstance is very analogous to <tt>make_pair</tt> (20.3.4 [pairs])
+where we started with passing by const reference, changed to pass by value to
+get pointer decay, and then changed to pass by rvalue reference, but modified with
+<tt>decay&lt;T&gt;</tt> to retain the pass-by-value behavior.  If we were to
+apply the same solution here it would look like:
+</p>
 
+<blockquote><pre><del>template &lt;class F&gt; explicit thread(F f);</del>
+template &lt;class F, class ...Args&gt; thread(F&amp;&amp; f, Args&amp;&amp;... args);
+</pre>
 <blockquote>
-Move to Ready.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Change p2 in Construction 20.5.2.1 [tuple.cnstr]:
+-4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall be <del><tt>CopyConstructible</tt>
+if an lvalue and otherwise</del> <tt>MoveConstructible</tt>.
+<tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.7.2 [func.require]) shall be a valid expression for
+some values <tt>w1, w2, ... , wN,</tt> where <tt>N == sizeof...(Args)</tt>.
 </p>
-
-<blockquote><pre>requires DefaultConstructible&lt;Types&gt;... tuple();
-</pre>
-<blockquote>
 <p>
--2- <i>Effects:</i> <del>Default</del> <ins>Value-</ins>initializes each element.
+-5- <i>Effects:</i> Constructs an object of type <tt>thread</tt>
+<del>and executes <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> in a new
+thread of execution, where <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>.
+<ins>Constructs
+the following objects in memory which is accessible to a new thread of execution
+as if:</ins>
+</p>
+<blockquote><pre><ins>typename decay&lt;F&gt;::type g(std::forward&lt;F&gt;(f));</ins>
+<ins>tuple&lt;typename decay&lt;Args&gt;::type...&gt; w(std::forward&lt;Args&gt;(args)...);</ins>
+</pre></blockquote>
+<p>
+<ins>The new thread of
+execution executes <tt><i>INVOKE</i>(g, wi...)</tt> where the <tt>wi...</tt> refers
+to the elements stored in the <tt>tuple w</tt>.</ins>
+Any return value from <tt>g</tt> is ignored.
+<del>If <tt>f</tt> terminates with an uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
+<ins>If the evaluation of <tt><i>INVOKE</i>(g,  wi...)</tt> terminates
+with an uncaught exception, <tt>std::terminate()</tt> shall be called [<i>Note:</i>
+<tt>std::terminate()</tt> could be called before entering <tt>g</tt>. -- <i>end note</i>]. Any
+exception thrown before the evaluation of <tt><i>INVOKE</i></tt> has started shall be
+catchable in the calling thread.</ins>
 </p>
 </blockquote>
 </blockquote>
 
-
-
-
-
-
-<hr>
-<h3><a name="887"></a>887. issue with condition::wait_...</h3>
-<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-07-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-The Posix/C++ working group has identified an inconsistency between
-Posix and the C++ working draft in that Posix requires the clock to be
-identified at creation, whereas C++ permits identifying the clock at the
-call to wait.  The latter cannot be implemented with the former.
+Text referring to when <tt>terminate()</tt> is called was contributed by Ganesh.
 </p>
 
+</blockquote>
+
 <p><i>[
-San Francisco:
+Batavia (2009-05):
 ]</i></p>
 
-
 <blockquote>
-<p>
-Howard recommends NAD with the following explanation:
-</p>
-
-<p>
-The intent of the current wording is for the <tt>condtion_variable::wait_until</tt>
-be able to handle user-defined clocks as well as clocks the system knows about.
-This can be done by providing overloads for the known clocks, and another
-overload for unknown clocks which synchs to a known clock before waiting.
-For example:
-</p>
-
-<blockquote><pre>template &lt;class Duration&gt;
-bool
-condition_variable::wait_until(unique_lock&lt;mutex&gt;&amp; lock,
-                               const chrono::time_point&lt;chrono::system_clock, Duration&gt;&amp; abs_time)
-{
-    using namespace chrono;
-    nanoseconds d = __round_up&lt;nanoseconds&gt;(abs_time.time_since_epoch());
-    __do_timed_wait(lock.mutex()-&gt;native_handle(), time_point&lt;system_clock, nanoseconds&gt;(d));
-    return system_clock::now() &lt; abs_time;
-}
-
-template &lt;class Clock, class Duration&gt;
-bool
-condition_variable::wait_until(unique_lock&lt;mutex&gt;&amp; lock,
-                               const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time)
-{
-    using namespace chrono;
-    typename Clock::time_point  c_entry = Clock::now();
-    system_clock::time_point    s_entry = system_clock::now();
-    nanoseconds dn = __round_up&lt;nanoseconds&gt;(abs_time.time_since_epoch() -
-                                              c_entry.time_since_epoch());
-    __do_timed_wait(lock.mutex()-&gt;native_handle(), s_entry + dn);
-    return Clock::now() &lt; abs_time;
-}
-</pre></blockquote>
-
-<p>
-In the above example, <tt>system_clock</tt> is the only clock which the underlying
-condition variable knows how to deal with.  One overload just passes that clock
-through.  The second overload (approximately) converts the unknown clock into
-a <tt>system_clock  time_point</tt> prior to passing it down to the native
-condition variable.
-</p>
-
-<p>
-On Posix systems vendors are free to add implementation defined constructors which
-take a clock.  That clock can be stored in the condition_variable, and converted
-to (or not as necessary) as shown above.
-</p>
-
-<p>
-If an implementation defined constructor takes a clock (for example), then part
-of the semantics for that implementation defined ctor might include that a
-<tt>wait_until</tt> using a clock other than the one constructed with results
-in an error (exceptional condition) instead of a conversion to the stored clock.
-Such a design is up to the vendor as once an implementation defined ctor is used,
-the vendor is free to specifiy the behavior of waits and/or notifies however
-he pleases (when the cv is constructed in an implementation defined manner).
-</p>
+We agree with the proposed resolution,
+but would like the final sentence to be reworded
+since "catchable" is not a term of art (and is used nowhere else).
 </blockquote>
 
 <p><i>[
-Post Summit:
+2009-07 Frankfurt:
 ]</i></p>
 
 
 <blockquote>
 <p>
-"POSIX people will review the proposed NAD resolution at their upcoming NY
-meeting.
+This is linked to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2901.pdf">N2901</a>.
 </p>
-
 <p>
-See the minutes at: <a href="http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009">http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009</a>.
+Howard to open a separate issue to remove (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1176">1176</a>).
+</p>
+<p>
+In Frankfurt there is no consensus for removing the variadic constructor.
 </p>
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Move to NAD.
+We want to move forward with this issue.  If we later take it out via <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1176">1176</a>
+then that's ok too.  Needs small group to improve wording.
 </blockquote>
 
 <p><i>[
-2009-07-18 Detlef reopens the issue:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
 <p>
-On Friday afternoon in Frankfurt is was decided that 887 is NAD.
-This decision was mainly based on a sample implementation presented
-by Howard that implemented one clock on top of another.
-Unfortunately this implementation doesn't work for the probably most
-important case where a system has a monotonic clock and a real-time
-clock (or "wall time" clock):
+Stefanus provided revised wording.  Moved to Review  Here is the original wording:
 </p>
+<blockquote>
 <p>
-If the underlying "system_clock" is a monotonic clock, and
-the program waits on the real-time clock, and the real-time clock
-is set forward, the wait will unblock too late.
+Modify the class definition of <tt>std::thread</tt> in 30.3.1 [thread.thread.class] to remove the
+following signature:
 </p>
 
+<blockquote><pre><del>template&lt;class F&gt; explicit thread(F f);</del>
+template&lt;class F, class ... Args&gt; <ins>explicit</ins> thread(F&amp;&amp; f, Args&amp;&amp; ... args);
+</pre></blockquote>
+
 <p>
-If the underlying "system_clock" is a real-time clock, and the
-program waits on the monotonic clock, and the real-time clock
-is set back, the wait again will unblock too late.
+Modify 30.3.1.2 [thread.thread.constr] to replace the constructors prior to paragraph 4 with
+the single constructor as above. Replace paragraph 4 - 6 with the
+following:
 </p>
 
+<blockquote>
 <p>
-Sorry that I didn't remember this on Friday, but it was Friday
-afternoon after a busy week...
+-4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall be <del><tt>CopyConstructible</tt>
+if an lvalue and otherwise</del> <tt>MoveConstructible</tt>.
+<tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.7.2 [func.require]) shall be a valid expression for
+some values <tt>w1, w2, ... , wN,</tt> where <tt>N == sizeof...(Args)</tt>.
 </p>
-
 <p>
-So as the decision was made on a wrong asumption, I propose to re-open
-the issue.
+-5- <i>Effects:</i> Constructs an object of type <tt>thread</tt>
+<del>and executes <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> in a new
+thread of execution, where <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>.
+<ins>Constructs
+the following objects:</ins>
+</p>
+<blockquote><pre><ins>typename decay&lt;F&gt;::type g(std::forward&lt;F&gt;(f));</ins>
+<ins>tuple&lt;typename decay&lt;Args&gt;::type...&gt; w(std::forward&lt;Args&gt;(args)...);</ins>
+</pre></blockquote>
+<p>
+<ins>and executes <tt><i>INVOKE</i>(g, wi...)</tt> in a new thread of execution.
+These objects shall be destroyed when the new thread of execution completes.</ins>
+Any return value from <tt>g</tt> is ignored.
+<del>If <tt>f</tt> terminates with an uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
+<ins>If the evaluation of <tt><i>INVOKE</i>(g,  wi...)</tt> terminates
+with an uncaught exception, <tt>std::terminate()</tt> shall be called [<i>Note:</i>
+<tt>std::terminate()</tt> could be called before entering <tt>g</tt>. -- <i>end note</i>]. Any
+exception thrown before the evaluation of <tt><i>INVOKE</i></tt> has started shall be
+catchable in the calling thread.</ins>
+</p>
+<p>
+-6- <i>Synchronization:</i> The invocation of the constructor <i>happens before</i> the
+invocation of <del><tt>f</tt></del> <ins><tt>g</tt></ins>.
 </p>
 </blockquote>
 
-<p><i>[
-2009-07-26 Howard adds:
-]</i></p>
+</blockquote>
+</blockquote>
 
 
-<blockquote>
+<p><b>Proposed resolution:</b></p>
 <p>
-Detlef correctly argues that <tt>condition_variable::wait_until</tt> could
-return "too late" in the context of clocks being adjusted during the wait.  I agree
-with his logic.  But I disagree that this makes this interface unimplementable
-on POSIX.
+Modify the class definition of <tt>std::thread</tt> in 30.3.1 [thread.thread.class] to remove the
+following signature:
 </p>
 
+<blockquote><pre><del>template&lt;class F&gt; explicit thread(F f);</del>
+template&lt;class F, class ... Args&gt; <ins>explicit</ins> thread(F&amp;&amp; f, Args&amp;&amp; ... args);
+</pre></blockquote>
+
 <p>
-The POSIX spec also does not guarantee that <tt>pthread_cond_timedwait</tt> does
-not return "too late" when clocks are readjusted during the wait.  Indeed, the
-POSIX specification lacks any requirements at all concerning how soon
-<tt>pthread_cond_timedwait</tt> returns after a time out.  This is evidently a
-QOI issue by the POSIX standard.  Here is a quote of the most relevant normative
-text concerning <tt>pthread_cond_timedwait</tt> found
-<a href="http://www.unix.org/single_unix_specification/">here</a>.
+Modify 30.3.1.2 [thread.thread.constr] to replace the constructors prior to paragraph 4 with
+the single constructor as above. Replace paragraph 4 - 6 with the
+following:
 </p>
 
 <blockquote>
-The <tt>pthread_cond_timedwait()</tt> function shall be equivalent to
-<tt>pthread_cond_wait()</tt>, except that an error is returned if the absolute
-time specified by <tt>abstime</tt> passes (that is, system time equals or exceeds
-<tt>abstime</tt>) before the condition <tt>cond</tt> is signaled or broadcasted, or if the
-absolute time specified by <tt>abstime</tt> has already been passed at the time
-of the call.
-</blockquote>
-
 <p>
-I.e. the POSIX specification speaks of the error code returned in case of a time
-out, but not on the timeliness of that return.
+-4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt>
+shall be <del><tt>CopyConstructible</tt> if an lvalue and
+otherwise</del> <tt>MoveConstructible</tt>. <tt><i>INVOKE</i>(f, w1, w2,
+..., wN)</tt> (20.7.2 [func.require]) shall be a valid expression
+for some values <tt>w1, w2, ... , wN,</tt> where <tt>N ==
+sizeof...(Args)</tt>.
 </p>
 
 <p>
-Might this simply be an oversight, or minor defect in the POSIX specification?
+-5- <i>Effects:</i> Constructs an object of type <tt>thread</tt> <del>and executes
+<tt>INVOKE(f, t1, t2, ..., tN)</tt> in a new thread of execution, where
+<tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>. 
+<ins>Given a function as follows:</ins>
+<del>Any return
+value from <tt>f</tt> is ignored. If <tt>f</tt> terminates with an
+uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
 </p>
 
-<p>
-I do not believe so.  This same section goes on to say in <em>non-normative</em>
-text:
-</p>
+<blockquote><pre><ins>
+template&lt;typename T&gt; typename decay&lt;T&gt;::type decay_copy(T&amp;&amp; v)
+    { return std::forward&lt;T&gt;(v); }
+</ins></pre></blockquote>
 
-<blockquote>
-For cases when the system clock is advanced discontinuously by an
-operator, it is expected that implementations process any timed wait
-expiring at an intervening time as if that time had actually occurred.
-</blockquote>
+<p><ins>
+The new thread of execution executes <tt>INVOKE(decay_copy(f),
+decay_copy(args)...)</tt> with the calls to <tt>decay_copy()</tt> being evaluated in
+the constructing thread. Any return value from this invocation is
+ignored. [<i>Note:</i> this implies any exceptions not thrown from the
+invocation of the copy of <tt>f</tt> will be thrown in the constructing thread,
+not the new thread. &#8212; <i>end note</i>].
+</ins></p>
 
 <p>
-Here is non-normative wording encouraging the implementation to ignore an advancing
-underlying clock and subsequently causing an early (spurious) return.  There is
-no wording at all which addresses Detlef's example of a "late return".  With
-<tt>pthread_cond_timedwait</tt> this would be caused by setting the system clock
-backwards.  It seems reasonable to assume, based on the wording that is already
-in the POSIX spec, that again, the discontinuously changed clock would be ignored
-by <tt>pthread_cond_timedwait</tt>. 
+-6- <i>Synchronization:</i> The invocation of the constructor <i>happens before</i> the
+invocation of <ins>copy of</ins> <tt>f</tt>.
 </p>
+</blockquote>
 
-<p>
-A noteworthy difference between <tt>pthread_cond_timedwait</tt> and
-<tt>condition_variable::wait_until</tt> is that the POSIX spec appears to
-say that <tt>ETIMEDOUT</tt> should be returned if <tt>pthread_cond_timedwait</tt>
-returns because of timeout signal, whether or not the system clock was discontinuously
-advanced during the wait.  In contrast <tt>condition_variable::wait_until</tt>
-always returns:
-</p>
-
-<blockquote><pre><tt>Clock::now() &lt; abs_time</tt>
-</pre></blockquote>
-
-<p>
-That is, the C++ spec requires that the clock be rechecked (detecting discontinuous
-adjustments during the wait) at the time of return.  <tt>condition_variable::wait_until</tt>
-may indeed return early or late.  But regardless it will return a value
-reflecting timeout status at the time of return (even if clocks have been adjusted).
-Of course the clock may be adjusted after the return value is computed but before the client has
-a chance to read the result of the return.  Thus there are no iron-clad guarantees
-here.
-</p>
-
-<p>
-<tt>condition_variable::wait_until</tt> (and <tt>pthread_cond_timedwait</tt>)
-is little more than a convenience function for making sure
-<tt>condition_variable::wait</tt> doesn't hang for an unreasonable amount of
-time (where the client gets to define "unreasonable").  I do not think it
-is in anyone's interest to try to make it into anything more than that.
-</p>
-
-<p>
-I maintain that this is a useful and flexible specification in the spirit of
-C++, and is implementable on POSIX.  The implementation technique described above
-is a reasonable approach.  There may also be higher quality approaches.  This
-specification, like the POSIX specification, gives a wide latitude for QOI.
-</p>
-
-<p>
-I continue to recommend NAD, but would not object to a clarifying note regarding
-the behavior of <tt>condition_variable::wait_until</tt>.  At the moment, I do
-not have good wording for such a note, but welcome suggestions.
-</p>
-
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
 
 
 
 
 
 <hr>
-<h3><a name="889"></a>889. thread::id comparisons</h3>
-<p><b>Section:</b> 30.3.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-07-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.id">issues</a> in [thread.thread.id].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="932"></a>932. <tt>unique_ptr(pointer p)</tt> for pointer deleter types</h3>
+<p><b>Section:</b> 20.8.14.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-11-26  <b>Last modified:</b> 2009-10-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.ctor">active issues</a> in [unique.ptr.single.ctor].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 
-<p><b>Addresses UK 324</b></p>
+<p><b>Addresses US 79</b></p>
 
 <p>
-The <tt>thread::id</tt> type supports the full set of comparison operators.  This
-is substantially more than is required for the associative containers that
-justified them.  Please place an issue against the threads library.
+20.8.14.2.1 [unique.ptr.single.ctor]/5 no longer requires for <tt>D</tt>
+not to be a pointer type.  I believe this restriction was accidently removed
+when we relaxed the completeness reuqirements on <tt>T</tt>. The restriction
+needs to be put back in.  Otherwise we have a run time failure that could
+have been caught at compile time:
 </p>
 
+<blockquote><pre>{
+unique_ptr&lt;int, void(*)(void*)&gt; p1(malloc(sizeof(int)));  <font color="#c80000">// should not compile</font>
+}  <font color="#c80000">// p1.~unique_ptr() dereferences a null function pointer</font>
+unique_ptr&lt;int, void(*)(void*)&gt; p2(malloc(sizeof(int)), free);  <font color="#c80000">// ok</font>
+</pre></blockquote>
+
 <p><i>[
-San Francisco:
+Post Summit:
 ]</i></p>
 
 
 <blockquote>
-<p>
-Would depend on proposed extension to POSIX, or non-standard extension.
-What about hash? POSIX discussing op. POSIX not known to be considering
-support needed for hash, op.
-</p>
-<p>
-Group expresses support for putting ids in both unordered and ordered containers.
-</p>
+Recommend Tentatively Ready.
 </blockquote>
 
 <p><i>[
-post San Francisco:
+2009-07 Frankfurt
 ]</i></p>
 
 
 <blockquote>
-<p>
-Howard:  It turns out the current working paper
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
-<i>already has</i> <tt>hash&lt;thread::id&gt;</tt>
-(20.7 [function.objects], 20.7.17 [unord.hash]).  We simply
-overlooked it in the meeting.  It is a good thing we voted in favor of it
-(again). :-)
-</p>
-<p>
-Recommend NAD.
-</p>
-
+Moved from Tentatively Ready to Open only because the wording needs to be
+improved for enable_if type constraining, possibly following Robert's
+formula.
 </blockquote>
 
 <p><i>[
-Post Summit:
+2009-07 Frankfurt:
 ]</i></p>
 
 
 <blockquote>
-Recommend to close as NAD. For POSIX, see if we need to add a function to
-convert <tt>pthread_t</tt> to integer.
+<p>
+We need to consider whether some requirements in the Requires paragraphs
+of [unique.ptr] should instead be Remarks.
+</p>
+<p>
+Leave Open. Howard to provide wording, and possibly demonstrate how this
+can be implemented using enable_if.
+</p>
 </blockquote>
 
 <p><i>[
-Post Summit, Alisdair adds:
+2009-07-27 Howard adds:
 ]</i></p>
 
 
 <blockquote>
 <p>
-The recommendation for LWG-889/UK-324 is NAD, already specified.
-</p>
-<p>
-It is not clear to me that the specification is complete.
-</p>
-<p>
-In particular, the synopsis of <tt>&lt;functional&gt;</tt> in 20.7 [function.objects] does not mention <tt>hash&lt; thread::id
-&gt;</tt> nor <tt>hash&lt; error_code &gt;</tt>, although their
-existence is implied by 20.7.17 [unord.hash], p1.
-</p>
-<p>
-I am fairly uncomfortable putting the declaration for the
-<tt>thread_id</tt> specialization into <tt>&lt;functional&gt;</tt> as
-<tt>id</tt> is a nested class inside <tt>std::thread</tt>, so it implies
-that <tt>&lt;functional&gt;</tt> would require the definition of the
-<tt>thread</tt> class template in order to forward declared
-<tt>thread::id</tt> and form this specialization.
+The two constructors to which this issue applies are not easily constrained
+with <tt>enable_if</tt> as they are not templated:
 </p>
+
+<blockquote><pre>unique_ptr();
+explicit unique_ptr(pointer p);
+</pre></blockquote>
+
 <p>
-It seems better to me that the dependency goes the other way around
-(<tt>&lt;thread&gt;</tt> will more typically make use of
-<tt>&lt;functional&gt;</tt> than vice-versa) and the
-<tt>hash&lt;thread::id&gt;</tt> specialization be declared in the
-<tt>&lt;thread&gt;</tt> header.
+To "SFINAE" these constructors away would take heroic effort such as specializing
+the entire <tt>unique_ptr</tt> class template on pointer deleter types.  There
+is insufficient motivation for such heroics.  Here is the expected and
+reasonable implementation for these constructors:
 </p>
+
+<blockquote><pre>unique_ptr()
+    : ptr_(pointer())
+    {
+        static_assert(!is_pointer&lt;deleter_type&gt;::value,
+            "unique_ptr constructed with null function pointer deleter");
+    }
+explicit unique_ptr(pointer p)
+    : ptr_(p)
+    {
+        static_assert(!is_pointer&lt;deleter_type&gt;::value,
+            "unique_ptr constructed with null function pointer deleter");
+    }
+</pre></blockquote>
+
 <p>
-I think <tt>hash&lt;error_code&gt;</tt> could go into either
-<tt>&lt;system_error&gt;</tt> or <tt>&lt;functional&gt;</tt> and have no
-immediate preference either way.  However, it should clearly appear in
-the synopsis of one of these two.
+I.e. just use <tt>static_assert</tt> to verify that the constructor is not
+instantiated with a function pointer for a deleter.  The compiler will automatically
+take care of issuing a diagnostic if the deleter is a reference type (uninitialized
+reference error).
 </p>
+
 <p>
-Recommend moving 889 back to open, and tying in a reference to UK-324.
+In keeping with our discussions in Frankfurt, I'm moving this requirement on
+the implementation from the Requires paragraph to a Remarks paragraph.
 </p>
+
 </blockquote>
 
 <p><i>[
-Batavia (2009-05):
+2009-08-17 Daniel adds:
 ]</i></p>
 
+
 <blockquote>
-Howard observes that <tt>thread::id</tt> need not be a nested class;
-it could be a <tt>typedef</tt> for a more visible type.
+<p>
+It is insufficient to require a diagnostic. This doesn't imply an
+ill-formed program
+as of 1.3.3 [defns.diagnostic] (a typical alternative would be a compiler
+warning), but
+exactly that seems to be the intend. I suggest to use the following
+remark instead:
+</p>
+
+<blockquote>
+<i>Remarks:</i> The program shall be ill-formed if this constructor is
+instantiated when <tt>D</tt> is a pointer type or reference type.
 </blockquote>
 
-<p><i>[
-2009-05-24 Alisdair adds:
-]</i></p>
+<p>
+Via the general standard rules of 1.4 [intro.compliance] the "diagnostic
+required" is implied.
+</p>
 
-<blockquote>
-I do not believe this is correct.  <tt>thread::id</tt> is explicitly documents as a
-nested class, rather than as an unspecified typedef analogous to an
-iterator.  If the intent is that this is not implemented as a nested class
-(under the as-if freedoms) then this is a novel form of standardese.
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Decided we want to move hash specialization for thread_id to the thread
-header. Alisdair to provide wording.
+Moved to Ready.
 </blockquote>
 
-<p><i>[
-2009-07-28 Alisdair provided wording, moved to Review.
-]</i></p>
-
-
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add to 30.3 [thread.threads], p1 Header <tt>&lt;thread&gt;</tt> synopsis:
-</p>
-
-<blockquote><pre><ins>template &lt;class T&gt; struct hash;
-template &lt;&gt; struct hash&lt;thread::id&gt;;</ins>
-</pre></blockquote>
-
-<p>
-Add template specialization below class definition in 30.3.1.1 [thread.thread.id]
+Change the description of the default constructor in 20.8.14.2.1 [unique.ptr.single.ctor]:
 </p>
 
-<blockquote><pre><ins>template &lt;&gt;
-struct hash&lt;thread::id&gt; : public unary_function&lt;thread::id, size_t&gt; {
-   size_t operator()(thread::id val) const;
-};</ins>
-</pre></blockquote>
-
+<blockquote><pre>unique_ptr();
+</pre>
+<blockquote>
 <p>
-Extend note in p2 30.3.1.1 [thread.thread.id] with second sentence:
+-1- <i>Requires:</i> <tt>D</tt> shall be default constructible, and that construction
+shall not throw an exception. <del><tt>D</tt> shall 
+not be a reference type or pointer type (diagnostic required).</del>
 </p>
+<p>...</p>
+<p><ins>
+<i>Remarks:</i> The program shall be ill-formed if this constructor is
+instantiated when <tt>D</tt> is a pointer type or reference type.
 
-<blockquote>
-[<i>Note:</i> Relational operators allow <tt>thread::id</tt> objects to be used
-as keys in associative containers.
-<ins><tt>hash</tt> template specialization allow <tt>thread::id</tt> objects to be used as keys
-in unordered containers.</ins>
-&#8212; <i>end note</i>]
+</ins></p>
+</blockquote>
 </blockquote>
 
 <p>
-Add new paragraph to end of 30.3.1.1 [thread.thread.id]
+Add  after 20.8.14.2.1 [unique.ptr.single.ctor]/8:
 </p>
 
-<blockquote><pre><ins>template &lt;&gt; struct hash&lt;thread::id&gt;;</ins>
+<blockquote><pre>unique_ptr(pointer p);
 </pre>
-<blockquote><ins>
-An explicit specializations of the class template hash (20.7.17 [unord.hash])
-shall be provided for the values of type <tt>thread::id</tt>
-suitable for use as keys in unordered associative containers (23.5 [unord]).
-</ins></blockquote>
+<blockquote>
+<p>...</p>
+<p><ins>
+<i>Remarks:</i> The program shall be ill-formed if this constructor is
+instantiated when <tt>D</tt> is a pointer type or reference type.
+
+</ins></p>
+</blockquote>
 </blockquote>
 
 
@@ -14919,224 +12335,185 @@ suitable for use as keys in unordered associative containers (23.5 [unord]).
 
 
 <hr>
-<h3><a name="891"></a>891. std::thread, std::call_once issue</h3>
-<p><b>Section:</b> 30.3.1.2 [thread.thread.constr], 30.4.5.2 [thread.once.callonce] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="939"></a>939. Problem with <tt>std::identity</tt> and reference-to-temporaries</h3>
+<p><b>Section:</b> 20.3.3 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-12-11  <b>Last modified:</b> 2009-10-29</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-I notice that the vararg overloads of <tt>std::thread</tt> and <tt>std::call_once</tt>
-(N2723 30.3.1.2 [thread.thread.constr] and 30.4.5.2 [thread.once.callonce]) are no longer specified in terms of
-<tt>std::bind</tt>; instead, some of the <tt>std::bind</tt> wording has been inlined into
-the specification.
-</p>
+<tt>std::identity</tt> takes an argument of type <tt>T const &amp;</tt>
+and returns a result of <tt>T const &amp;</tt>.
+</p>
 <p>
-There are two problems with this.
+Unfortunately, this signature will accept a value of type other than <tt>T</tt> that
+is convertible-to-<tt>T</tt>, and then return a reference to the dead temporary.  The
+constraint in the concepts version simply protects against returning
+reference-to-<tt>void</tt>.
 </p>
 <p>
-First, the specification (and implementation) in terms of <tt>std::bind</tt> allows, for example:
+Solutions:
 </p>
-
-<blockquote><pre>std::thread th( f, 1, std::bind( g ) );
+<blockquote>
+<p>
+i/  Return-by-value, potentially slicing bases and rejecting non-copyable
+types
+</p>
+<p>
+ii/ Provide an additional overload:
+</p>
+<blockquote><pre>template&lt; typename T &gt;
+template operator( U &amp; ) = delete;
 </pre></blockquote>
-
 <p>
-which executes <tt>f( 1, g() )</tt> in a thread. This can be useful. The
-"inlined" formulation changes it to execute <tt>f( 1, bind(g) )</tt> in a thread.
+This seems closer on intent, but moves beyond the original motivation for
+the operator, which is compatibility with existing (non-standard)
+implementations.
 </p>
 <p>
-Second, assuming that we don't want the above, the specification has copied the wording
+iii/ Remove the <tt>operator()</tt> overload.  This restores the original definition
+of the <tt>identity</tt>, although now effectively a type_trait rather than part of
+the perfect forwarding protocol.
 </p>
-
-<blockquote>
-<tt>INVOKE(func, w1, w2, ..., wN)</tt> (20.6.2) shall be a valid
-expression for some values <tt>w1, w2, ..., wN</tt>
-</blockquote>
-
 <p>
-but this is not needed since we know that our argument list is args; it should simply be
+iv/ Remove <tt>std::identity</tt> completely; its original reason to exist is
+replaced with the <tt>IdentityOf</tt> concept.
 </p>
-
-<blockquote>
-<tt>INVOKE(func, args...)</tt> (20.6.2) shall be a valid expression
 </blockquote>
+<p>
+My own preference is somewhere between (ii) and (iii) - although I stumbled
+over the issue with a specific application hoping for resolution (i)!
+</p>
 
 <p><i>[
-Summit:
+Batavia (2009-05):
 ]</i></p>
 
-
 <blockquote>
-Move to open.
+<p>
+We dislike options i and iii, and option ii seems like overkill.
+If we remove it (option iv), implementers can still provide it under a
+different name.
+</p>
+<p>
+Move to Open pending wording (from Alisdair) for option iv.
+</p>
 </blockquote>
 
 <p><i>[
-Post Summit Anthony provided proposed wording.
+2009-05-23 Alisdair provided wording for option iv.
 ]</i></p>
 
 
 <p><i>[
-2009-07 Frankfurt
+2009-07-20 Alisdair adds:
 ]</i></p>
 
 
 <blockquote>
-Leave Open. Await decision for thread variadic constructor.
+<p>
+I'm not sure why this issue was not discussed at Frankfurt (or I missed
+the discussion) but the rationale is now fundamentally flawed.  With the
+removal of concepts, <tt>std::identity</tt> again becomes an important library
+type so we cannot simply remove it.
+</p>
+<p>
+At that point, we need to pick one of the other suggested resolutions,
+but have no guidance at the moment.
+</p>
 </blockquote>
 
+<p><i>[
+2009-07-20 Howard adds:
+]</i></p>
 
 
-<p><b>Proposed resolution:</b></p>
+<blockquote>
 <p>
-Change paragraph 4 of 30.3.1.2 [thread.thread.constr] to:
+I believe the rationale for not addressing this issue in Frankfurt was that it did
+not address a national body comment.
 </p>
-
-<blockquote>
-<pre>template &lt;class F&gt; explicit thread(F f);
-template &lt;class F, class ...Args&gt; thread(F&amp;&amp; f, Args&amp;&amp;... args);
-</pre>
-<blockquote>
--4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt>
-shall be <tt>CopyConstructible</tt> if an lvalue and otherwise
-<tt>MoveConstructible</tt>. <tt><i>INVOKE</i>(f, <del>w1, w2, ..., wN</del> <ins>args...</ins>)</tt>
-(20.6.2) shall be a valid expression<del> for some values <i>w1, w2, ...,
-wN</i>, where <tt>N == sizeof...(Args)</tt></del>.
-</blockquote>
-</blockquote>
-
 <p>
-Change paragraph 1 of 30.4.5.2 [thread.once.callonce] to:
+I also believe that removal of <tt>identity</tt> is still a practical option as
+my latest reformulation of <tt>forward</tt>, which is due to comments suggested
+at Summit, no longer uses <tt>identity</tt>. :-)
 </p>
 
-<blockquote><pre>template&lt;class Callable, class ...Args&gt; 
-  void call_once(once_flag&amp; flag, Callable func, Args&amp;&amp;... args);
-</pre>
-<blockquote>
--1- <i>Requires:</i> The template parameters <tt>Callable&gt;</tt> and each
-<tt>Ti</tt> in <tt>Args</tt> shall be <tt>CopyConstructible</tt> if an
-lvalue and otherwise <tt>MoveConstructible</tt>. <tt><i>INVOKE</i>(func,
-<del>w1, w2, ..., wN</del> <ins>args...</ins>)</tt> (20.6.2) shall be a
-valid expression<del> for some values <i>w1, w2, ..., wN</i>, where
-<tt>N == sizeof...(Args)</tt></del>.
-</blockquote>
-</blockquote>
+<blockquote><pre>template &lt;class T, class U,
+    class = typename enable_if
+            &lt;
+                !is_lvalue_reference&lt;T&gt;::value || 
+                 is_lvalue_reference&lt;T&gt;::value &amp;&amp;
+                 is_lvalue_reference&lt;U&gt;::value
+            &gt;::type,
+    class = typename enable_if
+            &lt;
+                is_same&lt;typename remove_all&lt;T&gt;::type,
+                        typename remove_all&lt;U&gt;::type&gt;::value
+            &gt;::type&gt;
+inline
+T&amp;&amp;
+forward(U&amp;&amp; t)
+{
+    return static_cast&lt;T&amp;&amp;&gt;(t);
 
+}
+</pre>
 
+<p><i>[
+The above code assumes acceptance of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1120">1120</a> for the definition of
+<tt>remove_all</tt>.  This is just to make the syntax a little more palatable.
+Without this trait the above is still very implementable.
+]</i></p>
 
 
+</blockquote>
 
-<hr>
-<h3><a name="893"></a>893. std::mutex issue</h3>
-<p><b>Section:</b> 30.4.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-07-31</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.class">active issues</a> in [thread.mutex.class].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.class">issues</a> in [thread.mutex.class].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a></p>
-<p><b>Discussion:</b></p>
-<p>
-30.4.1.1 [thread.mutex.class]/27 (in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
-says that the behavior is undefined if:
-</p>
-<ul>
-<li>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or
-<tt>try_lock()</tt> on that object</li>
-</ul>
-<p>
-I don't believe that this is right. Calling <tt>lock()</tt> or <tt>try_lock()</tt> on a
-locked <tt>mutex</tt> is well defined in the general case. <tt>try_lock()</tt> is required
-to fail and return <tt>false</tt>. <tt>lock()</tt> is required to either throw an
-exception (and is allowed to do so if it detects deadlock) or to block
-until the <tt>mutex</tt> is free. These general requirements apply regardless of
-the current owner of the <tt>mutex</tt>; they should apply even if it's owned by
-the current thread.
-</p>
 <p>
-Making double <tt>lock()</tt> undefined behavior probably can be justified (even
-though I'd still disagree with the justification), but <tt>try_lock()</tt> on a
-locked <tt>mutex</tt> must fail.
+Paper with rationale is on the way ... <i>really</i>, I promise this time! ;-)
 </p>
+</blockquote>
 
 <p><i>[
-Summit:
+2009-07-30 Daniel adds:  See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#823">823</a> for an alternative resolution.
 ]</i></p>
 
-<blockquote>
-<p>
-Move to open. Proposed resolution:
-</p>
-<ul>
-<li>
-In 30.4.1 [thread.mutex.requirements] paragraph 12, change the error
-condition for <tt>resource_deadlock_would_occur</tt> to: "if the implementation
-detects that a deadlock would occur"
-</li>
-<li>
-Strike 30.4.1.1 [thread.mutex.class] paragraph 3 bullet 2 "a thread that owns a mutex object
-calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or"
-</li>
-</ul>
-</blockquote>
 
 <p><i>[
-2009-07 Frankfurt
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Move to Review. Alisdair to provide note.
+Move to Ready. Howard will update proposed wording to reflect current draft.
 </blockquote>
 
-<p><i>[
-2009-07-31 Alisdair provided note.
-]</i></p>
-
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-In 30.4.1 [thread.mutex.requirements] paragraph 12 change:
+Strike from 20.3 [utility]:
 </p>
 
-<blockquote>
-<ul>
-<li>...</li>
-<li>
-<tt>resource_deadlock_would_occur</tt> -- if the <del>current thread already owns the mutex and is able 
-to detect it</del> <ins>implementation detects that a deadlock would occur</ins>.
-</li>
-<li>...</li>
-</ul>
-</blockquote>
+<blockquote><pre><del>template &lt;class T&gt; struct identity;</del>
+</pre></blockquote>
 
 <p>
-Strike 30.4.1.1 [thread.mutex.class] paragraph 3 bullet 2:
+Remove from 20.3.3 [forward]:
 </p>
+
 <blockquote>
-<p>
--3- The behavior of a program is undefined if:
-</p>
-<ul>
-<li>...</li>
-<li>
-<del>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or</del>
-</li>
-<li>...</li>
-</ul>
-</blockquote>
+<pre><del>template &lt;class T&gt; struct identity {
+  typedef T type;
 
-<p>
-Add the following note after p3 30.4.1.1 [thread.mutex.class]
-</p>
+  const T&amp; operator()(const T&amp; x) const;
+};</del>
 
+<del>const T&amp; operator()(const T&amp; x) const;</del>
+</pre>
 <blockquote>
-[<i>Note:</i> a program may deadlock if the thread that owns a <tt>mutex</tt>
-object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object. If the program can
-detect the deadlock, a <tt>resource_deadlock_would_occur</tt> error condition may
-be observed. &#8212; <i>end note</i>]
+<del>-2-  <i>Returns:</i> <tt>x</tt></del>
+</blockquote>
 </blockquote>
 
 
@@ -15145,504 +12522,545 @@ be observed. &#8212; <i>end note</i>]
 
 
 <hr>
-<h3><a name="896"></a>896. Library thread safety issue</h3>
-<p><b>Section:</b> 20.8.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2008-09-16  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="940"></a>940. <tt>std::distance</tt></h3>
+<p><b>Section:</b> 24.4.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Thomas <b>Opened:</b> 2008-12-14  <b>Last modified:</b> 2009-10-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.operations">active issues</a> in [iterator.operations].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>
-It is unclear whether <tt>shared_ptr</tt> is thread-safe in the sense that
-multiple threads may simultaneously copy a <tt>shared_ptr</tt>.  However this
-is a critical piece of information for the client, and it has significant
-impact on usability for many applications.  (Detlef Vollman thinks it
-is currently clear that it is not thread-safe.  Hans Boehm thinks
-it currently requires thread safety, since the <tt>use_count</tt> is not an
-explicit field, and constructors and assignment take a const reference
-to an existing <tt>shared_ptr</tt>.)
-</p>
+
+<p><b>Addresses UK 270</b></p>
 
 <p>
-Pro thread-safety:
-</p>
-<p>
-Many multi-threaded usages are impossible.  A thread-safe version can
-be used to destroy an object when the last thread drops it, something
-that is often required, and for which we have no other easy mechanism.
+Regarding the <tt>std::distance</tt> - function, 24.4.4 [iterator.operations]
+/ 4 says:
 </p>
+<blockquote>
+Returns the
+number of increments or decrements needed to get from first to last.
+</blockquote>
 <p>
-Against thread-safety:
+This sentence is completely silent about the sign of the return value.
+24.4.4 [iterator.operations] / 1 gives more information about the
+underlying operations, but
+again no inferences about the sign can be made.
+Strictly speaking, that is taking that sentence literally, I think this
+sentence even implies a positive return value in all cases, as the
+number of increments or decrements is clearly a ratio scale variable,
+with a natural zero bound.
 </p>
 <p>
-The thread-safe version is well-known to be far more expensive, even
-if used by a single thread.  Many applications, including all single-threaded
-ones, do not care.
+Practically speaking, my implementations did what common sense and
+knowledge based on pointer arithmetic forecasts, namely a positive sign
+for increments (that is, going from <tt>first</tt> to <tt>last</tt> by <tt>operator++</tt>), and a
+negative sign for decrements (going from <tt>first</tt> to <tt>last</tt> by <tt>operator--</tt>).
 </p>
-
-<p><i>[
-San Francisco:
-]</i></p>
-
-
-<blockquote>
 <p>
-Beman: this is a complicated issue, and would like to move this to Open
-and await comment from Peter Dimov; we need very careful and complete
-rationale for any decision we make; let's go slow
+Here are my two questions:
 </p>
 <p>
-Detlef: I think that <tt>shared_ptr</tt> should not be thread-safe.
+First, is that paragraph supposed to be interpreted in the way what I
+called 'common sense', that is negative sign for decrements ? I am
+fairly sure that's the supposed behavior, but a double-check here in
+this group can't hurt.
 </p>
 <p>
-Hans: When you create a thread with a lambda, it in some cases makes it
-very difficult for the lambda to reference anything in the heap. It's
-currently ambiguous as to whether you can use a <tt>shared_ptr</tt> to get at an
-object.
+Second, is the present wording (2003 standard version - no idea about
+the draft for the upcoming standard) worth an edit to make it a bit more
+sensible, to mention the sign of the return value explicitly ?
 </p>
+
+<p><i>[
+Daniel adds:
+]</i></p>
+
+
+<blockquote>
 <p>
-Leave in Open. Detlef will submit an alternative proposed resolution
-that makes <tt>shared_ptr</tt> explicitly unsafe.
+My first thought was that resolution <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#204">204</a> would already cover the
+issue report, but it seems that current normative wording is in
+contradiction to that resolution:
 </p>
+
 <p>
-A third option is to support both threadsafe and non-safe share_ptrs,
-and to let the programmer decide which behavior they want.
+Referring to
+<a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>,
+24.4.4 [iterator.operations]/ p.4 says:
 </p>
 
+<blockquote>
+<i>Effects:</i> Returns the number of increments or decrements needed to get
+from <tt>first</tt> to <tt>last</tt>.
+</blockquote>
+
 <p>
-Beman:  Peter, do you support the PR?
+IMO the part " or decrements" is in contradiction to p. 5 which says
 </p>
 
+<blockquote>
+<i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>.
+</blockquote>
+
 <p>
-Peter:
+because "reachable" is defined in X [iterator.concepts]/7 as
 </p>
+
 <blockquote>
+An iterator <tt>j</tt> is called reachable from an iterator <tt>i</tt> if and only if
+there is a finite
+sequence of applications of the expression <tt>++i</tt> that makes <tt>i == j</tt>.[..]
+</blockquote>
+
 <p>
-Yes, I support the proposed resolution, and I certainly oppose any
-attempts to <tt>make shared_ptr</tt> thread-unsafe.
+Here is wording that would be consistent with this definition of "reachable":
 </p>
+
 <p>
-I'd mildly prefer if
+Change 24.4.4 [iterator.operations] p4 as follows:
 </p>
+
 <blockquote>
-[<i>Note:</i> This is true in spite of that fact that such functions often
-modify <tt>use_count()</tt> <i>--end note</i>]
+<i>Effects:</i> Returns the number of increments <del>or decrements</del>
+needed to get from <tt>first</tt> to <tt>last</tt>.
 </blockquote>
-<p>
-is changed to
-</p>
-<blockquote>
-[<i>Note:</i> This is true in spite of that fact that such functions often
-cause a change in <tt>use_count()</tt> <i>--end note</i>]
+
 </blockquote>
+
 <p>
-(or something along these lines) to emphasise that <tt>use_count()</tt> is not,
-conceptually, a variable, but a return value.
+Thomas adds more discussion and an alternative view point
+<a href="http://groups.google.com/group/comp.std.c++/browse_thread/thread/e8e46dcda0a5d797#">here</a>.
 </p>
-</blockquote>
 
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+The proposed wording below was verbally agreed to.  Howard provided.
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt
+Batavia (2009-05):
 ]</i></p>
 
-
 <blockquote>
 <p>
-Vote: Do we want one thread-safe shared pointer or two? If two, one
-would allow concurrent construction and destruction of shared pointers,
-and one would not be thread-safe. If one, then it would be thread-safe.
-</p>
-<p>
-No concensus on that vote.
+Pete reports that a recent similar change has been made
+for the <tt>advance()</tt> function.
 </p>
 <p>
-Hans to improve wording in consultation with Pete. Leave Open.
+We agree with the proposed resolution.
+Move to Tentatively Ready.
 </p>
 </blockquote>
 
+<p><i>[
+2009-07 Frankfurt
+]</i></p>
 
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Make it explicitly thread-safe, in this weak sense, as I believe was intended:
-</p>
-<p>
-Insert in 20.8.10.2 [util.smartptr.shared], before p5:
-</p>
 <blockquote>
-<p>
-For purposes of determining the presence of a data race,
-member functions do not modify <tt>const shared_ptr</tt> and
-const <tt>weak_ptr</tt> arguments, nor any objects they
-refer to.  [<i>Note:</i> This is true in spite of that fact that such functions often
-cause a change in <tt>use_count()</tt> <i>--end note</i>]
-</p>
+Moved from Tentatively Ready to Open only because the wording needs to be
+tweaked for concepts removal.
 </blockquote>
-<p>
-On looking at the text, I'm not sure we need a similar disclaimer
-anywhere else, since nothing else has the problem with the modified
-<tt>use_count()</tt>.  I think Howard arrived at a similar conclusion.
-</p>
 
+<p><i>[
+2009-07 Frankfurt:
+]</i></p>
 
 
+<blockquote>
+Leave Open pending arrival of a post-Concepts WD.
+</blockquote>
 
+<p><i>[
+2009-10-14 Daniel provided de-conceptified wording.
+]</i></p>
 
-<hr>
-<h3><a name="897"></a>897. Forward_list issues... Part 2</h3>
-<p><b>Section:</b> 23.3.3.4 [forwardlist.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-09-22  <b>Last modified:</b> 2009-07-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-This issue was split off from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a> at the request of the LWG.
-</p>
 
 <p><i>[
-San Francisco:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-<p>
-This issue is more complicated than it looks.
-</p>
-<p>
-paragraph 47: replace each <tt>(first, last) with (first, last]</tt>
-</p>
-<p>
-add a statement after paragraph 48 that complexity is O(1)
-</p>
-<p>
-remove the complexity statement from the first overload of splice_after
-</p>
-<p>
-We may have the same problems with other modifiers, like erase_after.
-Should it require that all iterators in the range (position, last] be
-dereferenceable?
-</p>
+Move to Ready, replacing the Effects clause in the proposed wording with
+"If InputIterator meets the requirements of random access iterator then
+returns (last - first), otherwise returns the number of increments
+needed to get from first to list.".
 </blockquote>
 
-<p>
-There are actually 3 issues here:
-</p>
 
+
+<p><b>Proposed resolution:</b></p>
 <ol>
 <li>
 <p>
-What value should <tt>erase_after</tt> return?  With <tt>list</tt>, code often
-looks like:
-</p>
-<blockquote><pre>for (auto i = l.begin(); i != l.end();)
-{
-    // inspect *i and decide if you want to erase it
-    // ...
-    if (I want to erase *i)
-        i = l.erase(i);
-    else
-        ++i;
-}
-</pre></blockquote>
-<p>
-I.e. the iterator returned from <tt>erase</tt> is useful for setting up the
-logic for operating on the next element.  For <tt>forward_list</tt> this might
-look something like:
+Change 24.2.5 [random.access.iterators], Table 105 as indicated [This change is not
+essential but it simplifies the specification] for the row with
+expression "<tt>b - a</tt>"
+and the column Operational semantics:
 </p>
-<blockquote><pre>auto i = fl.before_begin();
-auto ip1 = i;
-for (++ip1; ip1 != fl.end(); ++ip1)
-{
-    // inspect *(i+1) and decide if you want to erase it
-    // ...
-    if (I want to erase *(i+1))
-        i = fl.erase_after(i);
-    else
-        ++i;
-    ip1 = i;
-}
+
+<blockquote><pre><del>(a &lt; b) ? </del>distance(a,b)
+<del>: -distance(b,a)</del>
 </pre></blockquote>
-<p>
-In the above example code, it is convenient if <tt>erase_after</tt> returns
-the element <i>prior</i> to the erased element (range) instead of the element
-<i>after</i> the erase element (range).
-</p>
-<p>
-Existing practice:
-</p>
-<ul>
-<li>SGI slist returns an iterator referencing the element <i>after</i> the erased range.</li>
-<li>CodeWarrior slist returns an iterator referencing the element <i>before</i> the erased range.</li>
-</ul>
-<p>
-There is not a strong technical argument for either solution over the other.
-</p>
 </li>
 
 <li>
 <p>
-With all other containers, operations always work on the range
-<tt>[first, last)</tt> and/or <i>prior to</i> the given <tt>position</tt>.
-</p>
-<p>
-With <tt>forward_list</tt>, operations sometimes work on the range
-<tt>(first, last]</tt> and/or <i>after</i> the given <tt>position</tt>.
-</p>
-<p>
-This is simply due to the fact that in order to operate on
-<tt>*first</tt> (with <tt>forward_list</tt>) one needs access to
-<tt>*(first-1)</tt>.  And that's not practical with
-<tt>forward_list</tt>.  So the operating range needs to start with <tt>(first</tt>,
-not <tt>[first</tt> (as the current working paper says). 
-</p>
-<p>
-Additionally, if one is interested in  splicing the range <tt>(first, last)</tt>,
-then (with <tt>forward_list</tt>), one needs practical (constant time) access to
-<tt>*(last-1)</tt> so that one can set the <i>next</i> field in this node to
-the proper value.  As this is not possible with <tt>forward_list</tt>, one must
-specify the last element of interest instead of one past the last element of
-interest.  The syntax for doing this is to pass <tt>(first, last]</tt> instead
-of <tt>(first, last)</tt>.
+Change 24.4.4 [iterator.operations]/4+5 as indicated:
 </p>
+
+<blockquote><pre>template&lt;class InputIterator&gt;
+  typename iterator_traits&lt;InputIterator&gt;::difference_type
+    distance(InputIterator first, InputIterator last);
+</pre>
+<blockquote>
 <p>
-With <tt>erase_after</tt> we have a choice of either erasing the range
-<tt>(first, last]</tt> <em>or</em> <tt>(first, last)</tt>.  Choosing the latter
-enables:
+4 <i>Effects:</i> <ins>If <tt>InputIterator</tt> meets the requirements
+of random access iterator then returns <tt>(last - first)</tt>,
+otherwise</ins> <del>R</del><ins>r</ins>eturns the number of increments
+<del>or decrements</del> needed to get from <tt>first</tt> to
+<tt>last</tt>.
 </p>
-<blockquote><pre>x.erase_after(pos, x.end());
-</pre></blockquote>
 
 <p>
-With the former, the above statement is inconvenient or expensive due to the lack
-of constant time access to <tt>x.end()-1</tt>.  However we could introduce:
+5 <i>Requires:</i> <ins>If <tt>InputIterator</tt> meets the requirements
+of random access iterator then <tt>last</tt> shall be reachable from
+<tt>first</tt> or <tt>first</tt> shall be reachable from <tt>last</tt>,
+otherwise</ins> <tt>last</tt> shall be reachable from <tt>first</tt>.
 </p>
+</blockquote>
+</blockquote>
+</li>
+</ol>
 
-<blockquote><pre>iterator erase_to_end(const_iterator position);
-</pre></blockquote>
 
-<p>
-to compensate.
-</p>
 
-<p>
-The advantage of the former (<tt>(first, last]</tt>) for <tt>erase_after</tt>
-is a consistency with <tt>splice_after</tt> which uses <tt>(first, last]</tt>
-as the specified range.  But this either requires the addition of <tt>erase_to_end</tt>
-or giving up such functionality.
-</p>
 
-</li>
 
-<li>
-As stated in the discussion of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>, and reienforced by point 2 above,
-a <tt>splice_after</tt> should work on the source range <tt>(first, last]</tt>
-if the operation is to be <i>&#927;</i>(1).  When splicing an entire list <tt>x</tt> the
-algorithm needs <tt>(x.before_begin(), x.end()-1]</tt>.  Unfortunately <tt>x.end()-1</tt>
-is not available in constant time unless we specify that it must be.  In order to
-make <tt>x.end()-1</tt> available in constant time, the implementation would have
-to dedicate a pointer to it.  I believe the design of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2543.htm">N2543</a>
-intended a nominal overhead of <tt>foward_list</tt> of 1 pointer.  Thus splicing
-one <i>entire</i> <tt>forward_list</tt> into another can not be <i>&#927;</i>(1).
-</li>
-</ol>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
 
-<blockquote>
-<p>
-We agree with the proposed resolution.
-</p>
+
+
+<hr>
+<h3><a name="950"></a>950. unique_ptr converting ctor shouldn't accept array form</h3>
+<p><b>Section:</b> 20.8.14.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-21</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.ctor">active issues</a> in [unique.ptr.single.ctor].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Move to Review.
+<tt>unique_ptr</tt>'s of array type should not convert to
+<tt>unique_ptr</tt>'s which do not have an array type.
 </p>
-</blockquote>
+
+<blockquote><pre>struct Deleter
+{
+   void operator()(void*) {}
+};
+
+int main()
+{
+   unique_ptr&lt;int[], Deleter&gt; s;
+   unique_ptr&lt;int, Deleter&gt; s2(std::move(s));  <font color="#c80000">// should not compile</font>
+}
+</pre></blockquote>
 
 <p><i>[
-2009-07 Frankfurt
+Post Summit:
 ]</i></p>
 
 
 <blockquote>
 <p>
-We may need a new issue to correct splice_after, because it may no
-longer be correct to accept an rvalues as an argument. Merge may be
-affected, too. This might be issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1133">1133</a>. (Howard: confirmed)
-</p>
-<p>
-Move this to Ready, but the Requires clause of the second form of
-splice_after should say "(first, last)," not "(first, last]" (there are
-three occurrences). There was considerable discussion on this. (Howard: fixed)
-</p>
-<p>
-Alan suggested removing the "foward_last&lt;T. Alloc&gt;&amp;&amp; x"
-parameter from the second form of splice_after, because it is redundant.
-PJP wanted to keep it, because it allows him to check for bad ranges
-(i.e. "Granny knots").
-</p>
-<p>
-We prefer to keep <tt>x</tt>.
+Walter: Does the "diagnostic required" apply to both arms of the "and"?
 </p>
 <p>
-Beman. Whenever we deviate from the customary half-open range in the
-specification, we should add a non-normative comment to the standard
-explaining the deviation. This clarifies the intention and spares the
-committee much confusion in the future.
+Tom Plum: suggest to break into several sentences
 </p>
 <p>
-Alan to write a non-normative comment to explain the use of fully-closed ranges.
+Walter: suggest "comma" before the "and" in both places
 </p>
 <p>
-Move to Ready, with the changes described above. (Howard: awaiting note from Alan)
+Recommend Review.
 </p>
 </blockquote>
 
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Wording below assumes issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a> is accepted, but this issue is
-independent of that issue.
+<blockquote>
+The post-Summit comments have been applied to the proposed resolution.
+We now agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+<p><i>[
+2009-07 Frankfurt
+]</i></p>
+
+
+<blockquote>
+Moved from Tentatively Ready to Open only because the wording needs to be
+improved for enable_if type constraining, possibly following Robert's
+formula.
+</blockquote>
+
+<p><i>[
+2009-08-01 Howard updates wording and sets to Review.
+]</i></p>
+
+
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
+
+<blockquote>
+Move to Ready.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.8.14.2.1 [unique.ptr.single.ctor]:
+</p>
+
+<blockquote>
+<pre>template &lt;class U, class E&gt; unique_ptr(unique_ptr&lt;U, E&gt;&amp;&amp; u);
+</pre>
+<blockquote>
+<p>
+-20- <i>Requires:</i> If <tt>D</tt> is not a reference type,
+construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
+shall be well formed and shall not throw an exception. <del>If <tt>D</tt> is
+a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>
+(diagnostic required). <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be
+implicitly convertible to <tt>pointer</tt>. [<i>Note:</i> These requirements
+imply that <tt>T</tt> and <tt>U</tt> are complete types. &#8212; <i>end note</i>]</del>
 </p>
 
+<p><ins>
+<i>Remarks:</i> If <tt>D</tt> is
+a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>, else this
+constructor shall not participate in overload resolution. <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be
+implicitly convertible to <tt>pointer</tt>, else this
+constructor shall not participate in overload resolution. <tt>U</tt> shall not be
+an array type, else this
+constructor shall not participate in overload resolution. [<i>Note:</i> These requirements
+imply that <tt>T</tt> and <tt>U</tt> are complete types. &#8212; <i>end note</i>]
+</ins></p>
+
+</blockquote>
+</blockquote>
+
 <p>
-Change 23.3.3.4 [forwardlist.modifiers]:
+Change 20.8.14.2.3 [unique.ptr.single.asgn]:
 </p>
 
 <blockquote>
-<pre>iterator erase_after(const_iterator position);
+<pre>template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u);
 </pre>
 <blockquote>
 <p>
-<i>Requires:</i> The iterator following <tt>position</tt> is dereferenceable.
+-6- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
+<tt>D</tt> shall not throw an exception. <del><tt>unique_ptr&lt;U,
+E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>.
+[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
+are complete types. &#8212; <i>end note</i>]</del>
 </p>
+
+<p><ins>
+<i>Remarks:</i> <tt>unique_ptr&lt;U,
+E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>, else this
+operator shall not participate in overload resolution.
+<tt>U</tt> shall not be an array type, else this
+operator shall not participate in overload resolution.
+[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
+are complete types. &#8212; <i>end note</i>]
+</ins></p>
+
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="951"></a>951. Various threading bugs #1</h3>
+<p><b>Section:</b> 20.9.2.1 [time.traits.is_fp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
 <p>
-<i>Effects:</i> Erases the element pointed to by the iterator following <tt>position</tt>.
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>.
 </p>
+
 <p>
-<i>Returns:</i> <del>An iterator pointing to the element following the one that was erased, or <tt>end()</tt> if no such 
-element exists</del>
-<ins>An iterator equal to <tt>position</tt></ins>.
+20.9.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>
 
-<pre>iterator erase_after(const_iterator position, <ins>const_</ins>iterator last);
-</pre>
 <blockquote>
 <p>
-<i>Requires:</i> All iterators in the range
-<tt><del>[</del><ins>(</ins>position,last)</tt>
-are dereferenceable.
+As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
-<i>Effects:</i> Erases the elements in the range
-<tt><del>[</del><ins>(</ins>position,last)</tt>.
+We look forward to proposed wording.
 </p>
 <p>
-<i>Returns:</i>  <ins>An iterator equal to <tt>position</tt></ins> <del><tt>last</tt></del>
+Move to Open.
 </p>
 </blockquote>
-</blockquote>
 
-<p>
-Change 23.3.3.5 [forwardlist.ops]:
-</p>
+<p><i>[
+2009-08-01 Howard adds:
+]</i></p>
+
 
-<blockquote>
-<pre>void splice_after(const_iterator position, forward_list&lt;T,Allocator&gt;&amp;&amp; x);
-</pre>
 <blockquote>
 <p>
-<i>Requires:</i> <tt>position</tt> is <tt>before_begin()</tt> or a
-dereferenceable iterator in the range <tt>[begin(), end))</tt>. <tt>&amp;x != this</tt>.
+I have surveyed all clauses of 20.9.2.2 [time.traits.duration_values],
+20.9.2.3 [time.traits.specializations] and 20.9.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>
-<i>Effects:</i> Inserts the contents of <tt>x</tt> after <tt>position</tt>, and
-<tt>x</tt> becomes empty. 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>. 
+Indeed, <tt>treat_as_floating_point</tt>
+becomes completely superfluous if <tt>duration::rep</tt> can never be a class type.
 </p>
+
 <p>
-<i>Throws:</i> Nothing. 
+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>
-<i>Complexity:</i> <del><i>&#927;</i>(1)</del> <ins><i>&#927;</i>(<tt>distance(x.begin(), x.end())</tt>)</ins>
+In 20.9.2.1 [time.traits.is_fp] p1:
 </p>
-</blockquote>
-
-<p>...</p>
 
-<pre>void splice_after(const_iterator position, forward_list&lt;T,Allocator&gt;&amp;&amp; x, 
-                  const_iterator first, const_iterator last);
+<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>
-<i>Requires:</i> <tt>position</tt> is <tt>before_begin()</tt> or a
-dereferenceable iterator in the range <tt>[begin(), end))</tt>.
-<tt>(first,last)</tt> is a valid range in
-<tt>x</tt>, and all iterators in the range
-<tt>(first,last)</tt> are dereferenceable.
-<tt>position</tt> is not an iterator in the range <tt>(first,last)</tt>.
+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>Effects:</i> Inserts elements in the range <tt>(first,last)</tt>
-after <tt>position</tt> and removes the elements from <tt>x</tt>.
-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>.
+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.9 [time] without firmly grounded and
+documented rationale, example implementation, testing, and user
+experience which relates a positive experience.
 </p>
+
 <p>
-<ins><i>Complexity:</i> <i>&#927;</i>(1).</ins>
+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><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
 
 
 
 <hr>
-<h3><a name="900"></a>900. stream move-assignment</h3>
-<p><b>Section:</b> 27.9.1.8 [ifstream.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-09-20  <b>Last modified:</b> 2009-07-26</p>
+<h3><a name="953"></a>953. Various threading bugs #3</h3>
+<p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>
-It
-appears that we have an issue similar to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a> regarding the move-assignment of
-stream types. For example, when assigning to an <tt>std::ifstream</tt>,
-<tt>ifstream1</tt>, it seems preferable to close the file originally held by
-<tt>ifstream1</tt>:
-</p>
-
-<blockquote><pre>ifstream1 = std::move(ifstream2); 
-</pre></blockquote>
 
 <p>
-The current Draft
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
-specifies that the move-assignment of
-stream types like <tt>ifstream</tt> has the same effect as a swap:
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>.
 </p>
 
-<blockquote>
 <p>
-Assign and swap 27.9.1.8 [ifstream.assign]
+20.9.1 [time.clock.req] says that a clock's <tt>rep</tt> member is "an
+arithmetic type or a class emulating an arithmetic type." What are the
+requirements for such a type?
 </p>
-<pre>basic_ifstream&amp; operator=(basic_ifstream&amp;&amp; rhs); 
-</pre>
+
+<p><i>[
+2009-05-10 Howard adds:
+]</i></p>
+
+
 <blockquote>
-<i>Effects:</i> <tt>swap(rhs)</tt>.
-</blockquote>
+This wording was aimed directly at the <tt>ArithmeticLike</tt> concept.
 </blockquote>
 
 <p><i>[
@@ -15651,374 +13069,407 @@ Batavia (2009-05):
 
 <blockquote>
 <p>
-Howard agrees with the analysis and the direction proposed.
+We recommend this issue be addressed in the context of providing concepts
+for the entire <tt>thread</tt> header.
 </p>
 <p>
-Move to Open pending specific wording to be supplied by Howard.
+May resolve for now by specifying arithmetic types,
+and in future change to <tt>ArithmeticLike</tt>.
+However, Alisdair believes this is not feasible.
+</p>
+<p>
+Bill disagrees.
+</p>
+<p>
+We look forward to proposed wording.  Move to Open.
 </p>
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+2009-08-01 Howard adds:
 ]</i></p>
 
 
 <blockquote>
-Howard is going to write wording.
+See commented dated 2009-08-01 in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>.
 </blockquote>
 
 <p><i>[
-2009-07-26 Howard provided wording.
+2009-10 Santa Cruz:
 ]</i></p>
 
 
+<blockquote>
+Stefanus to provide wording to turn this into a note.
+</blockquote>
 
 
-<p><b>Proposed resolution:</b></p>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-Change 27.8.1.2 [stringbuf.assign]/1:
 </p>
 
-<blockquote><pre>basic_stringbuf&amp; operator=(basic_stringbuf&amp;&amp; rhs);
-</pre>
-<blockquote>
--1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
-<ins>After the move assignment <tt>*this</tt> reflects the same observable
-state it would have if it had been move constructed from <tt>rhs</tt>
-(27.8.1.1 [stringbuf.cons]).
-</ins>
-</blockquote>
-</blockquote>
 
-<p>
-Change 27.8.2.2 [istringstream.assign]/1:
-</p>
 
-<blockquote><pre>basic_istringstream&amp; operator=(basic_istringstream&amp;&amp; rhs);
-</pre>
-<blockquote>
--1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
-<ins>Move assigns the base and members of <tt>*this</tt> with the respective
-base and members of <tt>rhs</tt>.
-</ins>
-</blockquote>
-</blockquote>
 
+
+<hr>
+<h3><a name="954"></a>954. Various threading bugs #4</h3>
+<p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-21</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Change 27.8.3.2 [ostringstream.assign]/1:
+Table 55 -- Clock Requirements (in 20.9.1 [time.clock.req])
 </p>
 
-<blockquote><pre>basic_ostringstream&amp; operator=(basic_ostringstream&amp;&amp; rhs);
-</pre>
-<blockquote>
--1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
-<ins>Move assigns the base and members of <tt>*this</tt> with the respective
-base and members of <tt>rhs</tt>.
-</ins>
-</blockquote>
-</blockquote>
+<ol type="a">
+<li>
+the requirements for <tt>C1::time_point</tt> require <tt>C1</tt> and <tt>C2</tt>
+to "refer to the same epoch", but "epoch" is not defined.
+</li>
+<li>
+"Different clocks may share a <tt>time_point</tt> definition if it is
+valid to compare their <tt>time_point</tt>s by comparing their
+respective <tt>duration</tt>s." What does "valid" mean here? And, since
+<tt>C1::rep</tt> is "**THE** representation type of the native
+<tt>duration</tt> and <tt>time_point</tt>" (emphasis added), there
+doesn't seem to be much room for some other representation.
+</li>
+<li>
+<tt>C1::is_monotonic</tt> has type "<tt>const bool</tt>". The
+"<tt>const</tt>" should be removed.
+</li>
+<li>
+<tt>C1::period</tt> has type <tt>ratio</tt>. <tt>ratio</tt> isn't a type, 
+it's a template. What is the required type?
+</li>
+</ol>
 
-<p>
-Change 27.8.5.1 [stringstream.assign]/1:
-</p>
+<p><i>[
+2009-05-10 Howard adds:
+]</i></p>
 
-<blockquote><pre>basic_stringstream&amp; operator=(basic_stringstream&amp;&amp; rhs);
-</pre>
-<blockquote>
--1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
-<ins>Move assigns the base and members of <tt>*this</tt> with the respective
-base and members of <tt>rhs</tt>.
-</ins>
-</blockquote>
-</blockquote>
 
+<ol type="a">
+<li>
 <p>
-Change 27.9.1.3 [filebuf.assign]/1:
+"epoch" is purposefully not defined beyond the common English
+<a href="http://www.dictionary.net/epoch">definition</a>.  The C standard
+also chose not to define epoch, though POSIX did.  I believe it is a strength
+of the C standard that epoch is not defined.  When it is known that two <tt>time_point</tt>s
+refer to the same epoch, then a definition of the epoch is not needed to compare
+the two <tt>time_point</tt>s, or subtract them.
 </p>
-
-<blockquote><pre>basic_filebuf&amp; operator=(basic_filebuf&amp;&amp; rhs);
-</pre>
-<blockquote>
--1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
-<ins>Begins by calling <tt>this-&gt;close()</tt>.
-After the move assignment <tt>*this</tt> reflects the same observable
-state it would have if it had been move constructed from <tt>rhs</tt>
-(27.9.1.2 [filebuf.cons]).
-</ins>
-</blockquote>
-</blockquote>
-
 <p>
-Change 27.9.1.8 [ifstream.assign]/1:
+A <tt>time_point</tt> and a <tt>Clock</tt> implicitly refer to an (unspecified) epoch.
+The <tt>time_point</tt> represents an offset (<tt>duration</tt>) from an epoch.
+</p>
+</li>
+<li>
+<p>
+The sentence:
 </p>
-
-<blockquote><pre>basic_ifstream&amp; operator=(basic_ifstream&amp;&amp; rhs);
-</pre>
 <blockquote>
--1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
-<ins>Move assigns the base and members of <tt>*this</tt> with the respective
-base and members of <tt>rhs</tt>.</ins>
-</blockquote>
+Different clocks 
+may share a <tt>time_point</tt>
+definition if it is valid to 
+compare their <tt>time_point</tt>s by 
+comparing their respective 
+<tt>duration</tt>s.
 </blockquote>
 
 <p>
-Change 27.9.1.12 [ofstream.assign]/1:
+is redundant and could be removed.  I believe the sentence which follows the above:
 </p>
 
-<blockquote><pre>basic_ofstream&amp; operator=(basic_ofstream&amp;&amp; rhs);
-</pre>
 <blockquote>
--1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
-<ins>Move assigns the base and members of <tt>*this</tt> with the respective
-base and members of <tt>rhs</tt>.</ins>
-</blockquote>
+<tt>C1</tt> and <tt>C2</tt> shall refer to the same epoch.
 </blockquote>
 
 <p>
-Change 27.9.1.16 [fstream.assign]/1:
+is sufficient.  If two clocks share the same epoch, then by definition, comparing
+their <tt>time_point</tt>s is valid.
+</p>
+</li>
+<li>
+<tt>is_monotonic</tt> is meant to never change (be <tt>const</tt>).  It is also
+desired that this value be usable in compile-time computation and branching.
+</li>
+<li>
+<p>
+This should probably instead be worded:
 </p>
-
-<blockquote><pre>basic_fstream&amp; operator=(basic_fstream&amp;&amp; rhs);
-</pre>
 <blockquote>
--1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
-<ins>Move assigns the base and members of <tt>*this</tt> with the respective
-base and members of <tt>rhs</tt>.</ins>
-</blockquote>
+An instantiation of <tt>ratio</tt>.
 </blockquote>
+</li>
+</ol>
 
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
+<blockquote>
+<p>
+Re (a): It is not clear to us whether "epoch" is a term of art.
+</p>
+<p>
+Re (b), (c), and (d):  We agree with Howard's comments,
+and would consider adding to (c) a <tt>static constexpr</tt> requirement.
+</p>
+<p>
+Move to Open pending proposed wording.
+</p>
+</blockquote>
 
+<p><i>[
+2009-05-25 Daniel adds:
+]</i></p>
 
 
+<blockquote>
+In regards to (d) I suggest to say "a specialization of ratio" instead of
+"An instantiation of ratio". This seems to be the better matching standard
+core language term for this kind of entity.
+</blockquote>
 
-<hr>
-<h3><a name="908"></a>908. Deleted assignment operators for atomic types must be volatile</h3>
-<p><b>Section:</b> 29.5 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-09-26  <b>Last modified:</b> 2009-03-22</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><i>[
+2009-05-25 Ganesh adds:
+]</i></p>
 
-<p><b>Addresses US 90</b></p>
 
+<blockquote>
 <p>
-The deleted copy-assignment operators for the atomic types are not
-marked as volatile in N2723, whereas the assignment operators from the
-associated non-atomic types are. e.g.
+Regarding (a), I found this paper on the ISO website using the term "epoch" consistently with the current wording:
 </p>
-<blockquote><pre>atomic_bool&amp; operator=(atomic_bool const&amp;) = delete;
-atomic_bool&amp; operator=(bool) volatile;
-</pre></blockquote>
 
 <p>
-This leads to ambiguity when assigning a non-atomic value to a
-non-volatile instance of an atomic type:
+<a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM">http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM</a>
 </p>
-<blockquote><pre>atomic_bool b;
-b=false;
-</pre></blockquote>
-
 <p>
-Both assignment operators require a standard conversions: the
-copy-assignment operator can use the implicit <tt>atomic_bool(bool)</tt>
-conversion constructor to convert <tt>false</tt> to an instance of
-<tt>atomic_bool</tt>, or <tt>b</tt> can undergo a qualification conversion in order to
-use the assignment from a plain <tt>bool</tt>.
+which is part of ISO/IEC 18026 "Information technology -- Spatial Reference Model (SRM)".
 </p>
+</blockquote>
+
+<p><i>[
+2009-08-01 Howard: Moved to Reivew as the wording requested in Batavia has been provided.
+]</i></p>
 
-<p>
-This is only a problem once issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a> is applied.
-</p>
 
 <p><i>[
-Summit:
+2009-10 Santa Cruz:
 ]</i></p>
 
+
 <blockquote>
-Move to open. Assign to Lawrence. Related to US 90 comment.
+Move to Ready.
 </blockquote>
 
 
+
 <p><b>Proposed resolution:</b></p>
+<ol type="a">
+<li>
 <p>
-Add volatile qualification to the deleted copy-assignment operator of
-all the atomic types:
+Change 20.9.1 [time.clock.req] p1:
 </p>
-
-<blockquote><pre>atomic_bool&amp; operator=(atomic_bool const&amp;) <ins>volatile</ins> = delete;
-atomic_itype&amp; operator=(atomic_itype const&amp;) <ins>volatile</ins> = delete;
-</pre></blockquote>
-
+<blockquote>
+-1- A clock is a bundle consisting of a native <tt>duration</tt>, a native <tt>time_point</tt>, and a function <tt>now()</tt> to get the 
+current <tt>time_point</tt>.  <ins>The origin of the clock's <tt>time_point</tt> is referred to as the clock's <i>epoch</i> as defined in 
+section 6.3 of ISO/IEC 18026.</ins>
+A clock shall meet the requirements in Table 45.
+</blockquote>
+</li>
+<li>
 <p>
-etc.
+Remove the sentence from the <tt>time_point</tt> row of the table "Clock Requirements":
 </p>
+<table border="1">
+<caption>Clock requirements</caption>
+<tbody><tr>
+<td>
+<tt>C1::time_point</tt>
+</td>
+<td>
+<tt>chrono::time_point&lt;C1&gt;</tt> or <tt>chrono::time_point&lt;C2, C1::duration&gt;</tt>
+</td>
+<td>
+The native <tt>time_point</tt> type of the clock.
+<del>Different clocks may share a <tt>time_point</tt> definition if it is valid to compare their <tt>time_point</tt>s by comparing their respective <tt>duration</tt>s.</del>
+<tt>C1</tt> and <tt>C2</tt> shall refer to the same epoch.
+</td>
+</tr>
+</tbody></table>
+</li>
+</ol>
+<ol start="4" type="a">
+<li>
 <p>
-This will mean that the deleted copy-assignment operator will require
-<i>two</i> conversions in the above example, and thus be a worse match than
-the assignment from plain <tt>bool</tt>.
+Change the row starting with <tt>C1::period</tt> of the table "Clock Requirements":
 </p>
+<table border="1">
+<caption>Clock requirements</caption>
+<tbody><tr>
+<td>
+<tt>C1::period</tt>
+</td>
+<td>
+<ins>a specialization of</ins> <tt>ratio</tt>
+</td>
+<td>
+The tick period of the clock in seconds.
+</td>
+</tr>
+</tbody></table>
+
+</li>
+</ol>
 
 
 
 
 
 <hr>
-<h3><a name="910"></a>910. Effects of MoveAssignable</h3>
-<p><b>Section:</b> 20.2.9 [concept.copymove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-09-29  <b>Last modified:</b> 2009-07-18</p>
+<h3><a name="956"></a>956. Various threading bugs #6</h3>
+<p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-24</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
-<p><b>Addresses UK 150</b></p>
-
 <p>
-The description of the effect of <tt>operator=</tt> in the <tt>MoveAssignable</tt>
-concept, given in paragraph 7 is:
+20.9.1 [time.clock.req] uses the word "native" in several places,
+but doesn't define it. What is a "native <tt>duration</tt>"?
 </p>
 
-<blockquote><pre>result_type  T::operator=(T&amp;&amp;  rv);  // inherited from HasAssign&lt;T, T&amp;&amp;&gt;
-</pre>
+<p><i>[
+2009-05-10 Howard adds:
+]</i></p>
+
 
 <blockquote>
-<i>Postconditions:</i> the constructed <tt>T</tt> object is equivalent to the value of
-<tt>rv</tt> before the assignment. [<i>Note:</i> there is no
-requirement on the value of <tt>rv</tt> after the assignment.  <i>--end note</i>]
-</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>
-The sentence contains a typo (what is the "constructed <tt>T</tt> object"?)
-probably due to a cut&amp;paste from <tt>MoveConstructible</tt>. Moreover, the
-discussion of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a> shows that the postcondition is too generic
-and might not reflect the user expectations. An implementation of the
-move assignment that just calls <tt>swap()</tt> would always fulfill the
-postcondition as stated, but might have surprising side-effects in case
-the source rvalue refers to an object that is not going to be
-immediately destroyed. See LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a> for another example. Due to
-the sometimes intangible nature of the "user expectation", it seems
-difficult to have precise normative wording that could cover all cases
-without introducing unnecessary restrictions. However a non-normative
-clarification could be a very helpful warning sign that swapping is not
-always the correct thing to do.
-</p>
-
 <p><i>[
-2009-05-09 Alisdair adds:
+Batavia (2009-05):
 ]</i></p>
 
-
 <blockquote>
-<p>
-Issue 910 is exactly the reason BSI advanced the Editorial comment UK-150.
-</p>
-<p>
-The post-conditions after assignment are at a minimum that the object
-referenced by rv must be safely destructible, and the transaction should not
-leak resources.  Ideally it should be possible to simply assign rv a new
-valid state after the call without invoking undefined behaviour, but any
-other use of the referenced object would depend upon additional guarantees
-made by that type.
-</p>
+Move to Open pending proposed wording from Pete.
 </blockquote>
 
 <p><i>[
-2009-05-09 Howard adds:
+2009-10-23 Pete provides wording:
 ]</i></p>
 
 
-<blockquote>
-<p>
-The intent of the rvalue reference work is that the moved from <tt>rv</tt> is
-a valid object.  Not one in a singular state.  If, for example, the moved from
-object is a <tt>vector</tt>, one should be able to do anything on that moved-from
-<tt>vector</tt> that you can do with any other <tt>vector</tt>.  However you would
-first have to query it to find out what its current state is.  E.g. it might have <tt>capacity</tt>,
-it might not.  It might have a non-zero <tt>size</tt>, it might not.  But regardless,
-you can <tt>push_back</tt> on to it if you want.
-</p>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-That being said, most standard code is now conceptized.  That is, the concepts
-list the only operations that can be done with templated types - whether or not
-the values have been moved from.
+Remove every occurrence of "native" in 20.9.1 [time.clock.req].
 </p>
 
 <p>
-Here is user-written code which must be allowed to be legal:
+Add the following sentence at the end of 20.9.1 [time.clock.req]/1:
 </p>
-<blockquote><pre>#include &lt;vector&gt;
-#include &lt;cstdio&gt;
 
-template &lt;class Allocator&gt;
-void
-inspect(std::vector&lt;double, Allocator&gt;&amp;&amp; v)
-{
-    std::vector&lt;double, Allocator&gt; result(move(v));
-    std::printf("moved from vector has %u size and %u capacity\n", v.size(), v.capacity());
-    std::printf("The contents of the vector are:\n");
-    typedef typename std::vector&lt;double, Allocator&gt;::iterator I;
-    for (I i = v.begin(), e = v.end(); i != e; ++i)
-        printf("%f\n", *i);
-}
+<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>. A clock
+shall meet the requirements in Table 55.
+<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>
 
-int main()
-{
-    std::vector&lt;double&gt; v1(100, 5.5);
-    inspect(move(v1));
-}
-</pre></blockquote>
 
+
+
+
+<hr>
+<h3><a name="957"></a>957. Various threading bugs #7</h3>
+<p><b>Section:</b> 20.9.5.1 [time.clock.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-21</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.system">issues</a> in [time.clock.system].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-The above program does not treat the moved-from <tt>vector</tt> as singular.  It
-only treats it as a <tt>vector</tt> with an unknown value.
-</p>
-<p>
-I believe the current proposed wording is consistent with my view on this.
+20.9.5.1 [time.clock.system]: <tt>to_time_t</tt> is overspecified. It
+requires truncation, but should allow rounding. For example, suppose a
+system has a clock that gives times in milliseconds, but <tt>time()</tt> rounds
+those times to the nearest second. Then <tt>system_clock</tt> can't use any
+resolution finer than one second, because if it did, truncating times
+between half a second and a full second would produce the wrong <tt>time_t</tt>
+value.
 </p>
-</blockquote>
+
+<p><i>[
+Post Summit Anthony Williams provided proposed wording.
+]</i></p>
+
 
 <p><i>[
 Batavia (2009-05):
 ]</i></p>
 
 <blockquote>
-We agree that the proposed resolution
-is an improvement over the current wording.
+Move to Review pending input from Howard. and other stakeholders.
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+2009-05-23 Howard adds:
 ]</i></p>
 
 
 <blockquote>
-Need to look at again without concepts.
+I am in favor of the wording provided by Anthony.
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Walter will consult with Dave and Doug.
+Move to Ready.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-In 20.2.9 [concept.copymove], replace the postcondition in paragraph 7 with:
+In 20.9.5.1 [time.clock.system] replace paragraphs 3 and 4 with:
 </p>
 
 <blockquote>
-<i>Postconditions:</i> <tt>*this</tt> is equivalent to the value of <tt>rv</tt> before the
-assignment. [<i>Note:</i> there is no requirement on the value of <tt>rv</tt> after the
-assignment, but the
-effect should be unsurprising to the user even in case <tt>rv</tt> is not
-immediately destroyed. This may require that resources previously owned
-by <tt>*this</tt> are released instead of transferred to <tt>rv</tt>. <i>-- end note</i>]
+<pre>time_t to_time_t(const time_point&amp; t);
+</pre>
+<blockquote>
+-3- <i>Returns:</i> A <tt>time_t</tt> object that represents the same
+point in time as <tt>t</tt> when both values are <del>truncated</del>
+<ins>restricted</ins> to the coarser of the precisions of
+<tt>time_t</tt> and <tt>time_point</tt>. <ins> It is implementation
+defined whether values are rounded or truncated to the required
+precision.</ins>
+</blockquote>
+
+<pre>time_point from_time_t(time_t t);
+</pre>
+<blockquote>
+-4- <i>Returns:</i> A <tt>time_point</tt> object that represents the
+same point in time as <tt>t</tt> when both values are <del>truncated</del>
+<ins>restricted</ins> to the
+coarser of the precisions of <tt>time_t</tt> and <tt>time_point</tt>.
+<ins>It is implementation defined whether values are
+rounded or truncated to the required precision.</ins>
+</blockquote>
 </blockquote>
 
 
@@ -16026,351 +13477,345 @@ by <tt>*this</tt> are released instead of transferred to <tt>rv</tt>. <i>-- end
 
 
 <hr>
-<h3><a name="911"></a>911. I/O streams and <tt>move/swap</tt> semantic</h3>
-<p><b>Section:</b> 27.7.1 [input.streams], 27.7.2 [output.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-09-29  <b>Last modified:</b> 2009-07-27</p>
+<h3><a name="959"></a>959. Various threading bugs #9</h3>
+<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Class template <tt>basic_istream</tt>, <tt>basic_ostream</tt> and <tt>basic_iostream</tt>
-implements public move constructors, move assignment operators and <tt>swap</tt>
-method and free functions. This might induce both the user and the
-compiler to think that those types are <tt>MoveConstructible</tt>, <tt>MoveAssignable</tt>
-and <tt>Swappable</tt>. However, those class templates fail to fulfill the user
-expectations. For example:
+30.5.1 [thread.condition.condvar]: <tt>condition_variable::wait_for</tt>
+is required to compute the absolute time by adding the duration value to
+<tt>chrono::monotonic_clock::now()</tt>, but <tt>monotonic_clock</tt> is not required to
+exist.
 </p>
 
-<blockquote><pre>std::ostream os(std::ofstream("file.txt"));
-assert(os.rdbuf() == 0); // buffer object is not moved to os, file.txt has been closed
+<p><i>[
+Summit:
+]</i></p>
 
-std::vector&lt;std::ostream&gt; v;
-v.push_back(std::ofstream("file.txt"));
-v.reserve(100); // causes reallocation
-assert(v[0].rdbuf() == 0); // file.txt has been closed!
 
-std::ostream&amp;&amp; os1 = std::ofstream("file1.txt");
-os1 = std::ofstream("file2.txt");
-os1 &lt;&lt; "hello, world"; // still writes to file1.txt, not to file2.txt!
+<blockquote>
+Move to open. Associate with LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> and any other monotonic-clock
+related issues.
+</blockquote>
 
-std::ostream&amp;&amp; os1 = std::ofstream("file1.txt");
-std::ostream&amp;&amp; os2 = std::ofstream("file2.txt");
-std::swap(os1, os2);
-os1 &lt;&lt; "hello, world"; // writes to file1.txt, not to file2.txt!
-</pre></blockquote>
+<p><i>[
+2009-08-01 Howard adds:
+]</i></p>
 
-<p>
-This is because the move constructor, the move assignment operator and
-<tt>swap</tt> are all implemented through calls to <tt>std::basic_ios</tt> member
-functions <tt>move()</tt> and <tt>swap()</tt> that do not move nor swap the controlled
-stream buffers. That can't happen because the stream buffers may have
-different types.
-</p>
 
-<p>
-Notice that for <tt>basic_streambuf</tt>, the member function <tt>swap()</tt> is
-protected. I believe that is correct and all of <tt>basic_istream</tt>,
-<tt>basic_ostream</tt>, <tt>basic_iostream</tt> should do the same as the move ctor, move
-assignment operator and swap member function are needed by the derived
-<tt>fstream</tt>s and <tt>stringstream</tt>s template. The free swap functions for
-<tt>basic_(i|o|io)stream</tt> templates should be removed for the same reason.
-</p>
+<blockquote>
+I believe that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> (currently Ready) addresses this issue, and
+that this issue should be marked NAD, solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> (assuming
+it moves to WP).
+</blockquote>
 
 <p><i>[
-Batavia (2009-05):
+2009-10 Santa Cruz:
 ]</i></p>
 
+
 <blockquote>
+Leave open, but expect to be fixed by N2969 revision that Detlef is writing.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-We note that the rvalue swap functions have already been removed.
-</p>
-<p>
-Bill is unsure about making the affected functions protected;
-he believes they may need to be public.
-</p>
-<p>
-We are also unsure about removing the lvalue swap functions as proposed.
 </p>
+
+
+
+
+
+<hr>
+<h3><a name="960"></a>960. Various threading bugs #10</h3>
+<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Move to Open.
+30.4.1 [thread.mutex.requirements]: paragraph 4 is entitled
+"Error conditions", but according to 17.5.1.4 [structure.specifications], "Error
+conditions:" specifies "the error conditions for error codes reported by
+the function." It's not clear what this should mean when there is no
+function in sight.
 </p>
-</blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+Summit:
 ]</i></p>
 
 
 <blockquote>
-<p>
-It's not clear that the use case is compelling.
-</p>
-<p>
-Howard: This needs to be implemented and tested.
-</p>
+Move to open.
 </blockquote>
 
 <p><i>[
-2009-07-26 Howard adds:
+Beman provided proposed wording.
+]</i></p>
+
+
+<p><i>[
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
+Move to Ready. Fix the proposed wording with "functions of type Mutex"
+-&gt; "functions of Mutex type"
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-I started out thinking I would recommend NAD for this one.  I've turned around
-to agree with the proposed resolution (which I've updated to the current draft).
-I did not fully understand Ganesh's rationale, and attempt to describe my
-improved understanding below.
+Change 30.4.1 [thread.mutex.requirements] Mutex requirements,
+paragraph 4 as indicated:
 </p>
 
+<blockquote>
 <p>
-The move constructor, move assignment operator, and swap function are different
-for <tt>basic_istream</tt>, <tt>basic_ostream</tt> and <tt>basic_iostream</tt>
-than other classes.  A timely conversation with Daniel reminded me of this long
-forgotten fact.  These members are sufficiently different that they would be
-extremely confusing to use in general, but they are very much needed for derived
-clients.
+-4- <del><i>Error conditions:</i></del>
+<ins>The error conditions for error codes, if any, reported by member
+functions of Mutex type shall be:</ins>
 </p>
-
 <ul>
 <li>
-The move constructor moves everything but the <tt>rdbuf</tt> pointer.
+<tt>not_enough_memory</tt> -- if there is not enough memory to construct
+the mutex object.
 </li>
 <li>
-The move assignment operator moves everything but the <tt>rdbuf</tt> pointer.
+<tt>resource_unavailable_try_again</tt> -- if any native handle type
+manipulated is not available.
 </li>
 <li>
-The swap function swaps everything but the <tt>rdbuf</tt> pointer.
+<tt>operation_not_permitted</tt> -- if the thread does not have the
+necessary permission to change the state of the mutex object.
+</li>
+<li>
+<tt>device_or_resource_busy</tt> -- if any native handle type
+manipulated is already locked.
+</li>
+<li>
+<tt>invalid_argument</tt> -- if any native handle type manipulated as
+part of mutex construction is incorrect.
 </li>
 </ul>
-
-<p>
-The reason for this behavior is that for the std-derived classes (stringstreams,
-filestreams), the <tt>rdbuf</tt> pointer points back into the class itself
-(self referencing).  It can't be swapped or moved.  But this fact isn't born out
-at the <tt>stream</tt> level.  Rather it is born out at the <tt>fstream</tt>/<tt>sstream</tt>
-level.  And the lower levels just need to deal with that fact by not messing around
-with the <tt>rdbuf</tt> pointer which is stored down at the lower levels.
-</p>
-
-<p>
-In a nutshell, it is very confusing for all of those who are not so intimately
-related with streams that they've implemented them.  And it is even fairly
-confusing for some of those who have (including myself).  I do not think it is
-safe to swap or move <tt>istreams</tt> or <tt>ostreams</tt> because this will
-(by necessary design) separate stream state from streambuffer state.  Derived
-classes (such as <tt>fstream</tt> and <tt>stringstream</tt> must be used to
-keep the stream state and stream buffer consistently packaged as one unit during
-a move or swap.
-</p>
-
-<p>
-I've implemented this proposal and am living with it day to day.
-</p>
-
 </blockquote>
 
 
 
-<p><b>Proposed resolution:</b></p>
-<p>
-27.7.1.1 [istream]: make the following member functions protected:
-</p>
 
-<blockquote><pre>basic_istream(basic_istream&amp;&amp;  rhs);
-basic_istream&amp;  operator=(basic_istream&amp;&amp;  rhs);
-void  swap(basic_istream&amp;  rhs);
-</pre></blockquote>
 
+<hr>
+<h3><a name="962"></a>962. Various threading bugs #12</h3>
+<p><b>Section:</b> 30.4.3.2.2 [thread.lock.unique.locking] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.lock.unique.locking">active issues</a> in [thread.lock.unique.locking].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.lock.unique.locking">issues</a> in [thread.lock.unique.locking].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Ditto: remove the swap free function signature
+30.4.3.2.2 [thread.lock.unique.locking]:  <tt>unique_lock::lock</tt> is
+required to throw an object of type <tt>std::system_error</tt> "when the
+postcondition cannot be achieved." The postcondition is <tt>owns == true</tt>,
+and this is trivial to achieve. Presumably, the requirement is intended
+to mean something more than that.
 </p>
 
-<blockquote><pre><del>// swap: 
-template &lt;class charT, class traits&gt; 
-  void swap(basic_istream&lt;charT, traits&gt;&amp; x, basic_istream&lt;charT, traits&gt;&amp; y);</del>
-</pre></blockquote>
-
-<p>
-27.7.1.1.2 [istream.assign]: remove paragraph 4
-</p>
+<p><i>[
+Summit:
+]</i></p>
 
-<blockquote><pre><del>template &lt;class charT, class traits&gt; 
-  void swap(basic_istream&lt;charT, traits&gt;&amp; x, basic_istream&lt;charT, traits&gt;&amp; y);</del>
-</pre>
 <blockquote>
-<del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
-</blockquote>
+Move to open.
 </blockquote>
 
-<p>
-27.7.1.5 [iostreamclass]: make the following member function protected:
-</p>
+<p><i>[
+Beman has volunteered to provide proposed wording.
+]</i></p>
 
-<blockquote><pre>basic_iostream(basic_iostream&amp;&amp;  rhs);
-basic_iostream&amp;  operator=(basic_iostream&amp;&amp;  rhs);
-void  swap(basic_iostream&amp;  rhs);
-</pre></blockquote>
 
-<p>
-Ditto: remove the swap free function signature
-</p>
+<p><i>[
+2009-07-21 Beman added wording to address 30.2.2 [thread.req.exception]
+in response to the Frankfurt notes in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>.
+]</i></p>
 
-<blockquote><pre><del>template &lt;class charT, class traits&gt; 
-  void swap(basic_iostream&lt;charT, traits&gt;&amp; x, basic_iostream&lt;charT, traits&gt;&amp; y);</del>
-</pre></blockquote>
 
-<p>
-27.7.1.5.3 [iostream.assign]: remove paragraph 3
-</p>
+<p><i>[
+2009-09-25 Beman: minor update to wording.
+]</i></p>
 
-<blockquote><pre><del>template &lt;class charT, class traits&gt; 
-  void swap(basic_iostream&lt;charT, traits&gt;&amp; x, basic_iostream&lt;charT, traits&gt;&amp; y);</del>
-</pre>
-<blockquote>
-<del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
-</blockquote>
-</blockquote>
 
-<p>
-27.7.2.1 [ostream]: make the following member function protected:
-</p>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
-<blockquote><pre>basic_ostream(basic_ostream&amp;&amp;  rhs);
-basic_ostream&amp;  operator=(basic_ostream&amp;&amp;  rhs);
-void  swap(basic_ostream&amp;  rhs);
-</pre></blockquote>
 
-<p>
-Ditto: remove the swap free function signature
-</p>
+<blockquote>
+Move to Ready.
+</blockquote>
 
-<blockquote><pre><del>// swap: 
-template &lt;class charT, class traits&gt; 
-  void swap(basic_ostream&lt;charT, traits&gt;&amp; x, basic_ostream&lt;charT, traits&gt;&amp; y);</del>
-</pre></blockquote>
 
-<p>
-27.7.2.3 [ostream.assign]: remove paragraph 4 
-</p>
 
-<blockquote><pre><del>template &lt;class charT, class traits&gt; 
-  void swap(basic_ostream&lt;charT, traits&gt;&amp; x, basic_ostream&lt;charT, traits&gt;&amp; y);</del>
-</pre>
+<p><b>Proposed resolution:</b></p>
+
+<p><i>Change Exceptions 30.2.2 [thread.req.exception] as indicated:</i></p>
 <blockquote>
-<del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
-</blockquote>
+<p>Some functions described in this Clause are specified to throw exceptions of 
+type <code>system_error</code> (19.5.5). Such exceptions shall be thrown if <ins>
+any of the <i>Error conditions</i> are detected or</ins> a call to an operating 
+system or other underlying API results in an error that prevents the library 
+function from <del>satisfying its postconditions or from returning a meaningful 
+value</del> <ins>meeting its specifications</ins>. <ins>Failure to
+allocate storage shall be reported as described in
+17.6.4.11 [res.on.exception.handling].</ins></p>
 </blockquote>
 
+<p><i>Change thread assignment 30.3.1.5 [thread.thread.member], join(), 
+paragraph 8 as indicated:</i></p>
+<blockquote>
+<p><i>Throws:</i> <code>std::system_error</code> when <del>the postconditions cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
 
+</blockquote>
 
+<p><i>Change thread assignment 30.3.1.5 [thread.thread.member], detach(), paragraph 
+13 as indicated:</i></p>
+<blockquote>
 
+<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
+postconditions cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
 
+</blockquote>
 
-<hr>
-<h3><a name="915"></a>915. <tt>minmax</tt> with <tt>initializer_list</tt> should return
-<tt>pair</tt> of <tt>T</tt>, not <tt>pair</tt> of <tt>const T&amp;</tt></h3>
-<p><b>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04  <b>Last modified:</b> 2009-07-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-It seems that the proposed changes for
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2772.pdf">N2772</a>
-were not clear enough in
-this point:
-</p>
+<p><i>Change Mutex requirements 30.4.1 [thread.mutex.requirements], paragraph 
+11, as indicated:</i></p>
+<blockquote>
 
+<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
+postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
+</blockquote>
+<p><i>Change unique_lock locking 30.4.3.2.2 [thread.lock.unique.locking], 
+paragraph 3, as indicated:</i></p>
 <blockquote>
-25.5.7 [alg.min.max], before p.23 + p.24 + before p. 27 + p. 28 say that the return
-type of the <tt>minmax</tt> overloads with an <tt>initializer_list</tt> is
-<tt>pair&lt;const T&amp;, const T&amp;&gt;</tt>,
-which is inconsistent with the decision for the other <tt>min/max</tt> overloads which take
-a <tt>initializer_list</tt> as argument and return a <tt>T</tt>, not a <tt>const T&amp;</tt>.
-Doing otherwise for <tt>minmax</tt> would easily lead to unexpected life-time
-problems by using <tt>minmax</tt> instead of <tt>min</tt> and <tt>max</tt> separately.
+
+<p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
 </blockquote>
+<p><i>Change unique_lock locking 30.4.3.2.2 [thread.lock.unique.locking], 
+paragraph 8, as indicated:</i></p>
+<blockquote>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
+</blockquote>
+<p><i>Change unique_lock locking 30.4.3.2.2 [thread.lock.unique.locking], 
+paragraph 13, as indicated:</i></p>
+<blockquote>
 
+<p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
+</blockquote>
+<p><i>Change unique_lock locking 30.4.3.2.2 [thread.lock.unique.locking], 
+paragraph 18, as indicated:</i></p>
 <blockquote>
-We agree with the proposed resolution.
-Move to Tentatively Ready.
+
+<p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
 </blockquote>
+<p><i>Change unique_lock locking 30.4.3.2.2 [thread.lock.unique.locking], 
+paragraph 22, as indicated:</i></p>
+<blockquote>
 
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
+<p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
+</blockquote>
+<p><i>Change Function call_once 30.4.5.2 [thread.once.callonce], paragraph 4, as 
+indicated</i></p>
+<blockquote>
+  <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>, 
+  or any exception thrown by <code>func</code>.</p>
+</blockquote>
+<p><i>Change Class condition_variable 30.5.1 [thread.condition.condvar], 
+paragraph 12, as indicated:</i></p>
+<blockquote>
 
+<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
+postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
+</blockquote>
+<p><i>Change Class condition_variable 30.5.1 [thread.condition.condvar], 
+paragraph 19, as indicated:</i></p>
+<blockquote>
 
+<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
+postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
+</blockquote>
+<p><i>Change Class condition_variable_any 30.5.2 [thread.condition.condvarany], 
+paragraph 10, as indicated:</i></p>
 <blockquote>
-Moved from Tentatively Ready to Open only because the wording needs to be
-tweaked for concepts removal.
+
+<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
+postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
 </blockquote>
+<p><i>Change Class condition_variable_any 30.5.2 [thread.condition.condvarany], 
+paragraph 16, as indicated:</i></p>
+<blockquote>
 
+<p><i>Throws:</i> <code>std::system_error</code> when <del>the returned value, effects, or 
+postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
+</blockquote>
 
+<p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been 
+applied to the working paper, change Change 30.5.1 [thread.condition.condvar] as 
+indicated:</i></p>
+<blockquote>
+<pre>template &lt;class Rep, class Period&gt; 
+bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
+              const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);</pre>
+<pre>...</pre>
 
-<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
-<p>
-In 25 [algorithms]/2, header <tt>&lt;algorithm&gt;</tt> synopsis change as indicated:
-</p>
-
-<blockquote><pre>template&lt;<del>class</del><ins>LessThanComparable</ins> T&gt;
-<ins>requires CopyConstructible&lt;T&gt;</ins>
-pair&lt;<del>const </del>T<del>&amp;</del>, <del>const </del>T<del>&amp;</del>&gt;
-minmax(initializer_list&lt;T&gt; t);
+<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
+postcondition cannot be achieved</del> <ins>an exception is required ([thread.req.exception])</ins>.</p>
+</blockquote>
 
-template&lt;class T, <del>class</del><ins>StrictWeakOrder&lt;auto, T&gt;</ins> Compare&gt;
-<ins>requires CopyConstructible&lt;T&gt;</ins>
-pair&lt;<del>const </del>T<del>&amp;</del>, <del>const </del>T<del>&amp;</del>&gt;
-minmax(initializer_list&lt;T&gt; t, Compare comp);
-</pre></blockquote>
-</li>
-<li>
-<p>
-In 25.5.7 [alg.min.max] change as indicated (Begin: Just before p.20):
-</p>
-<blockquote><pre>template&lt;<del>class</del><ins>LessThanComparable</ins> T&gt;
-  <ins>requires CopyConstructible&lt;T&gt;</ins>
-  pair&lt;<del>const </del>T<del>&amp;</del>, <del>const </del>T<del>&amp;</del>&gt;
-  minmax(initializer_list&lt;T&gt; t);
-</pre>
+<p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been 
+applied to the working paper, change Change 30.5.1 [thread.condition.condvar] as 
+indicated:</i></p>
 <blockquote>
-<p>
-<del>-20- <i>Requires:</i> <tt>T</tt> is <tt>LessThanComparable</tt> and
-<tt>CopyConstructible</tt>.</del>
-</p>
-<p>
--21- <i>Returns:</i> <tt>pair&lt;<del>const </del>T<del>&amp;</del>, <del>const
-</del>T<del>&amp;</del>&gt;(x, y)</tt> where <tt>x</tt> is the
-smallest value and <tt>y</tt> the largest value in the <tt>initializer_list</tt>.
-</p>
-</blockquote>
+<pre>template &lt;class Rep, class Period, class Predicate&gt; 
+  bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
+                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, 
+                Predicate pred);</pre>
+  <pre>...</pre>
 
-<p>[..]</p>
-<pre>template&lt;class T, <del>class</del><ins>StrictWeakOrder&lt;auto, T&gt;</ins> Compare&gt;
-  <ins>requires CopyConstructible&lt;T&gt;</ins>
-  pair&lt;<del>const </del>T<del>&amp;</del>, <del>const </del>T<del>&amp;</del>&gt;
-  minmax(initializer_list&lt;T&gt; t, Compare comp);
-</pre>
+<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
+postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
+</blockquote>
 
+<p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been 
+applied to the working paper, change 30.5.2 [thread.condition.condvarany] as 
+indicated:</i></p>
 <blockquote>
-<p>
-<del>-24- <i>Requires:</i> type <tt>T</tt> is <tt>LessThanComparable</tt> and <tt>CopyConstructible</tt>.</del>
-</p>
-<p>
--25- <i>Returns:</i> <tt>pair&lt;<del>const </del>T<del>&amp;</del>, <del>const
-</del>T<del>&amp;</del>&gt;(x, y)</tt> where <tt>x</tt> is the
-smallest value and <tt>y</tt> largest value in the <tt>initializer_list</tt>.
-</p>
+<pre>template &lt;class Lock, class Rep, class Period&gt; 
+  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);</pre>
+  <pre>...</pre>
+
+<p><i>Throws:</i> <code>std::system_error</code> when <del>the returned value, effects or 
+postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
 </blockquote>
+
+<p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been 
+applied to the working paper, change 30.5.2 [thread.condition.condvarany] as 
+indicated:</i></p>
+<blockquote>
+<pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt; 
+  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);</pre>
+  <pre>...</pre>
+
+<p><i>Throws:</i> <code>std::system_error</code> when <del>the returned value, effects or 
+postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
 </blockquote>
-</li>
-</ol>
 
 
 
@@ -16378,968 +13823,639 @@ smallest value and <tt>y</tt> largest value in the <tt>initializer_list</tt>.
 
 
 <hr>
-<h3><a name="916"></a>916. Redundant move-assignment operator of <tt>pair</tt> should be removed</h3>
-<p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04  <b>Last modified:</b> 2009-07-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="963"></a>963. Various threading bugs #13</h3>
+<p><b>Section:</b> 30.3.1.5 [thread.thread.member] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.member">active issues</a> in [thread.thread.member].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.member">issues</a> in [thread.thread.member].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
-<p><b>see also <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>.</b></p>
-
-<p>
-The current WP provides the following assignment operators for <tt>pair</tt>
-in 20.3.3 [pairs]/1:
-</p>
-
-<ol>
-<li>
-<pre>template&lt;class U , class V&gt;
-requires HasAssign&lt;T1, const U&amp;&gt; &amp;&amp; HasAssign&lt;T2, const V&amp;&gt;
-pair&amp; operator=(const pair&lt;U , V&gt;&amp; p);
-</pre>
-</li>
-<li>
-<pre>requires MoveAssignable&lt;T1&gt; &amp;&amp; MoveAssignable&lt;T2&gt; pair&amp; operator=(pair&amp;&amp; p );
-</pre>
-</li>
-<li>
-<pre>template&lt;class U , class V&gt;
-requires HasAssign&lt;T1, RvalueOf&lt;U&gt;::type&gt; &amp;&amp; HasAssign&lt;T2, RvalueOf&lt;V&gt;::type&gt;
-pair&amp; operator=(pair&lt;U , V&gt;&amp;&amp; p);
-</pre>
-</li>
-</ol>
-
 <p>
-It seems that the functionality of (2) is completely covered by (3), therefore
-(2) should be removed.
+30.3.1.5 [thread.thread.member]:  <tt>thread::detach</tt> is required to
+throw an exception if the thread is "not a detachable thread".
+"Detachable" is never defined.
 </p>
 
 <p><i>[
-Batavia (2009-05):
+Howard adds:
 ]</i></p>
 
+
 <blockquote>
-<p>
-Bill believes the extra assignment operators are necessary for resolving
-ambiguities, but that does not mean it needs to be part of the specification.
-</p>
-<p>
-Move to Open.
-We recommend this be looked at in the context of the ongoing work
-related to the pair templates.
-</p>
+Due to a mistake on my part, 3 proposed resolutions appeared at approximately
+the same time.  They are all three noted below in the discussion.
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+Summit, proposed resolution:
 ]</i></p>
 
 
 <blockquote>
-Leave this open pending the removal of concepts from the WD.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<ol type="A">
-<li>
 <p>
-In 20.3.3 [pairs] p. 1, class <tt>pair</tt> and just before p. 13 remove the declaration:
+In 30.3.1.5 [thread.thread.member] change:
 </p>
 
-<blockquote><pre>requires MoveAssignable&lt;T1&gt; &amp;&amp; MoveAssignable&lt;T2&gt; pair&amp; operator=(pair&amp;&amp; p );
-</pre></blockquote>
-</li>
-
-<li>
-Remove p.13+p.14
-</li>
-
-</ol>
+<blockquote><pre>void detach();
+</pre>
+<blockquote>
+<p>...</p>
+<p>-14- <i>Error conditions:</i></p>
+<ul>
+<li><tt>no_such_process</tt> --  <ins>if the thread is</ins> not <del>a</del> valid<del> thread</del>.</li>
+<li><tt>invalid_argument</tt> -- <ins>if the thread is</ins> not <del>a detachable</del> <ins>joinable</ins><del> thread</del>.</li>
+</ul>
+</blockquote>
 
+</blockquote>
 
+</blockquote>
 
+<p><i>[
+Post Summit, Jonathan Wakely adds:
+]</i></p>
 
 
-<hr>
-<h3><a name="917"></a>917. Redundant move-assignment operator of <tt>tuple</tt> should be removed</h3>
-<p><b>Section:</b> 20.5.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04  <b>Last modified:</b> 2009-07-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p><b>see also <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>.</b></p>
+<blockquote>
+<p>
+A <tt>thread</tt> is detachable if it is joinable. As we've defined joinable,
+we can just use that.
+</p>
+<p>
+This corresponds to the pthreads specification, where pthread_detach
+fails if the thread is not joinable:
+</p>
+<blockquote>
+EINVAL: The  implementation  has  detected  that  the value specified by
+thread does not refer to a joinable thread.
+</blockquote>
+<p>
+Jonathan recommends this proposed wording:
+</p>
+<blockquote>
 <p>
-N2770 (and thus now the WP) removed the
-non-template move-assignment operator from tuple's class definition,
-but the latter individual member description does still provide this
-operator. Is this (a) an oversight and can it (b) be solved as part of an
-editorial process?
+In 30.3.1.5 [thread.thread.member] change:
 </p>
 
-<p><i>[
-Post Summit Daniel provided wording.
-]</i></p>
+<blockquote><pre>void detach();
+</pre>
+<blockquote>
+<p>...</p>
+<p>-14- <i>Error conditions:</i></p>
+<ul>
+<li>...</li>
+<li><tt>invalid_argument</tt> -- not a <del>detachable</del> <ins>joinable</ins> thread.</li>
+</ul>
+</blockquote>
 
+</blockquote>
+</blockquote>
+</blockquote>
 
 <p><i>[
-Batavia (2009-05):
+Post Summit, Anthony Williams adds:
 ]</i></p>
 
+
 <blockquote>
 <p>
-We believe that the proposed resolution's part 1 is editorial.
-</p>
-<p>
-Regarding part 2, we either remove the specification as proposed,
-or else add back the declaration to which the specification refers.
-Alisdair and Bill prefer the latter.
-It is not immediately obvious whether the function is intended to be present.
+This is covered by the precondition that <tt>joinable()</tt> be <tt>true</tt>.
 </p>
 <p>
-We recommend that the Project Editor restore the missing declaration
-and that we keep part 2 of the issue alive.
+Anthony recommends this proposed wording:
 </p>
+
+<blockquote>
 <p>
-Move to Open.
+In 30.3.1.5 [thread.thread.member] change:
 </p>
+
+<blockquote><pre>void detach();
+</pre>
+<blockquote>
+<p>...</p>
+<p>-14- <i>Error conditions:</i></p>
+<ul>
+<li>...</li>
+<li><del><tt>invalid_argument</tt> -- not a detachable thread.</del></li>
+</ul>
+</blockquote>
+
+</blockquote>
+
+</blockquote>
+
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Leave this open pending the removal of concepts from the WD.
+Mark as Ready with proposed resolution from Summit.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
-<ol>
-<li>
-<p>
-In 20.5.2 [tuple.tuple], class <tt>tuple</tt> just before member <tt>swap</tt> please
-change as indicated:
-</p>
-<p><i>[
-This fixes an editorial loss between N2798 to N2800
-]</i></p>
-
-<blockquote><pre>template &lt;class... UTypes&gt;
-requires HasAssign&lt;Types, const UTypes&amp;&gt;...
-<ins>tuple&amp; operator=(const pair&lt;UTypes...&gt;&amp;);</ins>
 
-template &lt;class... UTypes&gt;
-requires HasAssign&lt;Types, RvalueOf&lt;UTypes&gt;::type&gt;...
-<ins>tuple&amp; operator=(pair&lt;UTypes...&gt;&amp;&amp;);</ins>
-</pre></blockquote>
-</li>
-<li>
 <p>
-In 20.5.2.1 [tuple.cnstr], starting just before p. 11 please remove
-as indicated:
+In 30.3.1.5 [thread.thread.member] change:
 </p>
 
-<blockquote><pre><del>requires MoveAssignable&lt;Types&gt;... tuple&amp; operator=(tuple&amp;&amp; u);</del>
+<blockquote><pre>void detach();
 </pre>
 <blockquote>
-<p>
-<del>-11- <i>Effects:</i> Move-assigns each element of <tt>u</tt> to the corresponding
-element of <tt>*this</tt>.</del>
-</p>
-<p>
-<del>-12- <i>Returns:</i> <tt>*this</tt>.</del>
-</p>
+<p>...</p>
+<p>-14- <i>Error conditions:</i></p>
+<ul>
+<li><tt>no_such_process</tt> --  <ins>if the thread is</ins> not <del>a</del> valid<del> thread</del>.</li>
+<li><tt>invalid_argument</tt> -- <ins>if the thread is</ins> not <del>a detachable</del> <ins>joinable</ins><del> thread</del>.</li>
+</ul>
 </blockquote>
+
 </blockquote>
-</li>
-</ol>
+
 
 
 
 
 
 <hr>
-<h3><a name="919"></a>919. (forward_)list specialized remove algorithms are over constrained</h3>
-<p><b>Section:</b> 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-06  <b>Last modified:</b> 2009-07-21</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forwardlist.ops">active issues</a> in [forwardlist.ops].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</p>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvarany">active issues</a> in [thread.condition.condvarany].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvarany">issues</a> in [thread.condition.condvarany].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The signatures of <tt>forwardlist::remove</tt> and <tt>list::remove</tt>
-defined in 23.3.3.5 [forwardlist.ops] before 11 + 23.3.4.4 [list.ops] before 15:
+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>
 
-<blockquote><pre>requires EqualityComparable&lt;T&gt; void remove(const T&amp; value);
-</pre></blockquote>
+<p><i>[
+Summit:
+]</i></p>
 
-<p>
-are asymmetric to their predicate variants (which only require
-<tt>Predicate</tt>, <em>not</em> <tt>EquivalenceRelation</tt>) and with the free algorithm
-remove (which only require <tt>HasEqualTo</tt>). Also, nothing in the
-pre-concept WP
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
-implies that <tt>EqualityComparable</tt> should
-be the intended requirement.
-</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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>.
+</blockquote>
 
 <p><i>[
-Batavia (2009-05):
+Post Summit Howard adds:
 ]</i></p>
 
+
 <blockquote>
-<p>
-We agree with the proposed resolution,
-but would like additional input from concepts experts.
-</p>
-<p>
-Move to Review.
-</p>
+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-07-21 Alisdair adds:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Current rationale and wording for this issue is built around concepts. I
-suggest the issue reverts to Open status. &nbsp;I believe there is enough of
-an issue to review after concepts are removed from the WP to re-examine
-the issue in Santa Cruz, rather than resolve as NAD Concepts.
+Leave open. Benjamin to provide wording.
 </blockquote>
 
 
-<p><b>Proposed resolution:</b></p>
-<ol type="A">
-<li>
-<p>
-Replace in 23.3.3.5 [forwardlist.ops] before 11 and in 23.3.4.4 [list.ops] before 15
-</p>
-
-<blockquote><pre>requires <del>EqualityComparable&lt;T&gt;</del> <ins>HasEqualTo&lt;T, T&gt;</ins> void remove(const T&amp; value);
-</pre></blockquote>
-</li>
-</ol>
 
+<p><b>Proposed resolution:</b></p>
 
 
 
 
 
 <hr>
-<h3><a name="920"></a>920. Ref-qualification support in the library</h3>
-<p><b>Section:</b> 20.7.15 [func.memfn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Bronek Kozicki <b>Opened:</b> 2008-10-06  <b>Last modified:</b> 2009-05-23</p>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Daniel Krügler wrote:
+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>
-Shouldn't above list be completed for &amp;- and &amp;&amp;-qualified
-member functions This would cause to add:
+The proposed wording is inspired by the POSIX spec which says:
 </p>
-<blockquote><pre>template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-unspecified mem_fn(R (T::* pm)(Args...) &amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-unspecified mem_fn(R (T::* pm)(Args...) const &amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-unspecified mem_fn(R (T::* pm)(Args...) volatile &amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-unspecified mem_fn(R (T::* pm)(Args...) const volatile &amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-unspecified mem_fn(R (T::* pm)(Args...) &amp;&amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-unspecified mem_fn(R (T::* pm)(Args...) const &amp;&amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-unspecified mem_fn(R (T::* pm)(Args...) volatile &amp;&amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-unspecified mem_fn(R (T::* pm)(Args...) const volatile &amp;&amp;);
-</pre></blockquote>
 
+<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>
-yes, absolutely. Thanks for spotting this. Without this change <tt>mem_fn</tt>
-cannot be initialized from pointer to ref-qualified member function. I
-believe semantics of such function pointer is well defined.
+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>[
-Post Summit Daniel provided wording.
+2009-10 Santa Cruz:
 ]</i></p>
 
 
+<blockquote>
+Leave open, Detlef to provide improved wording.
+</blockquote>
+
 <p><i>[
-Batavia (2009-05):
+2009-10-23 Detlef Provided wording.
 ]</i></p>
 
+
 <blockquote>
 <p>
-We need to think about whether we really want to go down the proposed path
-of combinatorial explosion.
-Perhaps a Note would suffice.
-</p>
-<p>
-We would really like to have an implementation before proceeding.
+Detlef's wording put in Proposed resolution.  Original wording here:
 </p>
+<blockquote>
 <p>
-Move to Open, and recommend this be deferred until after the next
-Committee Draft has been issued.
+Change 30.5.1 [thread.condition.condvar] p12, p19 and
+30.5.2 [thread.condition.condvarany] p10, p16:
 </p>
-</blockquote>
 
+<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><b>Proposed resolution:</b></p>
-<ol>
-<li>
-<p>
-In 20.7 [function.objects]/2, header <tt>&lt;functional&gt;</tt> synopsis, just after
-the section "// 20.6.15, member function adaptors::" add the following
-declarations to the existing list:
-</p>
-<blockquote><pre>template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-  <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-  <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-  <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-  <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-  <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &amp;&amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-  <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &amp;&amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-  <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &amp;&amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-  <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &amp;&amp;);
-</pre></blockquote>
-</li>
-<li>
-<p>
-In 20.7.15 [func.memfn] add the following declarations to the existing
-list:
-</p>
-<blockquote><pre>template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-  <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-  <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-  <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-  <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-  <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &amp;&amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-  <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &amp;&amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-  <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &amp;&amp;);
-template&lt;Returnable R, class T, CopyConstructible... Args&gt;
-  <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &amp;&amp;);
-</pre></blockquote>
-</li>
-</ol>
-<p>
-The following text, most notably p.2 and p.3 which discuss influence
-of the cv-qualification on the definition of the base class's first template
-parameter remains unchanged.
-</p>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
 
+<blockquote>
+Leave open, Detlef to provide improved wording.
+</blockquote>
 
 
 
-<hr>
-<h3><a name="921"></a>921. Rational Arithmetic should use template aliases</h3>
-<p><b>Section:</b> 20.4.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2008-10-07  <b>Last modified:</b> 2009-07-21</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ratio.ratio">active issues</a> in [ratio.ratio].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.ratio">issues</a> in [ratio.ratio].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Proposed resolution:</b></p>
 <p>
-The compile-time functions that operate on <tt>ratio&lt;N,D&gt;</tt> require the
-cumbersome and error-prone "evaluation" of a <tt>type</tt> member using a
-meta-programming style that predates the invention of template aliases.
-Thus, multiplying three ratios <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> requires the expression:
+Replace 30.5.1 [thread.condition.condvar] p12, p19 and
+30.5.2 [thread.condition.condvarany] p10, p16:
 </p>
 
-<blockquote><pre>ratio_multiply&lt;a, ratio_multiply&lt;b, c&gt;::type&gt;::type
-</pre></blockquote>
+<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>
-The simpler expression:
-</p>
+<p><ins>
+<i>Throws:</i> It's 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>
 
-<blockquote><pre>ratio_multiply&lt;a, ratio_multiply&lt;b, c&gt;&gt;
-</pre></blockquote>
 
-<p>
-Could be used by if template aliases were employed in the definitions.
-</p>
 
-<p><i>[
-Post Summit:
-]</i></p>
 
 
-<blockquote>
-<p>
-Jens: not a complete proposed resolution: "would need to make similar change"
-</p>
-<p>
-Consensus: We agree with the direction of the issue.
-</p>
+
+<hr>
+<h3><a name="967"></a>967. Various threading bugs #17</h3>
+<p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Recommend Open.
+the error handling for the constructor for <tt>condition_variable</tt>
+distinguishes lack of memory from lack of other resources, but the error
+handling for the thread constructor does not. Is this difference
+intentional?
 </p>
-</blockquote>
 
 <p><i>[
-2009-05-11 Daniel adds:
+Beman has volunteered to provide proposed wording.
 ]</i></p>
 
 
-<blockquote>
-<p>
-Personally I'm <em>not</em> in favor for the addition of:
-</p>
-<blockquote><pre>typedef ratio type;
-</pre></blockquote>
-<p>
-For a reader of the
-standard it's usage or purpose is unclear. I haven't seen similar examples
-of attempts to satisfy non-feature complete compilers.
-</p>
-</blockquote>
-
 <p><i>[
-2009-05-11 Pablo adds:
+2009-09-25 Beman provided proposed wording.
 ]</i></p>
 
 
 <blockquote>
-<p>
-The addition of type to the <tt>ratio</tt> template allows the previous style
-(i.e., in the prototype implementations) to remain valid and permits the
-use of transitional library implementations for C++03 compilers.  I do
-not feel strongly about its inclusion, however, and leave it up to the
-reviewers to decide.
-</p>
+The proposed resolution assumes <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a> has been accepted and
+its proposed resolution applied to the working paper.
 </blockquote>
 
 <p><i>[
-Batavia (2009-05):
+2009-10 Santa Cruz:
 ]</i></p>
 
+
 <blockquote>
-Bill asks for additional discussion in the issue
-that spells out more details of the implementation.
-Howard points us to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>
-which has at least most of the requested details.
-Tom is strongly in favor of overflow-checking at compile time.
-Pete points out that there is no change of functionality implied.
-We agree with the proposed resolution,
-but recommend moving the issue to Review
-to allow time to improve the discussion if needed.
+Move to Ready.
 </blockquote>
 
-<p><i>[
-2009-07-21 Alisdair adds:
-]</i></p>
 
 
-<blockquote>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1121">1121</a> for a potentially incompatible proposal.
-</blockquote>
+<p><b>Proposed resolution:</b></p>
 
 
-<p><b>Proposed resolution:</b></p>
+<p><span style="font-style: italic;">Change Mutex requirements 30.4.1 [thread.mutex.requirements], 
+paragraph 4, as indicated:</span></p>
+<blockquote>
 
- 
- <ol start="0">
-<li>
-<p>
-In 20.4 [ratio]/3 change as indicated:
-</p>
+<p><i>Error conditions:</i></p>
+  <blockquote>
 
-<blockquote><pre>// ratio arithmetic
-template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_add<ins> = <em>see below</em></ins>;
-template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_subtract<ins> = <em>see below</em></ins>;
-template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_multiply<ins> = <em>see below</em></ins>;
-template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_divide<ins> = <em>see below</em></ins>;
-</pre></blockquote>
-</li>
-<li>
-<p>
-In 20.4.1 [ratio.ratio], change as indicated:
-</p>
-<blockquote><pre>namespace std {
-  template &lt;intmax_t N, intmax_t D = 1&gt;
-  class ratio {
-  public:
-    <ins>typedef ratio type;</ins>
-    static const intmax_t num;
-    static const intmax_t den;
-  };
-}
-</pre></blockquote>
-</li>
-<li>
-<p>
-In 20.4.2 [ratio.arithmetic] change as indicated:
-</p>
+<ul>
+<li><del> <code>not_enough_memory</code> &#8212; if there is not enough memory to construct 
+the mutex object.</del></li>
 
-<blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_add<ins> = <em>see below</em></ins><del>{
-  typedef <em>see below</em> type;
-}</del>;
-</pre>
+<li><code>resource_unavailable_try_again</code> &#8212; if any native handle type 
+manipulated is not available.</li>
 
-<blockquote>
-<p>
-1 The <del>nested typedef</del> type <tt><ins>ratio_add&lt;R1, R2&gt;</ins></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>.
-</p>
-</blockquote>
-</blockquote>
-<blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_subtract<ins> = <em>see below</em></ins><del>{
-  typedef <em>see below</em> type;
-}</del>;
-</pre>
-<blockquote>
-<p>
-2 The <del>nested typedef</del> type <tt><ins>ratio_subtract&lt;R1, R2&gt;</ins></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>.
-</p>
-</blockquote>
-</blockquote>
-<blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_multiply<ins> = <em>see below</em></ins><del>{
-  typedef <em>see below</em> type;
-}</del>;
-</pre>
-<blockquote>
-<p>
-3 The <del>nested typedef</del> type <tt><ins>ratio_multiply&lt;R1, R2&gt;</ins></tt>
-shall be a synonym for <tt>ratio&lt;T1, T2&gt;</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>.
-</p>
-</blockquote>
-</blockquote>
-<blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_divide<ins> = <em>see below</em></ins><del>{
-  typedef <em>see below</em> type;
-}</del>;
-</pre>
-<blockquote>
-<p>
-4 The <del>nested typedef</del> type <tt><ins>ratio_divide&lt;R1, R2&gt;</ins></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</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::num</tt>.
-</p>
-</blockquote>
-</blockquote>
-</li>
-<li>
-<p>
-In 20.9.3.1 [time.duration.cons]/4 change as indicated:
-</p>
-<blockquote>
-<p>
-<i>Requires:</i> <tt>treat_as_floating_point&lt;rep&gt;::value</tt> shall be true or
-<tt>ratio_divide&lt;Period2, period&gt;::<del>type::</del>den</tt> shall be 1.[..]
-</p>
+<li><code>operation_not_permitted</code> &#8212; if the thread does not have the 
+necessary permission to change the state of the mutex object.</li>
+
+<li><code>device_or_resource_busy</code> &#8212; if any native handle type 
+manipulated is already locked.</li>
+
+<li><code>invalid_argument</code> &#8212; if any native handle type manipulated as 
+part of mutex construction is incorrect.</li>
+</ul>
+  </blockquote>
 </blockquote>
-</li>
-<li>
-<p>
-In 20.9.3.7 [time.duration.cast]/2 change as indicated:
-</p>
+
+<p><span style="font-style: italic;">Change Class condition_variable 30.5.1 [thread.condition.condvar], 
+default constructor, as indicated:</span></p>
 <blockquote>
-<p>
-<i>Returns:</i> Let CF be <tt>ratio_divide&lt;Period, typename
-ToDuration::period&gt;<del>::type</del></tt>, and [..]
-</p>
+  <p><code>condition_variable();</code></p>
+  <blockquote>
+    <p><i>Effects:</i> Constructs an object of type <code>condition_variable</code>.</p>
+    <p><ins><i>Throws:</i> <code>std::system_error</code> when an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
+    <p><i>Error conditions:</i></p>
+    <blockquote>
+    <ul>
+      <li><del><code>not_enough_memory</code> &#8212; if a memory limitation prevents 
+      initialization.</del></li>
+      <li> <code>resource_unavailable_try_again</code> &#8212; if some non-memory 
+      resource limitation prevents initialization.</li>
+      <li> <code>device_or_resource_busy</code> &#8212; if attempting to initialize a 
+      previously-initialized but as of yet undestroyed <code>condition_variable</code>.</li>
+    </ul>
+    </blockquote>
+  </blockquote>
 </blockquote>
-</li>
-</ol>
 
 
 
 
 
 <hr>
-<h3><a name="923"></a>923. atomics with floating-point </h3>
-<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-10-17  <b>Last modified:</b> 2009-05-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="968"></a>968. Various threading bugs #18</h3>
+<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Right now, C++0x doesn't have <tt>atomic&lt;float&gt;</tt>. We're thinking of adding
-the words to support it for TR2 (note: that would be slightly
-post-C++0x). If we need it, we could probably add the words.
-</p>
-<p>
-<b>Proposed resolutions:</b> Using <tt>atomic&lt;FP&gt;::compare_exchange</tt> (weak or
-strong) should be either:
-</p>
-
-<ol>
-<li>
-ill-formed, or
-</li>
-<li>
-well-defined.
-</li>
-</ol>
-
-<p>
-I propose Option 1 for C++0x for expediency. If someone wants to argue
-for Option 2, they need to say what exactly they want <tt>compare_exchange</tt>
-to mean in this case (IIRC, C++0x doesn't even assume IEEE 754).
+30.4.1 [thread.mutex.requirements]: several functions are
+required to throw exceptions "if the thread does not have the necessary
+permission ...". "The necessary permission" is not defined.
 </p>
 
 <p><i>[
 Summit:
 ]</i></p>
 
-
 <blockquote>
-Move to open. Blocked until concepts for atomics are addressed.
+Move to open.
 </blockquote>
 
+
 <p><i>[
-Post Summit Anthony adds:
+Beman has volunteered to provide proposed wording.
 ]</i></p>
 
 
-<blockquote>
-<p>
-Recommend NAD. C++0x does have <tt>std::atomic&lt;float&gt;</tt>, and both
-<tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> are well-defined in
-this case. Maybe change the note in 29.6 [atomics.types.operations] paragraph 20 to:
-</p>
-
-<blockquote>
-<p>
-[<i>Note:</i> The effect of the compare-and-exchange operations is
-</p>
-<blockquote><pre>if (!memcmp(object,expected,sizeof(*object)))
-    *object = desired;
-else
-    *expected = *object;
-</pre></blockquote>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
-<p>
-This may result in failed comparisons for values that compare equal if
-the underlying type has padding bits or alternate representations of
-the same value. <i>-- end note</i>]
-</p>
-</blockquote>
 
+<blockquote>
+Moved to Ready with minor word-smithing in the example.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
-<p>
-Change the note in 29.6 [atomics.types.operations] paragraph 20 to:
-</p>
-
-<blockquote>
-<p>
-[<i>Note:</i> The effect of the compare-and-exchange operations is
-</p>
-<blockquote><pre>if (<del>*object == *expected</del> <ins>!memcmp(object,expected,sizeof(*object))</ins>)
-    *object = desired;
-else
-    *expected = *object;
-</pre></blockquote>
 
-<p><ins>
-This may result in failed comparisons for values that compare equal if
-the underlying type has padding bits or alternate representations of
-the same value.</ins> <i>-- end note</i>]
-</p>
-</blockquote>
 
+<p><i>Change Exceptions 30.2.2 [thread.req.exception] as indicated:</i></p>
+<blockquote>
+<p>Some functions described in this Clause are 
+specified to throw exceptions of type <code>system_error</code> (19.5.5). Such exceptions 
+shall be thrown if any of the <i>Error conditions</i> are detected or a call to an operating system or other underlying API 
+results in an error that prevents the library function from meeting its specifications.
+<i>[Note:</i> See 17.6.4.11 [res.on.exception.handling] for exceptions thrown to report 
+storage allocation failures. <i>&#8212;end 
+note]</i></p>
 
+<p><ins><i>[Example:</i></ins></p>
 
+<blockquote>
 
+<p><ins>Consider a function in this clause that is specified to throw exceptions of type <code>
+system_error</code> and specifies <i>Error conditions</i> that include <code>
+operation_not_permitted</code> for a thread that does not have the privilege to 
+perform the operation. Assume that, during the execution of this function, an <code>errno</code> 
+of <code>EPERM</code> is reported by a POSIX API call used by the 
+implementation. Since POSIX specifies an <code>errno</code> of <code>EPERM</code> 
+when "the caller does not have the privilege to perform the operation", 
+the implementation maps <code>EPERM</code>&nbsp; to an <code>error_condition</code> 
+of <code>operation_not_permitted</code> (19.5 [syserr]) and an exception of type <code>
+system_error</code> is thrown. </ins></p>
 
+</blockquote>
 
-<hr>
-<h3><a name="924"></a>924. structs with internal padding</h3>
-<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-10-17  <b>Last modified:</b> 2009-03-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Right now, the <tt>compare_exchange_weak</tt> loop should rapidly converge on the
-padding contents. But <tt>compare_exchange_strong</tt> will require a bit more
-compiler work to ignore padding for comparison purposes.
-</p>
-<p>
-Note that this isn't a problem for structs with no padding, and we do
-already have one portable way to ensure that there is no padding that
-covers the key use cases: Have elements be the same type. I suspect that
-the greatest need is for a structure of two pointers, which has no
-padding problem. I suspect the second need is a structure of a pointer
-and some form of an integer. If that integer is <tt>intptr_t</tt>, there will be
-no padding.
-</p>
-<p>
-Related but separable issue: For unused bitfields, or other unused
-fields for that matter, we should probably say it's the programmer's
-responsibility to set them to zero or otherwise ensure they'll be
-ignored by <tt>memcmp</tt>.
-</p>
+<p><ins><i>&#8212;end example]</i></ins></p>
 
-<p>
-<b>Proposed resolutions:</b> Using
-<tt>atomic&lt;struct-with-padding&gt;::compare_exchange_strong</tt> should be either:
-</p>
+<p><span style="font-style: italic;">Editorial note: For the sake of exposition, 
+the existing text above is shown with the changes proposed in issues 962 and 967. The 
+proposed additional example is independent of whether or not the 962 and 967 
+proposed resolutions are accepted.</span></p>
 
-<ol>
-<li>
-ill-formed, or
-</li>
-<li>
-well-defined.
-</li>
-</ol>
+</blockquote>
 
-<p>
-I propose Option 1 for C++0x for expediency, though I'm not sure how to
-say it. I would be happy with Option 2, which I believe would mean that
-<tt>compare_exchange_strong</tt> would be implemented to avoid comparing padding
-bytes, or something equivalent such as always zeroing out padding when
-loading/storing/comparing. (Either implementation might require compiler
-support.)
-</p>
+<p><span style="font-style: italic;">Change Mutex requirements 30.4.1 [thread.mutex.requirements], 
+paragraph 4, as indicated:</span></p>
 
-<p><i>[
-Summit:
-]</i></p>
+<blockquote>
 
+<p>&#8212; <code>operation_not_permitted</code> &#8212; if the thread does not have the 
+<del>necessary permission to change the state of the mutex object</del> <ins>privilege to perform the operation</ins>.</p>
 
-<blockquote>
-Move to open. Blocked until concepts for atomics are addressed.
 </blockquote>
 
-<p><i>[
-Post Summit Anthony adds:
-]</i></p>
-
+<p><span style="font-style: italic;">Change Mutex requirements 30.4.1 [thread.mutex.requirements], 
+paragraph 12, as indicated:</span></p>
 
 <blockquote>
-The resoultion of LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a> should resolve this issue as well.
-</blockquote>
 
+<p>&#8212; <code>operation_not_permitted</code> &#8212; if the thread does not have the 
+<del>necessary permission to change the state of the mutex</del> <ins>privilege to perform the operation</ins>.</p>
 
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
 
 
 
 
 
 <hr>
-<h3><a name="926"></a>926. Sequentially consistent fences, relaxed operations and modification order</h3>
-<p><b>Section:</b> 29.3 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-10-19  <b>Last modified:</b> 2009-03-22</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.order">issues</a> in [atomics.order].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="974"></a>974. <tt>duration&lt;double&gt;</tt> should not implicitly convert to <tt>duration&lt;int&gt;</tt></h3>
+<p><b>Section:</b> 20.9.3.1 [time.duration.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-21  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
-<p><b>Addresses UK 313</b></p>
-
 <p>
-There was an interesting issue raised over on comp.programming.threads
-today regarding the following example
+The following code should not compile because it involves implicit truncation
+errors (against the design philosophy of the <tt>duration</tt> library).
 </p>
 
-<blockquote><pre>// Thread 1:
-x.store(1, memory_order_relaxed);           // SX
-atomic_thread_fence(memory_order_seq_cst);  // F1
-y.store(1, memory_order_relaxed);           // SY1
-atomic_thread_fence(memory_order_seq_cst);  // F2
-r1 = y.load(memory_order_relaxed);          // RY
-
-// Thread 2:
-y.store(0, memory_order_relaxed);          // SY2
-atomic_thread_fence(memory_order_seq_cst); // F3
-r2 = x.load(memory_order_relaxed);         // RX
+<blockquote><pre>duration&lt;double&gt; d(3.5);
+duration&lt;int&gt; i = d;  <font color="#c80000">// implicit truncation, should not compile</font>
 </pre></blockquote>
 
 <p>
-is the outcome <tt>r1 == 0</tt> and <tt>r2 == 0</tt> possible?
-</p>
-<p>
-I think the intent is that this is not possible, but I am not sure the
-wording guarantees that. Here is my analysis:
-</p>
-<p>
-Since all the fences are SC, there must be a total order between them.
-<tt>F1</tt> must be before <tt>F2</tt> in that order since they are in
-the same thread. Therefore <tt>F3</tt> is either before <tt>F1</tt>,
-between <tt>F1</tt> and <tt>F2</tt> or after <tt>F2</tt>.
-</p>
-<p>
-If <tt>F3</tt> is <em>after</em> <tt>F2</tt>, then we can apply 29.3 [atomics.order]p5 from
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>:
+This intent was codified in the example implementation which drove this proposal
+but I failed to accurately translate the code into the specification in this
+regard.
 </p>
 
-<blockquote>
-For atomic operations <tt>A</tt> and <tt>B</tt> on an atomic object
-<tt>M</tt>, where <tt>A</tt> modifies <tt>M</tt> and <tt>B</tt> takes
-its value, if there are <tt>memory_order_seq_cst</tt> fences <tt>X</tt>
-and <tt>Y</tt> such that <tt>A</tt> is sequenced before <tt>X</tt>,
-<tt>Y</tt> is sequenced before <tt>B</tt>, and <tt>X</tt> precedes
-<tt>Y</tt> in <tt>S</tt>, then <tt>B</tt> observes either the effects of
-<tt>A</tt> or a later modification of <tt>M</tt> in its modification
-order.
-</blockquote>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
+<blockquote>
 <p>
-In this case, <tt>A</tt> is <tt>SX</tt>, <tt>B</tt> is <tt>RX</tt>, the
-fence <tt>X</tt> is <tt>F2</tt> and the fence <tt>Y</tt> is <tt>F3</tt>,
-so <tt>RX</tt> must see 1.
-</p>
-<p>
-If <tt>F3</tt> is <em>before</em> <tt>F2</tt>, this doesn't apply, but
-<tt>F3</tt> can therefore be before or after <tt>F1</tt>.
-</p>
-<p>
-If <tt>F3</tt> is <em>after</em> <tt>F1</tt>, the same logic applies, but this
-time the fence <tt>X</tt> is <tt>F1</tt>. Therefore again, <tt>RX</tt>
-must see 1.
-</p>
-<p>
-Finally we have the case that <tt>F3</tt> is <em>before</em> <tt>F1</tt>
-in the SC ordering. There are now no guarantees about <tt>RX</tt>, and
-<tt>RX</tt> can see <tt>r2==0</tt>.
-</p>
-<p>
-We can apply 29.3 [atomics.order]p5 again. This time,
-<tt>A</tt> is <tt>SY2</tt>, <tt>B</tt> is <tt>RY</tt>, <tt>X</tt> is
-<tt>F3</tt> and <tt>Y</tt> is <tt>F1</tt>. Thus <tt>RY</tt> must observe
-the effects of <tt>SY2</tt> or a later modification of <tt>y</tt> in its
-modification order.
-</p>
-<p>
-Since <tt>SY1</tt> is sequenced before <tt>RY</tt>, <tt>RY</tt> must
-observe the effects of <tt>SY1</tt> or a later modification of
-<tt>y</tt> in its modification order.
-</p>
-<p>
-In order to ensure that <tt>RY</tt> sees <tt>(r1==1)</tt>, we must see
-that <tt>SY1</tt> is later in the modification order of <tt>y</tt> than
-<tt>SY2</tt>.
+We agree with the proposed resolution.
 </p>
 <p>
-We're now skating on thin ice. Conceptually, <tt>SY2</tt> happens-before
-<tt>F3</tt>, <tt>F3</tt> is SC-ordered before <tt>F1</tt>, <tt>F1</tt>
-happens-before <tt>SY1</tt>, so <tt>SY1</tt> is later in the
-modification order <tt>M</tt> of <tt>y</tt>, and <tt>RY</tt> must see
-the result of <tt>SY1</tt> (<tt>r1==1</tt>). However, I don't think the
-words are clear on that.
+Move to Tentatively Ready.
 </p>
+</blockquote>
 
 <p><i>[
-Post Summit Hans adds:
+2009-07 Frankfurt
 ]</i></p>
 
 
 <blockquote>
-<p>
-In my (Hans') view, our definition of fences will always be weaker than
-what particular hardware will guarantee.  <tt>Memory_order_seq_cst</tt> fences
-inherently don't guarantee sequential consistency anyway, for good
-reasons (e.g. because they can't enforce a total order on stores).
- Hence I don't think the issue demonstrates a gross failure to achieve
-what we intended to achieve.  The example in question is a bit esoteric.
- Hence, in my view, living with the status quo certainly wouldn't be a
-disaster either.
-</p>
-<p>
-In any case, we should probably add text along the lines of the
-following between p5 and p6 in 29.3 [atomics.order]:
-</p>
-<blockquote>
-[Note: <tt>Memory_order_seq_cst</tt> only ensures sequential consistency for a
-data-race-free program that uses exclusively <tt>memory_order_seq_cst</tt>
-operations.  Any use of weaker ordering will invalidate this guarantee
-unless extreme care is used.  In particular, <tt>memory_order_seq_cst</tt> fences
-only ensure a total order for the fences themselves.  They cannot, in
-general, be used to restore sequential consistency for atomic operations
-with weaker ordering specifications.]
+Moved from Tentatively Ready to Open only because the wording needs to be
+improved for enable_if type constraining, possibly following Robert's
+formula.
 </blockquote>
 
-<p>
-Also see thread beginning at c++std-lib-23271.
-</p>
+<p><i>[
+2009-08-01 Howard adds:
+]</i></p>
 
+
+<blockquote>
+Addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a>.
 </blockquote>
 
 <p><i>[
-Herve's correction:
+2009-10 Santa Cruz:
 ]</i></p>
 
-<blockquote>
-<p>
-Minor point, and sorry for the knee jerk reaction: I admit to having
-no knowledge of Memory_order_seq_cst, but my former boss (John Lakos)
-has ingrained an automatic introspection on the use of "only".   I
-think you meant:
-</p>
 
 <blockquote>
-[Note: <tt>Memory_order_seq_cst</tt> ensures sequential consistency only
-for . . . .  In particular, <tt>memory_order_seq_cst</tt> fences ensure a
-total order only for . . .
-</blockquote>
-<p>
-Unless, of course, <tt>Memory_order_seq_cst</tt> really do nothing but ensure
-sequential consistency for a data-race-free program that uses
-exclusively <tt>memory_order_seq_cst</tt> operations.
-</p>
+Not completely addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a>.  Move to Ready.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add a new paragraph after 29.3 [atomics.order]p5 that says
+Change 20.9.3.1 [time.duration.cons], p4:
 </p>
 
 <blockquote>
-For atomic operations <tt>A</tt> and <tt>B</tt> on an atomic object
-<tt>M</tt>, where <tt>A</tt> and <tt>B</tt> modify <tt>M</tt>, if there
-are <tt>memory_order_seq_cst</tt> fences <tt>X</tt> and <tt>Y</tt> such
-that <tt>A</tt> is sequenced before <tt>X</tt>, <tt>Y</tt> is sequenced
-before <tt>B</tt>, and <tt>X</tt> precedes <tt>Y</tt> in <tt>S</tt>,
-then <tt>B</tt> occurs later than <tt>A</tt> in the modifiction order of
-<tt>M</tt>.
+<pre>template &lt;class Rep2, class Period2&gt; 
+  duration(const duration&lt;Rep2, Period2&gt;&amp; d);
+</pre>
+<blockquote>
+-4- <i>Requires:</i> <tt>treat_as_floating_point&lt;rep&gt;::value</tt>
+shall be <tt>true</tt> or <ins>both</ins> <tt>ratio_divide&lt;Period2,
+period&gt;::type::den</tt> shall be 1
+<ins>and <tt>treat_as_floating_point&lt;Rep2&gt;::value</tt>
+shall be <tt>false</tt></ins>.
+Diagnostic required.
+[<i>Note:</i> This requirement prevents implicit truncation error when
+converting between integral-based <tt>duration</tt> types. Such a
+construction could easily lead to confusion about the value of the
+<tt>duration</tt>. -- <i>end note</i>]
+</blockquote>
 </blockquote>
 
 
@@ -17347,978 +14463,823 @@ then <tt>B</tt> occurs later than <tt>A</tt> in the modifiction order of
 
 
 <hr>
-<h3><a name="929"></a>929. Thread constructor</h3>
-<p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-10-23  <b>Last modified:</b> 2009-07-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="978"></a>978. Hashing smart pointers</h3>
+<p><b>Section:</b> 20.7.16 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-02-02  <b>Last modified:</b> 2009-10-27</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 323</b></p>
-
-<p>
-The <tt>thread</tt> constructor for starting a new thread with a function and
-arguments is overly constrained by the signature requiring rvalue
-references for <tt>func</tt> and <tt>args</tt> and the <tt>CopyConstructible</tt> requirements
-for the elements of <tt>args</tt>. The use of an rvalue reference for the
-function restricts the potential use of a plain function name, since
-the type of the bound parameter will be deduced to be a function
-reference and decay to pointer-to-function will not happen. This
-therefore complicates the implementation in order to handle a simple
-case. Furthermore, the use of rvalue references for args prevents the
-array to pointer decay. Since arrays are not <tt>CopyConstructible</tt> or even
-<tt>MoveConstructible</tt>, this essentially prevents the passing of arrays as
-parameters. In particular it prevents the passing of string literals.
-Consequently a simple case such as
-</p>
-
-<blockquote><pre>void f(const char*);
-std::thread t(f,"hello");
-</pre></blockquote>
-
-<p>
-is ill-formed since the type of the string literal is <tt>const char[6]</tt>.
-</p>
-
-<p>
-By changing the signature to take all parameters by value we can
-eliminate the <tt>CopyConstructible</tt> requirement and permit the use of
-arrays, as the parameter passing semantics will cause the necessary
-array-to-pointer decay. They will also cause the function name to
-decay to a pointer to function and allow the implementation to handle
-functions and function objects identically.
-</p>
-
+<p><b>Addresses UK 208</b></p>
 <p>
-The new signature of the <tt>thread</tt> constructor for a function and
-arguments is thus:
+I don't see an open issue on supporting <tt>std::hash</tt> for smart pointers
+(<tt>unique_ptr</tt> and <tt>shared_ptr</tt> at least).
 </p>
-
-<blockquote><pre>template&lt;typename F,typename... Args&gt;
-thread(F,Args... args);
-</pre></blockquote>
-
 <p>
-Since the parameter pack <tt>Args</tt> can be empty, the single-parameter
-constructor that takes just a function by value is now redundant.
+It seems reasonable to at least expect support for the smart
+pointers, especially as they support comparison for use in ordered
+associative containers.
 </p>
 
 <p><i>[
-Howard adds:
+Batavia (2009-05):
 ]</i></p>
 
-
 <blockquote>
 <p>
-I agree with everything Anthony says in this issue.  However I believe we
-can optimize in such a way as to get the pass-by-value behavior with the
-pass-by-rvalue-ref performance.  The performance difference is that the latter
-removes a <tt>move</tt> when passing in an lvalue.
+Howard points out that the client can always supply a custom hash function.
 </p>
-
 <p>
-This circumstance is very analogous to <tt>make_pair</tt> (20.3.3 [pairs])
-where we started with passing by const reference, changed to pass by value to
-get pointer decay, and then changed to pass by rvalue reference, but modified with
-<tt>decay&lt;T&gt;</tt> to retain the pass-by-value behavior.  If we were to
-apply the same solution here it would look like:
+Alisdair replies that the smart pointer classes are highly likely
+to be frequently used as hash keys.
 </p>
-
-<blockquote><pre><del>template &lt;class F&gt; explicit thread(F f);</del>
-template &lt;class F, class ...Args&gt; thread(F&amp;&amp; f, Args&amp;&amp;... args);
-</pre>
-<blockquote>
 <p>
--4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall be <del><tt>CopyConstructible</tt>
-if an lvalue and otherwise</del> <tt>MoveConstructible</tt>.
-<tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.7.2 [func.require]) shall be a valid expression for
-some values <tt>w1, w2, ... , wN,</tt> where <tt>N == sizeof...(Args)</tt>.
+Bill would prefer to be conservative.
 </p>
 <p>
--5- <i>Effects:</i> Constructs an object of type <tt>thread</tt>
-<del>and executes <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> in a new
-thread of execution, where <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>.
-<ins>Constructs
-the following objects in memory which is accessible to a new thread of execution
-as if:</ins>
+Alisdair mentions that this issue may also be viewed as a subissue or
+duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.
 </p>
-<blockquote><pre><ins>typename decay&lt;F&gt;::type g(std::forward&lt;F&gt;(f));</ins>
-<ins>tuple&lt;typename decay&lt;Args&gt;::type...&gt; w(std::forward&lt;Args&gt;(args)...);</ins>
-</pre></blockquote>
 <p>
-<ins>The new thread of
-execution executes <tt><i>INVOKE</i>(g, wi...)</tt> where the <tt>wi...</tt> refers
-to the elements stored in the <tt>tuple w</tt>.</ins>
-Any return value from <tt>g</tt> is ignored.
-<del>If <tt>f</tt> terminates with an uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
-<ins>If the evaluation of <tt><i>INVOKE</i>(g,  wi...)</tt> terminates
-with an uncaught exception, <tt>std::terminate()</tt> shall be called [<i>Note:</i>
-<tt>std::terminate()</tt> could be called before entering <tt>g</tt>. -- <i>end note</i>]. Any
-exception thrown before the evaluation of <tt><i>INVOKE</i></tt> has started shall be
-catchable in the calling thread.</ins>
+Move to Open, and recommend the issue be deferred until after the next
+Committee Draft is issued.
 </p>
 </blockquote>
-</blockquote>
 
+<p><i>[
+2009-05-31 Peter adds:
+]</i></p>
+
+
+<blockquote>
+<blockquote>
+Howard points out that the client can always supply a custom hash function.
+</blockquote>
 <p>
-Text referring to when <tt>terminate()</tt> is called was contributed by Ganesh.
+Not entirely true. The client cannot supply the function that hashes the
+address of the control block (the equivalent of the old <tt>operator&lt;</tt>, now
+proudly carrying the awkward name of '<tt>owner_before</tt>'). Only the
+implementation can do that, not necessarily via specializing <tt>hash&lt;&gt;</tt>, of
+course.
+</p>
+<p>
+This hash function makes sense in certain situations for <tt>shared_ptr</tt>
+(when one needs to switch from <tt>set/map</tt> using ownership ordering to
+<tt>unordered_set/map</tt>) and is the only hash function that makes sense for
+<tt>weak_ptr</tt>.
 </p>
-
 </blockquote>
 
 <p><i>[
-Batavia (2009-05):
+2009-07-28 Alisdair provides wording.
 ]</i></p>
 
-<blockquote>
-We agree with the proposed resolution,
-but would like the final sentence to be reworded
-since "catchable" is not a term of art (and is used nowhere else).
-</blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-<p>
-This is linked to
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2901.pdf">N2901</a>.
-</p>
-<p>
-Howard to open a separate issue to remove (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1176">1176</a>).
-</p>
-<p>
-In Frankfurt there is no consensus for removing the variadic constructor.
-</p>
+Move to Ready.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Modify the class definition of <tt>std::thread</tt> in 30.3.1 [thread.thread.class] to remove the
-following signature:
+Add the following declarations to the synopsis of <tt>&lt;memory&gt;</tt>
+in 20.8 [memory]
 </p>
 
-<blockquote><pre><del>template&lt;class F&gt; explicit thread(F f);</del>
-template&lt;class F, class ... Args&gt; <ins>explicit</ins> thread(F&amp;&amp; f, Args&amp;&amp; ... args);
+<blockquote><pre>// 20.8.10.X hash support
+template &lt;class T&gt; struct hash;
+template &lt;class T, class D&gt; struct hash&lt;unique_ptr&lt;T,D&gt;&gt;;
+template &lt;class T&gt; struct hash&lt;shared_ptr&lt;T&gt;&gt;;
 </pre></blockquote>
 
 <p>
-Modify 30.3.1.2 [thread.thread.constr] to replace the constructors prior to paragraph 4 with
-the single constructor as above. Replace paragraph 4 - 6 with the
-following:
+Add a new subclause 20.8.10.X hash support
 </p>
 
 <blockquote>
 <p>
--4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall be <del><tt>CopyConstructible</tt>
-if an lvalue and otherwise</del> <tt>MoveConstructible</tt>.
-<tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.7.2 [func.require]) shall be a valid expression for
-some values <tt>w1, w2, ... , wN,</tt> where <tt>N == sizeof...(Args)</tt>.
-</p>
-<p>
--5- <i>Effects:</i> Constructs an object of type <tt>thread</tt>
-<del>and executes <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> in a new
-thread of execution, where <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>.
-<ins>Constructs
-the following objects:</ins>
+20.8.10.X hash support [util.smartptr.hash]
 </p>
-<blockquote><pre><ins>typename decay&lt;F&gt;::type g(std::forward&lt;F&gt;(f));</ins>
-<ins>tuple&lt;typename decay&lt;Args&gt;::type...&gt; w(std::forward&lt;Args&gt;(args)...);</ins>
-</pre></blockquote>
-<p>
-<ins>and executes <tt><i>INVOKE</i>(g, wi...)</tt> in a new thread of execution.
-These objects shall be destroyed when the new thread of execution completes.</ins>
-Any return value from <tt>g</tt> is ignored.
-<del>If <tt>f</tt> terminates with an uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
-<ins>If the evaluation of <tt><i>INVOKE</i>(g,  wi...)</tt> terminates
-with an uncaught exception, <tt>std::terminate()</tt> shall be called [<i>Note:</i>
-<tt>std::terminate()</tt> could be called before entering <tt>g</tt>. -- <i>end note</i>]. Any
-exception thrown before the evaluation of <tt><i>INVOKE</i></tt> has started shall be
-catchable in the calling thread.</ins>
-</p>
-<p>
--6- <i>Synchronization:</i> The invocation of the constructor <i>happens before</i> the
-invocation of <del><tt>f</tt></del> <ins><tt>g</tt></ins>.
-</p>
-</blockquote>
-
-
-
-
 
-
-<hr>
-<h3><a name="930"></a>930. Access to std::array data as built-in array type</h3>
-<p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-11-17  <b>Last modified:</b> 2009-07-31</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-The Working Draft (N2798) allows access to the elements of
-<tt>std::array</tt> by its <tt>data()</tt> member function:
-</p>
+<pre>template &lt;class T, class D&gt; struct hash&lt;unique_ptr&lt;T,D&gt;&gt;;
+</pre>
 
 <blockquote>
-
-<h5>23.2.1.4 array::data [array.data]</h5>
-<pre> T *data();
- const T *data() const;
-</pre>
-<ol><li>
- Returns: elems.
-</li></ol>
+A partial specialization of the class template <tt>hash</tt> (20.7.16 [unord.hash]) shall be provided for instances of the
+<tt>unique_ptr</tt> template suitable for use as a key in unordered
+associative containers (23.5 [unord]) if and only if there is a
+<tt>hash</tt> specialization available for the type <tt>D::pointer</tt>.
+For an object <tt>p</tt> of type <tt>unqiue_ptr&lt;T,D&gt;</tt> the
+<tt>hash</tt> shall evaluate to the same value as <tt>hash&lt;typename
+D::pointer&gt;{}(p.get())</tt>.
 </blockquote>
 
-<p>
-Unfortunately, the result of <tt>std::array::data()</tt> cannot be bound
-to a reference to a built-in array of the type of <tt>array::elems</tt>.
-And <tt>std::array</tt> provides no other way to get a reference to
-<tt>array::elems</tt>. 
-This hampers the use of <tt>std::array</tt>, for example when trying to
-pass its data to a C style API function:
-</p>
-
-<pre> // Some C style API function. 
- void set_path( char (*)[MAX_PATH] );
-
- std::array&lt;char,MAX_PATH&gt; path;
- set_path( path.data() );  // error
- set_path( &amp;(path.data()) );  // error
+<pre>template &lt;class T&gt; struct hash&lt;shared_ptr&lt;T&gt;&gt;;
 </pre>
 
- <p>
-Another example, trying to pass the array data to an instance of another
-C++ class:
-</p>
+<blockquote>
+A partial specialization of the class template <tt>hash</tt> (20.7.16 [unord.hash])
+shall be provided for instances of the <tt>shared_ptr</tt> template
+suitable for use as a key in unordered associative containers
+(23.5 [unord]). For an object <tt>p</tt> of type <tt>shared_ptr&lt;T&gt;</tt>
+the <tt>hash</tt> shall evaluate
+to the same value as <tt>hash&lt;T*&gt;{}(p.get())</tt>.
+</blockquote>
+</blockquote>
+
 
-<pre> // Represents a 3-D point in space.
- class three_d_point {
- public:
-   explicit three_d_point(const double (&amp;)[3]); 
- };
 
- const std::array&lt;double,3&gt; coordinates = { 0, 1, 2 };
- three_d_point point1( coordinates.data() );  // error.
- three_d_point point2( *(coordinates.data()) );  // error.
-</pre>
 
-<p>
-A user might be tempted to use <tt>std::array::elems</tt> instead, but
-doing so isn't recommended, because <tt>std::array::elems</tt> is "for
-exposition only".  Note that Boost.Array users might already use
-<tt>boost::array::elems</tt>, as its documentation doesn't explicitly
-state that <tt>boost::array::elems</tt> is for exposition only:
-http://www.boost.org/doc/libs/1_36_0/doc/html/boost/array.html
-</p>
-<p>
-I can think of three options to solve this issue:
-</p>
-<ol><li>
-Remove the words "exposition only" from the definition of
-<tt>std::array::elems</tt>, as well as the note saying that "elems is
-shown for exposition only."
-</li><li>
-Change the signature of <tt>std::array::data()</tt>, so that it would
-return a reference to the built-in array, instead of a pointer to its
-first element.
-</li><li>
-Add extra member functions, returning a reference to the built-in array.
-</li></ol>
-<p>
-Lawrence Crowl wrote me that it might be better to leave
-<tt>std::array::elems</tt> "for exposition only", to allow alternate
-representations to allocate the array data dynamically.  This might be
-of interest to the embedded community, having to deal with very limited
-stack sizes.
-</p>
-<p>
-The second option, changing the return type of
-<tt>std::array::data()</tt>, would break backward compatible to current
-Boost and TR1 implementations, as well as to the other contiguous
-container (<tt>vector</tt> and <tt>string</tt>) in a very subtle way.
-For example, the following call to <tt>std::swap</tt> currently swap two
-locally declared pointers <tt>(data1, data2)</tt>, for any container
-type <tt>T</tt> that has a <tt>data()</tt> member function. When
-<tt>std::array::data()</tt> is changed to return a reference, the
-<tt>std::swap</tt> call may swap the container elements instead.
-</p>
-
-<pre> template &lt;typename T&gt;
- void func(T&amp; container1, T&amp; container2)
- {
-   // Are data1 and data2 pointers or references?
-   auto data1 = container1.data();
-   auto data2 = container2.data();
-
-   // Will this swap two local pointers, or all container elements?
-   std::swap(data1, data2);
- }
-</pre>
 
+<hr>
+<h3><a name="983"></a>983. <tt>unique_ptr</tt> reference deleters should not be moved from</h3>
+<p><b>Section:</b> 20.8.14.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-10  <b>Last modified:</b> 2009-10-21</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single">active issues</a> in [unique.ptr.single].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-The following concept is currently satisfied by all contiguous
-containers, but it no longer is for <tt>std::array</tt>, when
-<tt>array::data()</tt>
-is changed to return a reference (tested on ConceptGCC Alpha 7):
+Dave brought to my attention that when a <tt>unique_ptr</tt> has a non-const reference
+type deleter, move constructing from it, even when the <tt>unique_ptr</tt> containing
+the reference is an rvalue, could have surprising results:
 </p>
 
-<pre> auto concept ContiguousContainerConcept&lt;typename T&gt;
- {
-   typename value_type = typename T::value_type;
-   const value_type * T::data() const;
- }
-</pre>
+<blockquote><pre>D d(some-state);
+unique_ptr&lt;A, D&amp;&gt; p(new A, d);
+unique_ptr&lt;A, D&gt; p2 = std::move(p);
+<font color="#c80000">// has d's state changed here?</font>
+</pre></blockquote>
 
 <p>
-Still it's worth considering having <tt>std::array::data()</tt> return a
-reference, because it might be the most intuitive option, from a user's
-point of view.  Nicolai Josuttis (who wrote <tt>boost::array</tt>)
-mailed me that he very much prefers this option.
-</p>
-<p>
-Note that for this option, the definition of <tt>data()</tt> would also
-need to be revised for zero-sized arrays, as its return type cannot be a
-reference to a zero-sized built-in array.  Regarding zero-sized array,
-<tt>data()</tt> could throw an exception.  Or there could be a partial
-specialization of <tt>std::array</tt> where <tt>data()</tt> returns
-<tt>T*</tt> or gets removed.
+I agree with him.  It is the <tt>unique_ptr</tt> that is the rvalue, not the
+deleter.  When the deleter is a reference type, the <tt>unique_ptr</tt> should
+respect the "lvalueness" of the deleter.
 </p>
+
 <p>
-Personally I prefer the third option, adding a new member function to
-<tt>std::array</tt>, overloaded for const and non-const access,
-returning a reference to the built-in array, to avoid those compatible
-issues. I'd propose naming the function <tt>std::array::c_array()</tt>,
-which sounds intuitive to me. Note that <tt>boost::array</tt> already
-has a <tt>c_array()</tt> member, returning a pointer, but Nicolai told
-me that this one is only there for historical reasons. (Otherwise a name
-like <tt>std::array::native_array()</tt> or
-<tt>std::array::builtin_array()</tt> would also be fine with me.) 
-According to my proposed resolution, a zero-sized <tt>std::array</tt> does not need
-to have <tt>c_array()</tt>, while it is still required to have
-<tt>data()</tt> functions.
+Thanks Dave.
 </p>
 
 <p><i>[
-Post Summit:
+Batavia (2009-05):
 ]</i></p>
 
-
 <blockquote>
+Seems correct, but complicated enough that we recommend moving to Review.
+</blockquote>
 
-<p>
-Alisdair: Don't like p4 suggesting implementation-defined behaviour.
-</p>
-<p>
-Walter: What about an explicit conversion operator, instead of adding
-the new member function?
-</p>
-<p>
-Alisdair: Noodling about:
-</p>
-<blockquote><pre>template&lt;size_t N, ValueType T&gt;
-struct array
-{
-  T elems[N];
-
-// fantasy code starts here
-
-// crazy decltype version for grins only
-//requires True&lt;(N&gt;0)&gt;
-//explict operator decltype(elems) &amp; () { return elems; }
-
-// conversion to lvalue ref
-requires True&lt;(N&gt;0)&gt;
-explict operator T(&amp;)[N] () &amp; { return elems; }
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
-// conversion to const lvalue ref
-requires True&lt;(N&gt;0)&gt;
-explict operator const T(&amp;)[N] () const &amp; { return elems; }
 
-// conversion to rvalue ref using ref qualifiers
-requires True&lt;(N&gt;0)&gt;
-explict operator T(&amp;&amp;)[N] () &amp;&amp; { return elems; }
+<blockquote>
+Move to Ready.
+</blockquote>
 
-// fantasy code ends here
 
-explicit operator bool() { return true; }
-};
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-This seems legal but odd. Jason Merrill says currently a CWG issue 613
-on the non-static data member that fixes the error that current G++
-gives for the non-explicit, non-conceptualized version of this. Verdict
-from human compiler: seems legal.
-</p>
-<p>
-Some grumbling about zero-sized arrays being allowed and supported.
-</p>
-<p>
-Walter: Would this address the issue? Are we inclined to go this route?
-</p>
-<p>
-Alan: What would usage look like?
+Change 20.8.14.2.1 [unique.ptr.single.ctor], p20-21
 </p>
-<blockquote><pre>// 3-d point in space
-struct three_d_point
-{
-  explicit three_d_point(const double (&amp;)[3]);
-};
 
-void sink(double*);
+<blockquote>
+<pre>template &lt;class U, class E&gt; unique_ptr(unique_ptr&lt;U, E&gt;&amp;&amp; u);
+</pre>
 
-const std::array&lt;double, 3&gt; coordinates = { 0, 1, 2 };
-three_d_point point1( coordinates.data() ); //error
-three_d_point point2( *(coordinates.data()) ); // error
-three_d_point point3( coordinates ); // yay!
+<blockquote>
 
-sink(cooridinates); // error, no conversion
-</pre></blockquote>
+<p>
+-20- <i>Requires:</i> If <tt><del>D</del> <ins>E</ins></tt> is not a reference type,
+construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
+shall be well formed and shall not throw an exception.
+<ins>
+Otherwise <tt>E</tt> is a reference type and construction of the deleter
+<tt>D</tt> from an lvalue of type <tt>E</tt> shall be well formed and
+shall not throw an exception.
+</ins>
+If <tt>D</tt> is
+a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>
+(diagnostic required). <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be
+implicitly convertible to <tt>pointer</tt>. [<tt>Note:</tt> These
+requirements imply that <tt>T</tt> and <tt>U</tt> are complete types.
+<i>-- end note</i>]
+</p>
 
 <p>
-Recommended Open with new wording. Take the required clause and add the
-explicit conversion operators, not have a <tt>typedef</tt>. At issue still is use
-<tt>decltype</tt> or use <tt>T[N]</tt>. In favour of using <tt>T[N]</tt>, even though use of
-<tt>decltype</tt> is specially clever.
+-21- <i>Effects:</i> Constructs a <tt>unique_ptr</tt> which owns the
+pointer which <tt>u</tt> owns (if any). If the deleter
+<ins><tt>E</tt></ins> is not a reference type, <del>it</del> <ins>this
+deleter</ins> is move constructed from <tt>u</tt>'s deleter, otherwise
+<del>the reference</del> <ins>this deleter</ins> is copy constructed
+from <tt>u</tt>.'s deleter. After the construction, <tt>u</tt> no longer
+owns a pointer. [<i>Note:</i> The deleter constructor can be implemented
+with <tt>std::forward&lt;<del>D</del><ins>E</ins>&gt;</tt>. <i>-- end
+note</i>]
 </p>
 
 </blockquote>
+</blockquote>
 
-<p><i>[
-Post Summit, further discussion in the thread starting with c++std-lib-23215.
-]</i></p>
-
-
-<p><i>[
-2009-07 post-Frankfurt (Saturday afternoon group):
-]</i></p>
-
-
-<blockquote>
-<p>
-The idea to resolve the issue by adding explicit conversion operators
-was abandoned, because it would be inconvenient to use, especially when
-passing the array to a template function, as mentioned by Daniel. So we
-reconsidered the original proposed resolution, which appeared
-acceptable, except for its proposed changes to 23.3.1.6 [array.zero], which
-allowed <tt>c_array_type</tt> and <tt>c_array()</tt> to be absent for a zero-sized array.
-Alisdair argued that such wording would disallow certain generic use
-cases. New wording for 23.3.1.6 [array.zero] was agreed upon (Howard: and
-is reflected in the proposed resolution).
-</p>
 <p>
-Move to Review
+Change 20.8.14.2.3 [unique.ptr.single.asgn], p1-3
 </p>
-</blockquote>
-
-<p><i>[
-2009-07-31 Alisdair adds:
-]</i></p>
-
 
 <blockquote>
+<pre>unique_ptr&amp; operator=(unique_ptr&amp;&amp; u);
+</pre>
+<blockquote>
+
 <p>
-I will be unhappy voting the proposed resolution for 930 past review
-until we have implementation experience with reference qualifiers. 
-Specifically, I want to understand the impact of the missing overload
-for <tt>const &amp;&amp;</tt> (if any.)
+-1- <i>Requires:</i> <ins>If the deleter <tt>D</tt> is not a reference type,</ins>
+<del>A</del><ins>a</ins>ssignment of the deleter <tt>D</tt> from an rvalue <tt>D</tt> shall not throw an exception.
+<ins>
+Otherwise the deleter <tt>D</tt> is a reference type,
+and assignment of the deleter <tt>D</tt> from an lvalue <tt>D</tt> shall not throw an exception.</ins>
 </p>
 
 <p>
-If we think the issue is important enough it might be worthwhile
-stripping the ref qualifiers for easy progress next meeting, and opening
-yet another issue to put them back with experience.
+-2- <i>Effects:</i> reset(u.release()) followed by
+a<ins>n</ins> <del>move</del> assignment from <del><tt>u</tt>'s deleter to this deleter</del>
+<ins><tt>std::forward&lt;D&gt;(u.get_deleter())</tt></ins>.
 </p>
 
 <p>
-Recommend deferring any decision on splitting the issue until we get LWG
-feedback next meeting - I may be the lone dissenting voice if others are
-prepared to proceed without it.
+-3- <i>Postconditions:</i> This <tt>unique_ptr</tt> now owns the pointer
+which <tt>u</tt> owned, and <tt>u</tt> no longer owns it. <del>[<i>Note:</i> If
+<tt>D</tt> is a reference type, then the referenced lvalue deleters are
+move assigned. <i>-- end note</i>]</del>
 </p>
 </blockquote>
+</blockquote>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Add to the template definition of array, 23.3.1 [array]/3:
+Change 20.8.14.2.3 [unique.ptr.single.asgn], p6-7
 </p>
 
 <blockquote>
-<pre><ins>
-typedef T c_array_type[N];
-c_array_type &amp; c_array() &amp;;
-c_array_type &amp;&amp; c_array() &amp;&amp;;
-const c_array_type &amp; c_array() const &amp;;
-</ins>
+<pre>template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u);
 </pre>
-</blockquote>
+<blockquote>
 
 <p>
-Add the following subsection to 23.3.1 [array], after 23.3.1.4 [array.data]:
+<i>Requires:</i> <ins>If the deleter <tt>E</tt> is not a reference type,</ins>
+<del>A</del><ins>a</ins>ssignment of the deleter <tt>D</tt> from an rvalue
+<tt><del>D</del><ins>E</ins></tt> shall not throw an exception.
+<ins>
+Otherwise the deleter <tt>E</tt> is a reference type,
+and assignment of the deleter <tt>D</tt> from an lvalue <tt>E</tt> shall not throw an exception.</ins>
+<tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>.
+[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U&gt;</tt>
+are complete types. <i>-- end note</i>]
 </p>
 
-<blockquote>
-<h5><ins>23.2.1.5 array::c_array [array.c_array]</ins></h5>
-    <pre><ins>
-c_array_type &amp; c_array() &amp;;
-c_array_type &amp;&amp; c_array() &amp;&amp;;
-const c_array_type &amp; c_array() const &amp;;
-</ins></pre>
-<blockquote>
 <p>
-<ins><i>Returns:</i> <tt>elems</tt>.</ins>
+<i>Effects:</i> <tt>reset(u.release())</tt> followed by
+a<ins>n</ins> <del>move</del> assignment from <del><tt>u</tt>'s deleter to this deleter</del>
+<ins><tt>std::forward&lt;E&gt;(u.get_deleter())</tt></ins>.
+<del>If either
+<tt>D</tt> or <tt>E</tt> is a reference type, then the referenced lvalue
+deleter participates in the move assignment.</del>
 </p>
-</blockquote>
 
 </blockquote>
+</blockquote>
 
 
 
-<p>
-Change Zero sized arrays 23.3.1.6 [array.zero]:
-</p>
-
-<blockquote>
 
-<p>-2- ...</p>
 
-<p><ins>
-The type <tt>c_array_type</tt> is unspecified for a zero-sized array.
-</ins></p>
 
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Rani Sharoni <b>Opened:</b> 2009-02-12  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
--3- The effect of calling <ins><tt>c_array()</tt>,</ins> <tt>front()</tt><ins>,</ins> or
-<tt>back()</tt> for a zero-sized array is implementation defined.
+<b>Introduction</b>
 </p>
-</blockquote>
-
-
-
 
+<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>
 
-<hr>
-<h3><a name="932"></a>932. <tt>unique_ptr(pointer p)</tt> for pointer deleter types</h3>
-<p><b>Section:</b> 20.8.9.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-11-26  <b>Last modified:</b> 2009-07-27</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.ctor">active issues</a> in [unique.ptr.single.ctor].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></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><b>Addresses US 79</b></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>
-20.8.9.2.1 [unique.ptr.single.ctor]/5 no longer requires for <tt>D</tt>
-not to be a pointer type.  I believe this restriction was accidently removed
-when we relaxed the completeness reuqirements on <tt>T</tt>. The restriction
-needs to be put back in.  Otherwise we have a run time failure that could
-have been caught at compile time:
+<b>Regression</b>
 </p>
 
-<blockquote><pre>{
-unique_ptr&lt;int, void(*)(void*)&gt; p1(malloc(sizeof(int)));  <font color="#c80000">// should not compile</font>
-}  <font color="#c80000">// p1.~unique_ptr() dereferences a null function pointer</font>
-unique_ptr&lt;int, void(*)(void*)&gt; p2(malloc(sizeof(int)), free);  <font color="#c80000">// ok</font>
-</pre></blockquote>
+<p>This section only refers to cases in which the contained object
+is by itself a standard container.</p>
 
-<p><i>[
-Post Summit:
-]</i></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>
 
-<blockquote>
-Recommend Tentatively Ready.
-</blockquote>
+<p>There are few options to solve this regression:</p>
 
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
+<ol>
+<li>
+Disallow throwing move and throwing default constructor
+</li>
 
+<li>
+Disallow throwing move but disallowing usage after move
+</li>
 
-<blockquote>
-Moved from Tentatively Ready to Open only because the wording needs to be
-improved for enable_if type constraining, possibly following Robert's
-formula.
-</blockquote>
+<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>[
-2009-07 Frankfurt:
+Batavia (2009-05):
 ]</i></p>
 
-
 <blockquote>
 <p>
-We need to consider whether some requirements in the Requires paragraphs
-of [unique.ptr] should instead be Remarks.
+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>
-Leave Open. Howard to provide wording, and possibly demonstrate how this
-can be implemented using enable_if.
+Move to Open and recommend it be deferred until after the next
+Committee Draft is issued.
 </p>
 </blockquote>
 
 <p><i>[
-2009-07-27 Howard adds:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-<p>
-The two constructors to which this issue applies are not easily constrained
-with <tt>enable_if</tt> as they are not templated:
-</p>
+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>
 
-<blockquote><pre>unique_ptr();
-explicit unique_ptr(pointer p);
-</pre></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
 
 <p>
-To "SFINAE" these constructors away would take heroic effort such as specializing
-the entire <tt>unique_ptr</tt> class template on pointer deleter types.  There
-is insufficient motivation for such heroics.  Here is the expected and
-reasonable implementation for these constructors:
+23.2.1 [container.requirements.general]  paragraph 10 add footnote:
 </p>
 
-<blockquote><pre>unique_ptr()
-    : ptr_(pointer())
-    {
-        static_assert(!is_pointer&lt;deleter_type&gt;::value,
-            "unique_ptr constructed with null function pointer deleter");
-    }
-explicit unique_ptr(pointer p)
-    : ptr_(p)
-    {
-        static_assert(!is_pointer&lt;deleter_type&gt;::value,
-            "unique_ptr constructed with null function pointer deleter");
-    }
-</pre></blockquote>
-
+<blockquote>
 <p>
-I.e. just use <tt>static_assert</tt> to verify that the constructor is not
-instantiated with a function pointer for a deleter.  The compiler will automatically
-take care of issuing a diagnostic if the deleter is a reference type (uninitialized
-reference error).
+-10- 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>
-In keeping with our discussions in Frankfurt, I'm moving this requirement on
-the implementation from the Requires paragraph to a Remarks paragraph.
+<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>
 
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
 <p>
-Change the description of the default constructor in 20.8.9.2.1 [unique.ptr.single.ctor]:
+-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>
 
-<blockquote><pre>unique_ptr();
-</pre>
-<blockquote>
 <p>
--1- <i>Requires:</i> <tt>D</tt> shall be default constructible, and that construction
-shall not throw an exception. <del><tt>D</tt> shall 
-not be a reference type or pointer type (diagnostic required).</del>
-</p>
-<p>...</p>
-<ins><i>Remarks:</i> A diagnostic shall be emitted if this constructor is instantiated
-when <tt>D</tt> is a pointer type or reference type.</ins>
-</blockquote>
+-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>
-Add  after 20.8.9.2.1 [unique.ptr.single.ctor]/8:
+23.3.2.3 [deque.modifiers] change paragraph 2 to say:
 </p>
 
-<blockquote><pre>unique_ptr(pointer p);
-</pre>
 <blockquote>
-<p>...</p>
-<ins><i>Remarks:</i> A diagnostic shall be emitted if this constructor is instantiated
-when <tt>D</tt> is a pointer type or reference type.</ins>
-</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.2.3 [deque.modifiers] change paragraph 6 to say:
+</p>
 
+<blockquote>
+-6- <i>Throws:</i> Nothing unless an exception is thrown by the copy
+constructor<ins>, move constructor</ins> or assignment operator of <tt>T</tt>.
+</blockquote>
 
+<p>
+23.3.6.2 [vector.capacity] remove paragraph 2
+</p>
 
+<blockquote>
+<del>-2- <i>Requires:</i> If <tt>value_type</tt> has a move constructor,
+that constructor shall not throw any exceptions.</del>
+</blockquote>
 
-<hr>
-<h3><a name="933"></a>933. Unique_ptr defect</h3>
-<p><b>Section:</b> 20.8.9.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-11-27  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.modifiers">issues</a> in [unique.ptr.single.modifiers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-If we are supporting stateful deleters, we need an overload for
-<tt>reset</tt> that
-takes a deleter as well.
+23.3.6.2 [vector.capacity] paragraph 3 change to say:
 </p>
 
-<blockquote><pre>void reset( pointer p, deleter_type d);
-</pre></blockquote>
+<blockquote>
+-3- <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>
-We probably need two overloads to support move-only deleters, and
-this
-sounds uncomfortably like the two constructors I have been ignoring
-for
-now...
+23.3.6.2 [vector.capacity] paragraph 12 change to say:
 </p>
 
-<p><i>[
-Batavia (2009-05):
-]</i></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>
-Howard comments that we have the functionality via move-assigment.
+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>
+
 <p>
-Move to Open.
+23.3.6.4 [vector.modifiers] change paragraph 2 to say:
 </p>
-</blockquote>
 
+<blockquote>
+-2- <i>Remarks:</i> Causes reallocation if the new size is greater than
+the old capacity. If no reallocation happens, all the iterators and
+references before the insertion point remain valid. If an exception is
+thrown other than by the copy constructor<ins>, move constructor</ins>
+or assignment operator of <tt>T</tt> or by any <tt>InputIterator</tt>
+operation there are no effects.
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
+23.3.6.4 [vector.modifiers] change paragraph 6 to say:
 </p>
 
+<blockquote>
+-6- <i>Throws:</i> Nothing unless an exception is thrown by the copy
+constructor<ins>, move constructor</ins> or assignment operator of <tt>T</tt>.
+</blockquote>
 
 
 
 
-<hr>
-<h3><a name="934"></a>934. <tt>duration</tt> is missing <tt>operator%</tt></h3>
-<p><b>Section:</b> 20.9.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Terry Golubiewski <b>Opened:</b> 2008-11-30  <b>Last modified:</b> 2009-07-27</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.duration">active issues</a> in [time.duration].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration">issues</a> in [time.duration].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p><b>Addresses US 81</b></p>
 
-<p>
-<tt>duration</tt> is missing <tt>operator%</tt>.  This operator is convenient
-for computing where in a time frame a given <tt>duration</tt> lies.  A
-motivating example is converting a <tt>duration</tt> into a "broken-down"
-time duration such as hours::minutes::seconds:
-</p>
 
-<blockquote><pre>class ClockTime
-{
-    typedef std::chrono::hours hours;
-    typedef std::chrono::minutes minutes;
-    typedef std::chrono::seconds seconds;
-public:
-    hours hours_;
-    minutes minutes_;
-    seconds seconds_;
-
-    template &lt;class Rep, class Period&gt;
-      explicit ClockTime(const std::chrono::duration&lt;Rep, Period&gt;&amp; d)
-        : hours_  (std::chrono::duration_cast&lt;hours&gt;  (d)),
-          minutes_(std::chrono::duration_cast&lt;minutes&gt;(d % hours(1))),
-          seconds_(std::chrono::duration_cast&lt;seconds&gt;(d % minutes(1)))
-          {}
-};
-</pre></blockquote>
+<hr>
+<h3><a name="987"></a>987. <tt>reference_wrapper</tt> and function types</h3>
+<p><b>Section:</b> 20.7.5 [refwrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-18  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap">issues</a> in [refwrap].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The synopsis in 20.7.5 [refwrap] says:
+</p>
 
-<p><i>[
-Summit:
-]</i></p>
+<blockquote><pre>template &lt;<b>ObjectType</b> T&gt; class reference_wrapper
+...
+</pre></blockquote>
 
+<p>
+And then paragraph 3 says:
+</p>
 
 <blockquote>
-Agree except that there is a typo in the proposed resolution. The member
-operators should be operator%=.
+<p>
+The template instantiation <tt>reference_wrapper&lt;T&gt;</tt> shall be
+derived from <tt>std::unary_function&lt;T1, R&gt;</tt> only if the type
+<tt>T</tt> is any of the following:
+</p>
+
+<ul>
+<li>
+a <b>function type</b> or a pointer to function type taking one argument of
+type <tt>T1</tt> and returning <tt>R</tt>
+</li>
+</ul>
 </blockquote>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<p>
+But function types are not <tt>ObjectType</tt>s.
+</p>
 
-<blockquote>
-We agree with the proposed resolution.
-Move to Tentatively Ready.
-</blockquote>
+<p>
+Paragraph 4 contains the same contradiction.
+</p>
 
 <p><i>[
-2009-07 Frankfurt
+Post Summit:
 ]</i></p>
 
 
 <blockquote>
-Moved from Tentatively Ready to Open only because the wording needs to be
-improved for enable_if type constraining, possibly following Robert's
-formula.
+<p>
+Jens: restricted reference to ObjectType
+</p>
+<p>
+Recommend Review.
+</p>
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+Post Summit, Peter adds:
 ]</i></p>
 
 
 <blockquote>
 <p>
-Howard to open a separate issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a>) to handle the removal of member
-functions from overload sets, provide wording, and possibly demonstrate
-how this can be implemented using enable_if (see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>).
+In <a href="https://svn.boost.org/trac/boost/ticket/1846">https://svn.boost.org/trac/boost/ticket/1846</a>
+however Eric Niebler makes the very reasonable point that <tt>reference_wrapper&lt;F&gt;</tt>,
+where <tt>F</tt> is a function type, represents a reference to a function,
+a legitimate entity. So <tt>boost::ref</tt> was changed to allow it.
 </p>
 <p>
-Move to Ready.
+<a href="https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp">https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp</a>
+</p>
+<p>
+Therefore, I believe an alternative proposed resolution for issue 987 could simply
+allow <tt>reference_wrapper</tt> to be used with function types.
 </p>
 </blockquote>
 
+<p><i>[
+Post Summit, Howard adds:
+]</i></p>
 
 
-<p><b>Proposed resolution:</b></p>
+<blockquote>
 <p>
-Add to the synopsis in 20.9 [time]:
+I agree with Peter (and Eric).  I got this one wrong on my first try.  Here
+is code that demonstrates how easy (and useful) it is to instantiate
+<tt>reference_wrapper</tt> with a function type:
 </p>
 
-<blockquote><pre>template &lt;class Rep1, class Period, class Rep2&gt;
-  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
-  operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
-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
-  operator%(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
+<blockquote><pre>#include &lt;functional&gt;
+
+template &lt;class F&gt;
+void test(F f);
+
+void f() {}
+
+int main()
+{
+    test(std::ref(f));
+}
 </pre></blockquote>
 
 <p>
-Add to the synopsis of <tt>duration</tt> in 20.9.3 [time.duration]:
+Output (link time error shows type of <tt>reference_wrapper</tt> instantiated
+with function type):
 </p>
 
-<blockquote><pre>template &lt;class Rep, class Period = ratio&lt;1&gt;&gt;
-class duration {
-public:
-  ...
-  <ins>duration&amp; operator%=(const rep&amp; rhs);</ins>
-  <ins>duration&amp; operator%=(const duration&amp; d);</ins>
-  ...
-};
+<blockquote><pre>Undefined symbols:
+  "void test&lt;std::reference_wrapper&lt;void ()()&gt; &gt;(std::reference_wrapper&lt;void ()()&gt;)",...
 </pre></blockquote>
 
 <p>
-Add to 20.9.3.3 [time.duration.arithmetic]:
+I've taken the liberty of changing the proposed wording to allow function types
+and set to Open.  I'll also freely admit that I'm not positive <tt>ReferentType</tt>
+is the correct concept.
 </p>
 
-<blockquote>
-<pre>duration&amp; operator%=(const rep&amp; rhs);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> <tt>rep_ %= rhs</tt>.
-</p>
-<p>
-<i>Returns:</i> <tt>*this</tt>.
-</p>
 </blockquote>
 
-<pre>duration&amp; operator%=(const duration&amp; d);
-</pre>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
 <blockquote>
 <p>
-<i>Effects:</i> <tt>rep_ %= d.count()</tt>.
+Howard observed that <tt>FunctionType</tt>,
+a concept not (yet?) in the Working Paper,
+is likely the correct constraint to be applied.
+However, the proposed resolution provides an adequate approximation.
 </p>
 <p>
-<i>Returns:</i> <tt>*this</tt>.
+Move to Review.
 </p>
 </blockquote>
-</blockquote>
 
-<p>
-Add to 20.9.3.5 [time.duration.nonmember]:
-</p>
+<p><i>[
+2009-05-23 Alisdair adds:
+]</i></p>
 
-<blockquote>
 
-<pre>template &lt;class Rep1, class Period, class Rep2&gt;
-  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
-  operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
-</pre>
 <blockquote>
 <p>
-<i>Requires:</i> <tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt> and
-<tt>Rep2</tt> shall not be an instantiation of <tt>duration</tt>. Diagnostic required.
+By constraining to <tt>PointeeType</tt> we rule out the ability for <tt>T</tt> to be a
+reference, and call in reference-collapsing.  I'm not sure if this is
+correct and intended, but would like to be sure the case was considered.
 </p>
 <p>
-<i>Returns:</i> <tt>duration&lt;CR, Period&gt;(d) %= s</tt>.
+Is dis-allowing reference types and the
+implied reference collapsing the intended result?
 </p>
 </blockquote>
 
-<pre>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
-  operator%(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
-</pre>
+<p><i>[
+2009-07 Frankfurt
+]</i></p>
+
+
 <blockquote>
-<p>
-<i>Returns:</i> <tt>common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type(lhs) %= rhs</tt>.
-</p>
+Moved from Review to Open only because the wording needs to be
+tweaked for concepts removal.
 </blockquote>
 
-</blockquote>
+<p><i>[
+2009-10-14 Daniel provided de-conceptified wording.
+]</i></p>
+
 
+<p><i>[
+2009-10 post-Santa Cruz:
+]</i></p>
 
 
+<blockquote>
+Move to Tentatively Ready.
+</blockquote>
 
 
 
-<hr>
-<h3><a name="935"></a>935. clock error handling needs to be specified</h3>
-<p><b>Section:</b> 20.9.5 [time.clock] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-11-24  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Proposed resolution:</b></p>
 <p>
-Each of the three clocks specified in Clocks 20.9.5 [time.clock]
-provides the member function:
+Change 20.7.5 [refwrap]/1 as indicated:
 </p>
 
-<blockquote><pre>static time_point now();
-</pre></blockquote>
+<blockquote>
+<tt>reference_wrapper&lt;T&gt;</tt> is a <tt>CopyConstructible</tt> and
+<tt><ins>Copy</ins>Assignable</tt> wrapper around a
+reference to an object <ins>or function</ins> of type <tt>T</tt>.
+</blockquote>
+
+
 
+
+
+<p><b>Rationale:</b></p>
 <p>
-The semantics specified by Clock requirements 20.9.1 [time.clock.req]
-make no mention of error handling. Thus the function may throw <tt>bad_alloc</tt>
-or an implementation-defined exception (17.6.4.10 [res.on.exception.handling]
-paragraph 4).
+a) The occurrence of <tt>T&amp;</tt> in the function signature auto-implies
+<tt>std::ReferentType</tt>,
+this is due to  [temp.req.impl]/4 bullet 4
 </p>
-
 <p>
-Some implementations of these functions on POSIX, Windows, and
-presumably on other operating systems, may fail in ways only detectable
-at runtime. Some failures on Windows are due to supporting chipset
-errata and can even occur after successful calls to a clock's <tt>now()</tt>
-function.
+b) The occurrence of the constrained template <tt>reference_wrapper&lt;T&gt;</tt> in
+the remaining
+signatures lets kick in  [temp.req.impl]/4 bullet 1 and adds *all* requirements of
+this template. But we need to add at least *one* requirement (and it
+was an arbitrary,
+but natural decision to require <tt>std::PointeeType</tt> here) to *activate*
+this. If we hadn't done
+this, we were in unconstrained mode!
 </p>
 
+
+
+
+
+<hr>
+<h3><a name="996"></a>996. Move operation not well specified</h3>
+<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-06  <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-These functions are used in cases where exceptions are not appropriate
-or where the specifics of the exception or cause of error need to be
-available to the user. See
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html">N2828</a>,
-<i>Library Support for hybrid error
-handling (Rev 1)</i>, for more specific discussion of use cases. Thus some change in
-the interface of now is required.
+There are lots of places in the standard where we talk about "the move
+constructor" but where we mean "the move operation," i.e.  <tt>T( move( x ) )</tt>.
 </p>
-
 <p>
-The proposed resolution has been implemented in the Boost version of the
-chrono library. No problems were encountered.
+We also don't account for whether that operation modifies <tt>x</tt> or not, and
+we need to.
 </p>
 
 <p><i>[
@@ -18326,620 +15287,508 @@ Batavia (2009-05):
 ]</i></p>
 
 <blockquote>
-<p>
-We recommend this issue be deferred until the next Committee Draft
-has been issued and the prerequisite paper has been accepted.
-</p>
-<p>
-Move to Open.
-</p>
+Move to Open, pending proposed wording from Dave for further
+review.
 </blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Accept the proposed wording of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html">N2828</a>,
-<i>Library Support for hybrid error handling (Rev 1)</i>.
-</p>
-
-<p>
-Change Clock requirements 20.9.1 [time.clock.req] as indicated:
-</p>
-
-<blockquote>
-<p>
--2- In Table 55 <tt>C1</tt> and <tt>C2</tt> denote clock types. <tt>t1</tt> and
-<tt>t2</tt> are values returned by <tt>C1::now()</tt> where the call 
-returning <tt>t1</tt> happens before (1.10) the call returning <tt>t2</tt> and
-both of these calls happen before <tt>C1::time_point::max()</tt>.
-<ins><tt>ec</tt> denotes an object of type <tt>error_code</tt> 
-(19.5.2.2 [syserr.errcode.overview]).</ins>
 </p>
 
-<table border="1">
-<caption>Table 55 -- Clock requirements</caption>
-<tbody><tr>
-<th>Expression</th><th>Return type</th><th>Operational semantics</th>
-</tr>
 
-<tr>
-<td>...</td>
-<td>...</td>
-<td>...</td>
-</tr>
 
-<tr>
-<td><tt>C1::now()</tt></td>
-<td><tt>C1::time_point</tt></td>
-<td>Returns a <tt>time_point</tt> object representing the current point in time.
-</td>
-</tr>
 
-<tr>
-<td><tt><ins>C1::now(ec)</ins></tt></td>
-<td><tt><ins>C1::time_point</ins></tt></td>
-<td><ins>Returns a <tt>time_point</tt> object representing the current point in time.</ins>
-</td>
-</tr>
-</tbody></table>
-</blockquote>
 
+<hr>
+<h3><a name="999"></a>999. Taking the address of a function</h3>
+<p><b>Section:</b> 20.8.13 [specialized.algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-03-09  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#specialized.algorithms">issues</a> in [specialized.algorithms].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Change Class system_clock 20.9.5.1 [time.clock.system] as indicated:
+The same fix (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>) may be applied to <tt>addressof</tt>, which is also constrained to
+<tt>ObjectType</tt>. (That was why <tt>boost::ref</tt> didn't work with functions - it
+tried to apply <tt>boost::addressof</tt> and the <tt>reinterpret_cast&lt;char&amp;&gt;</tt>
+implementation of <tt>addressof</tt> failed.)
 </p>
 
-<blockquote><pre>static time_point now(<ins>error_code&amp; ec=throws()</ins>);
-</pre></blockquote>
 
-<p>
-Change Class monotonic_clock 20.9.5.2 [time.clock.monotonic] as indicated:
-</p>
 
-<blockquote><pre>static time_point now(<ins>error_code&amp; ec=throws()</ins>);
-</pre></blockquote>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
+<blockquote>
+<p>
+We agree.
+</p>
 <p>
-Change Class high_resolution_clock 20.9.5.3 [time.clock.hires] as indicated:
+Move to Tentatively Ready.
 </p>
+</blockquote>
 
-<blockquote><pre>static time_point now(<ins>error_code&amp; ec=throws()</ins>);
-</pre></blockquote>
+<p><i>[
+2009-07 Frankfurt
+]</i></p>
 
 
+<blockquote>
+Moved from Tentatively Ready to Open only because the wording needs to be
+tweaked for concepts removal.
+</blockquote>
 
+<p><i>[
+2009-10-10 Daniel updates wording to concept-free.
+]</i></p>
 
 
+<p><i>[
+2009-10 post-Santa Cruz:
+]</i></p>
+
+
+<blockquote>
+Move to Tentatively Ready.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p><i>[
+The resolution assumes that <tt>addressof</tt> is reintroduced as described in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2946.pdf">n2946</a>
+]</i></p>
 
-<hr>
-<h3><a name="936"></a>936. Mutex type overspecified</h3>
-<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-05  <b>Last modified:</b> 2009-03-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-30.4.1 [thread.mutex.requirements] describes the requirements for a type to be
-a "Mutex type". A Mutex type can be used as the template argument for
-the <tt>Lock</tt> type that's passed to <tt>condition_variable_any::wait</tt> (although
-<tt>Lock</tt> seems like the wrong name here, since <tt>Lock</tt> is given a different
-formal meaning in 30.4.3 [thread.lock]) and, although the WD doesn't quite say
-so, as the template argument for <tt>lock_guard</tt> and <tt>unique_lock</tt>.
-</p>
 
 <p>
-The requirements for a Mutex type include:
+In 20.8.13 [specialized.algorithms] change as described:
 </p>
 
-<ul>
-<li>
-<tt>m.lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>.
-</li>
-<li>
-<tt>m.try_lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>bool</tt>.
-</li>
-<li>
-<tt>m.unlock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>.
-</li>
-</ul>
+<blockquote><pre>template &lt;class T&gt; T* addressof(T&amp; r);
+</pre>
+<blockquote>
+<i>Returns:</i> The actual address of the object <ins>or function</ins>
+referenced by <tt>r</tt>, even in the
+presence of an overloaded <tt>operator&amp;</tt>.
+</blockquote>
+</blockquote>
 
+
+
+
+<p><b>Rationale:</b></p>
 <p>
-Also, a Mutex type "shall not be copyable nor movable".
+a) The occurrence of <tt>T&amp;</tt> in the function signature auto-implies
+<tt>std::ReferentType</tt>,
+this is due to  [temp.req.impl]/4 bullet 4
 </p>
 
+
+
+
+
+<hr>
+<h3><a name="1008"></a>1008. <tt>nested_exception</tt> wording unclear</h3>
+<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-10-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses JP 31</b></p>
+
 <p>
-The latter requirement seems completely irrelevant, and the three
-requirements on return types are tighter than they need to be. For
-example, there's no reason that <tt>lock_guard</tt> can't be instantiated with a
-type that's copyable. The rule is, in fact, that <tt>lock_guard</tt>, etc. won't
-try to copy objects of that type. That's a constraint on locks, not on
-mutexes. Similarly, the requirements for <tt>void</tt> return types are
-unnecessary; the rule is, in fact, that <tt>lock_guard</tt>, etc. won't use any
-returned value. And with the return type of <tt>bool</tt>, the requirement should
-be that the return type is convertible to <tt>bool</tt>.
+It is difficult to understand in which case <tt>nested_exception</tt> is applied.
 </p>
 
 <p><i>[
 Summit:
 ]</i></p>
 
-
+ 
 <blockquote>
-<p>
-Move to open. Related to conceptualization and should probably be tackled as part of that.
-</p>
-<ul>
-<li>
-The intention is not only to place a constraint on what types such as
-<tt>lock_guard</tt> may do with mutex types, but on what any code, including user
-code, may do with mutex types. Thus the constraints as they are apply to
-the mutex types themselves, not the current users of mutex types in the
-standard.
-</li>
-<li>
-This is a low priority issue; the wording as it is may be overly
-restrictive but this may not be a real issue.
-</li>
-</ul>
+Alisdair will add an example in an update to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2619.pdf">N2619</a>.
 </blockquote>
 
 <p><i>[
-Post Summit Anthony adds:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-<p>
-Section 30.4.1 [thread.mutex.requirements] conflates the
-requirements on a generic Mutex type (including user-supplied mutexes)
-with the requirements placed on the standard-supplied mutex types in an
-attempt to group everything together and save space.
-</p>
-<p>
-When applying concepts to chapter 30, I suggest that the concepts
-<tt>Lockable</tt> and <tt>TimedLockable</tt> embody the requirements for
-*use* of a mutex type as required by
-<tt>unique_lock/lock_guard/condition_variable_any</tt>. These should be
-relaxed as Pete describes in the issue. The existing words in 30.4.1 [thread.mutex.requirements] are requirements on all of
-<tt>std::mutex</tt>, <tt>std::timed_mutex</tt>,
-<tt>std::recursive_mutex</tt> and <tt>std::recursive_timed_mutex</tt>,
-and should be rephrased as such.
-</p>
+It doesn't appear that N2619 really addresses this. Alisdair to propose wording.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
-<p>
-</p>
 
 
 
 
 
 <hr>
-<h3><a name="939"></a>939. Problem with <tt>std::identity</tt> and reference-to-temporaries</h3>
-<p><b>Section:</b> 20.7.6 [identity.operation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-12-11  <b>Last modified:</b> 2009-07-30</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1011"></a>1011. <tt>next/prev</tt> wrong iterator type</h3>
+<p><b>Section:</b> 24.4.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-10-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.operations">active issues</a> in [iterator.operations].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 271</b></p>
+
 <p>
-<tt>std::identity</tt> takes an argument of type <tt>T const &amp;</tt>
-and returns a result of <tt>T const &amp;</tt>.
-</p>
-<p>
-Unfortunately, this signature will accept a value of type other than <tt>T</tt> that
-is convertible-to-<tt>T</tt>, and then return a reference to the dead temporary.  The
-constraint in the concepts version simply protects against returning
-reference-to-<tt>void</tt>.
-</p>
-<p>
-Solutions:
+<tt>next/prev</tt> return an incremented iterator without changing the value of
+the original iterator. However, even this may invalidate an
+<tt>InputIterator</tt>. A <tt>ForwardIterator</tt> is required to guarantee the
+'multipass' property.
 </p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
 <blockquote>
-<p>
-i/  Return-by-value, potentially slicing bases and rejecting non-copyable
-types
-</p>
-<p>
-ii/ Provide an additional overload:
-</p>
-<blockquote><pre>template&lt; typename T &gt;
-template operator( U &amp; ) = delete;
-</pre></blockquote>
-<p>
-This seems closer on intent, but moves beyond the original motivation for
-the operator, which is compatibility with existing (non-standard)
-implementations.
-</p>
-<p>
-iii/ Remove the <tt>operator()</tt> overload.  This restores the original definition
-of the <tt>identity</tt>, although now effectively a type_trait rather than part of
-the perfect forwarding protocol.
-</p>
-<p>
-iv/ Remove <tt>std::identity</tt> completely; its original reason to exist is
-replaced with the <tt>IdentityOf</tt> concept.
-</p>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
 </blockquote>
-<p>
-My own preference is somewhere between (ii) and (iii) - although I stumbled
-over the issue with a specific application hoping for resolution (i)!
-</p>
 
 <p><i>[
-Batavia (2009-05):
+2009-07 Frankfurt
 ]</i></p>
 
+
 <blockquote>
-<p>
-We dislike options i and iii, and option ii seems like overkill.
-If we remove it (option iv), implementers can still provide it under a
-different name.
-</p>
-<p>
-Move to Open pending wording (from Alisdair) for option iv.
-</p>
+Moved from Tentatively Ready to Open only because the wording needs to be
+tweaked for concepts removal.
 </blockquote>
 
 <p><i>[
-2009-05-23 Alisdair provided wording for option iv.
+2009-10-14 Daniel provided de-conceptified wording.
 ]</i></p>
 
 
 <p><i>[
-2009-07-20 Alisdair adds:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
+Moved to Ready.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+<ol>
+<li>
 <p>
-I'm not sure why this issue was not discussed at Frankfurt (or I missed
-the discussion) but the rationale is now fundamentally flawed.  With the
-removal of concepts, <tt>std::identity</tt> again becomes an important library
-type so we cannot simply remove it.
+Change header <tt>&lt;iterator&gt;</tt> synopsis 24.3 [iterator.synopsis] as indicated:
 </p>
+
+<blockquote><pre>// 24.4.4, iterator operations:
+...
+template &lt;class <del>Input</del><ins>Forward</ins>Iterator&gt;
+  <del>Input</del><ins>Forward</ins>Iterator
+  next(<del>Input</del><ins>Forward</ins>Iterator x, typename std::iterator_traits&lt;<del>Input</del><ins>Forward</ins>Iterator&gt;::difference_type n = 1);
+</pre></blockquote>
+</li>
+
+<li>
 <p>
-At that point, we need to pick one of the other suggested resolutions,
-but have no guidance at the moment.
+Change 24.4.4 [iterator.operations] before p.6 as indicated:
 </p>
-</blockquote>
 
-<p><i>[
-2009-07-20 Howard adds:
-]</i></p>
+<blockquote><pre>template &lt;class <del>Input</del><ins>Forward</ins>Iterator&gt;
+  <del>Input</del><ins>Forward</ins>Iterator
+  next(<del>Input</del><ins>Forward</ins>Iterator x, typename std::iterator_traits&lt;<del>Input</del><ins>Forward</ins>Iterator&gt;::difference_type n = 1);
+</pre></blockquote>
+</li>
+</ol>
 
 
-<blockquote>
+
+
+
+
+<hr>
+<h3><a name="1030"></a>1030. Response to JP 44</h3>
+<p><b>Section:</b> 20.8.15.5 [util.smartptr.shared.atomic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses JP 44</b></p>
+
 <p>
-I believe the rationale for not addressing this issue in Frankfurt was that it did
-not address a national body comment.
+The 1st parameter <tt>p</tt> and 2nd parameter <tt>v</tt> is now
+<tt>shared_ptr&lt;T&gt;*</tt>.
 </p>
 <p>
-I also believe that removal of <tt>identity</tt> is still a practical option as
-my latest reformulation of <tt>forward</tt>, which is due to comments suggested
-at Summit, no longer uses <tt>identity</tt>. :-)
+It should be <tt>shared_ptr&lt;T&gt;&amp;</tt>, or if these are
+<tt>shared_ptr&lt;T&gt;*</tt> then add the "<tt>p</tt> shall not be a
+null pointer" at the requires.
 </p>
 
-<blockquote><pre>template &lt;class T, class U,
-    class = typename enable_if
-            &lt;
-                !is_lvalue_reference&lt;T&gt;::value || 
-                 is_lvalue_reference&lt;T&gt;::value &amp;&amp;
-                 is_lvalue_reference&lt;U&gt;::value
-            &gt;::type,
-    class = typename enable_if
-            &lt;
-                is_same&lt;typename remove_all&lt;T&gt;::type,
-                        typename remove_all&lt;U&gt;::type&gt;::value
-            &gt;::type&gt;
-inline
-T&amp;&amp;
-forward(U&amp;&amp; t)
-{
-    return static_cast&lt;T&amp;&amp;&gt;(t);
-
-}
-</pre>
-
 <p><i>[
-The above code assumes acceptance of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1120">1120</a> for the definition of
-<tt>remove_all</tt>.  This is just to make the syntax a little more palatable.
-Without this trait the above is still very implementable.
+Summit:
 ]</i></p>
 
 
+<blockquote>
+Agree. All of the functions need a requirement that <tt>p</tt> (or
+<tt>v</tt>) is a pointer to a valid object.
 </blockquote>
 
+<p><i>[
+2009-07 post-Frankfurt:
+]</i></p>
+
+
+<blockquote>
 <p>
-Paper with rationale is on the way ... <i>really</i>, I promise this time! ;-)
+Lawrence explained that these signatures match the regular atomics. The
+regular atomics must not use references because these signatures are
+shared with C. The decision to pass shared_ptrs by pointer rather than
+by reference was deliberate and was motivated by the principle of least
+surprise.
+</p>
+<p>
+Lawrence to write wording that requires that the pointers not be null.
 </p>
 </blockquote>
 
 <p><i>[
-2009-07-30 Daniel adds:  See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a> for an alternative resolution.
+2009-09-20 Lawrence provided wording:
 ]</i></p>
 
 
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
+<p>
+The parameter types for atomic shared pointer access
+were deliberately chosen to be pointers
+to match the corresponding parameters of the atomics chapter.
+Those in turn were deliberately chosen
+to match C functions,
+which do not have reference parameters.
+</p>
 <p>
-Strike 20.2.1 [concept.transform] p3:
+We adopt the second suggestion,
+to require that such pointers not be null.
 </p>
+</blockquote>
+
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
 
 <blockquote>
-<del>-4- <i>Note:</i> concept form of the identity type metafunction (20.7.6).</del>
+Moved to Ready.
 </blockquote>
 
-<p>
-Strike from 20.7 [function.objects] p2:
-</p>
 
-<blockquote><pre><del>// 20.7.6, identity operation:</del>
-<del>template &lt;IdentityOf T&gt; struct identity;</del>
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-Remove 20.7.6 [identity.operation] (whole subclause):
+In section "<code>shared_ptr</code> atomic access"
+20.8.15.5 [util.smartptr.shared.atomic], add to each function the
+following clause.
 </p>
-
-<blockquote>
-<pre><del>template &lt;IdentityOf T&gt; struct identity {
-  typedef T type;
-
-  requires ReferentType&lt;T&gt;
-     const T&amp; operator()(const T&amp; x) const;
-};</del>
-
-<del>requires ReferentType&lt;T&gt;
-  const T&amp; operator()(const T&amp; x) const;</del>
-</pre>
-<blockquote>
-<del>-1-  <i>Returns:</i> <tt>x</tt></del>
-</blockquote>
-</blockquote>
-
+<blockquote><p>
+<i>Requires:</i> <code>p</code> shall not be null.
+</p></blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="940"></a>940. <tt>std::distance</tt></h3>
-<p><b>Section:</b> 24.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Thomas <b>Opened:</b> 2008-12-14  <b>Last modified:</b> 2009-07-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.operations">active issues</a> in [iterator.operations].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p>
+<h3><a name="1033"></a>1033. <tt>thread::join()</tt> effects?</h3>
+<p><b>Section:</b> 30.3.1.5 [thread.thread.member] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.member">active issues</a> in [thread.thread.member].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.member">issues</a> in [thread.thread.member].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 
-<p><b>Addresses UK 270</b></p>
-
-<p>
-Regarding the <tt>std::distance</tt> - function, 24.4 [iterator.operations]
-/ 4 says:
-</p>
-<blockquote>
-Returns the
-number of increments or decrements needed to get from first to last.
-</blockquote>
-<p>
-This sentence is completely silent about the sign of the return value.
-24.4 [iterator.operations] / 1 gives more information about the
-underlying operations, but
-again no inferences about the sign can be made.
-Strictly speaking, that is taking that sentence literally, I think this
-sentence even implies a positive return value in all cases, as the
-number of increments or decrements is clearly a ratio scale variable,
-with a natural zero bound.
-</p>
-<p>
-Practically speaking, my implementations did what common sense and
-knowledge based on pointer arithmetic forecasts, namely a positive sign
-for increments (that is, going from <tt>first</tt> to <tt>last</tt> by <tt>operator++</tt>), and a
-negative sign for decrements (going from <tt>first</tt> to <tt>last</tt> by <tt>operator--</tt>).
-</p>
-<p>
-Here are my two questions:
-</p>
 <p>
-First, is that paragraph supposed to be interpreted in the way what I
-called 'common sense', that is negative sign for decrements ? I am
-fairly sure that's the supposed behavior, but a double-check here in
-this group can't hurt.
+While looking at <tt>thread::join()</tt> I think I spotted a couple of
+possible defects in the specifications. I could not find a previous
+issue or NB comment about that, but I might have missed it.
 </p>
+
 <p>
-Second, is the present wording (2003 standard version - no idea about
-the draft for the upcoming standard) worth an edit to make it a bit more
-sensible, to mention the sign of the return value explicitly ?
+The postconditions clause for <tt>thread::join()</tt> is:
 </p>
 
-<p><i>[
-Daniel adds:
-]</i></p>
-
-
 <blockquote>
-<p>
-My first thought was that resolution <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#204">204</a> would already cover the
-issue report, but it seems that current normative wording is in
-contradiction to that resolution:
-</p>
+<i>Postconditions:</i> If <tt>join()</tt> throws an exception, the value
+returned by <tt>get_id()</tt> is unchanged. Otherwise, <tt>get_id() == id()</tt>.
+</blockquote>
 
 <p>
-Referring to
-<a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>,
-24.4 [iterator.operations]/ p.4 says:
+and the throws clause is:
 </p>
 
 <blockquote>
-<i>Effects:</i> Returns the number of increments or decrements needed to get
-from <tt>first</tt> to <tt>last</tt>.
+<i>Throws:</i> <tt>std::system_error</tt> when the postconditions cannot be achieved.
 </blockquote>
 
 <p>
-IMO the part " or decrements" is in contradiction to p. 5 which says
+Now... how could the postconditions <em>not</em> be achieved?
+It's just a matter of resetting the value of <tt>get_id()</tt> or leave it
+unchanged! I bet we can always do that. Moreover, it's a chicken-and-egg
+problem: in order to decide whether to throw or not I depend on the
+postconditions, but the postconditions are different in the two cases.
 </p>
 
-<blockquote>
-<i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>.
-</blockquote>
-
 <p>
-because "reachable" is defined in 24.2 [iterator.concepts]/7 as
+I believe the throws clause should be:
 </p>
 
 <blockquote>
-An iterator <tt>j</tt> is called reachable from an iterator <tt>i</tt> if and only if
-there is a finite
-sequence of applications of the expression <tt>++i</tt> that makes <tt>i == j</tt>.[..]
+<i>Throws:</i> <tt>std::system_error</tt> when the effects or postconditions
+cannot be achieved.
 </blockquote>
 
 <p>
-Here is wording that would be consistent with this definition of "reachable":
+as it is in <tt>detach()</tt>, or, even better, as the postcondition is
+trivially satisfiable and to remove the circular dependency:
 </p>
 
-<p>
-Change 24.4 [iterator.operations] p4 as follows:
-</p>
 
 <blockquote>
-<i>Effects:</i> Returns the number of increments <del>or decrements</del>
-needed to get from <tt>first</tt> to <tt>last</tt>.
-</blockquote>
-
+<i>Throws:</i> <tt>std::system_error</tt> if the effects cannot be achieved.
 </blockquote>
 
 <p>
-Thomas adds more discussion and an alternative view point
-<a href="http://groups.google.com/group/comp.std.c++/browse_thread/thread/e8e46dcda0a5d797#">here</a>.
+Problem is that... ehm... <tt>join()</tt> has no "Effects" clause. Is that intentional?
 </p>
 
 <p><i>[
-Summit:
+See the thread starting at c++std-lib-23204 for more discussion.
 ]</i></p>
 
 
-<blockquote>
-The proposed wording below was verbally agreed to.  Howard provided.
-</blockquote>
-
 <p><i>[
 Batavia (2009-05):
 ]</i></p>
 
 <blockquote>
 <p>
-Pete reports that a recent similar change has been made
-for the <tt>advance()</tt> function.
+Pete believes there may be some more general language (in frontmatter)
+that can address this and related issues such as <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>.
 </p>
 <p>
-We agree with the proposed resolution.
-Move to Tentatively Ready.
+Move to Open.
 </p>
 </blockquote>
 
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
 
+<p><b>Proposed resolution:</b></p>
 
-<blockquote>
-Moved from Tentatively Ready to Open only because the wording needs to be
-tweaked for concepts removal.
-</blockquote>
 
-<p><i>[
-2009-07 Frankfurt:
-]</i></p>
 
 
-<blockquote>
-Leave Open pending arrival of a post-Concepts WD.
-</blockquote>
 
+<hr>
+<h3><a name="1034"></a>1034. Response to UK 222</h3>
+<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 
+<p><b>Addresses UK 222</b></p>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 24.4 [iterator.operations]:
+It is not clear what purpose the Requirement tables serve in the
+Containers clause. Are they the definition of a library Container? Or
+simply a conventient shorthand to factor common semantics into a single
+place, simplifying the description of each subsequent container? This
+becomes an issue for 'containers' like <tt>array</tt>, which does not meet the
+default-construct-to-empty requirement, or <tt>forward_list</tt> which does not
+support the size operation. Are these components no longer containers?
+Does that mean the remaining requirements don't apply? Or are these
+contradictions that need fixing, despite being a clear design decision?
 </p>
 
-<blockquote>
-<pre>template &lt;InputIterator Iter&gt;
-  Iter::difference_type
-  distance(Iter first, Iter last);
-<del>template &lt;RandomAccessIterator Iter&gt;
-  Iter::difference_type distance(Iter first, Iter last);</del>
-</pre>
-
-<blockquote>
 <p>
--4- <i>Effects:</i> Returns the number of increments <del>or decrements</del>
-needed to get from <tt>first</tt> to <tt>last</tt>.
+Recommend:
 </p>
+
 <p>
--5- <i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>.
+Clarify all the tables in 23.2 [container.requirements] are
+there as a convenience for documentation, rather than a strict set of
+requirements. Containers should be allowed to relax specific
+requirements if they call attention to them in their documentation. The
+introductory text for <tt>array</tt> should be expanded to mention a
+default constructed <tt>array</tt> is not empty, and
+<tt>forward_list</tt> introduction should mention it does not provide
+the required <tt>size</tt> operation as it cannot be implemented
+efficiently.
 </p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agree in principle.
 </blockquote>
 
-<pre><ins>template &lt;RandomAccessIterator Iter&gt;
-  Iter::difference_type distance(Iter first, Iter last);</ins>
-</pre>
+<p><i>[
+2009-07 post-Frankfurt:
+]</i></p>
+
 
 <blockquote>
-<p>
-<ins>-6- <i>Effects:</i> Returns the number of increments or decrements
-needed to get from <tt>first</tt> to <tt>last</tt>.</ins>
-</p>
-<p>
-<ins>-7- <i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>
-or <tt>first</tt> shall be reachable from <tt>last</tt>.</ins>
-</p>
+We agree in principle, but we have a timetable. This group feels that
+the issue should be closed as NAD unless a proposed resolution is
+submitted prior to the March 2010 meeting.
 </blockquote>
 
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
 
+<blockquote>
+Looked at this and still intend to close as NAD in March
+2010 unless there is proposed wording that we like.
 </blockquote>
 
 
 
+<p><b>Proposed resolution:</b></p>
+
+
 
 
 
 <hr>
-<h3><a name="944"></a>944. <tt>atomic&lt;bool&gt;</tt> derive from <tt>atomic_bool</tt>?</h3>
-<p><b>Section:</b> 29.5.3 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19  <b>Last modified:</b> 2009-03-22</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1052"></a>1052. Response to UK 281</h3>
+<p><b>Section:</b> 24.5.1.3.5 [reverse.iter.opref] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-10-22</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>
-I think it's fairly obvious that <tt>atomic&lt;bool&gt;</tt> is supposed to be derived
-from <tt>atomic_bool</tt> (and otherwise follow the <tt>atomic&lt;integral&gt;</tt> interface),
-though I think the current wording doesn't support this. I raised this
-point along with <tt>atomic&lt;floating-point&gt;</tt> privately with Herb and I seem
-to recall it came up in the resulting discussion on this list. However,
-I don't see anything on the current libs issue list mentioning this
-problem.
-</p>
-
-<p>
-29.5.3 [atomics.types.generic]/3 reads
-</p>
 
-<blockquote>
-There are full specializations over the integral types on the atomic
-class template. For each integral type integral in the second column of
-table 121 or table 122, the specialization <tt>atomic&lt;integral&gt;</tt> shall be
-publicly derived from the corresponding atomic integral type in the
-first column of the table. These specializations shall have trivial
-default constructors and trivial destructors.
-</blockquote>
+<p><b>Addresses UK 281</b></p>
 
 <p>
-Table 121 does not include (<tt>atomic_bool</tt>, <tt>bool</tt>),
-so that this should probably be mentioned explicitly in the quoted paragraph.
+The current specification for return value for <tt>reverse_iterator::operator-&gt;</tt>
+will always be a true pointer type, but <tt>reverse_iterator</tt> supports proxy
+iterators where the pointer type may be some kind of 'smart pointer'.
 </p>
 
 <p><i>[
@@ -18948,308 +15797,323 @@ Summit:
 
 
 <blockquote>
-Move to open. Lawrence will draft a proposed resolution. Also, ask
-Howard to fix the title.
-</blockquote>
-
-<p><i>[
-Post Summit Anthony provided proposed wording.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Replace paragraph 3 in 29.5.3 [atomics.types.generic] with
+<tt>move_iterator</tt> avoids this problem by returning a value of the wrapped
+Iterator type.
+study group formed to come up with a suggested resolution.
 </p>
-
-<blockquote>
--3- There are full specializations over the integral types on the <tt>atomic</tt>
-class template. For each integral type <tt>integral</tt> in the second column of
-table 121 or table 122, the specialization <tt>atomic&lt;integral&gt;</tt> shall be
-publicly derived from the corresponding atomic integral type in the first
-column of the table.
-<ins>In addition, the specialization <tt>atomic&lt;bool&gt;</tt>
-shall be publicly derived from <tt>atomic_bool</tt>.</ins>
-These specializations shall have trivial default
-constructors and trivial destructors.
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="947"></a>947. duration arithmetic: contradictory requirements</h3>
-<p><b>Section:</b> 20.9.3.5 [time.duration.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-20  <b>Last modified:</b> 2009-07-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.nonmember">issues</a> in [time.duration.nonmember].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-In 20.9.3.5 [time.duration.nonmember], paragraph 8 says that calling
-<tt>dur / rep</tt>
-when <tt>rep</tt> is an instantiation of <tt>duration</tt> requires a diagnostic.
-That's followed by an <tt>operator/</tt> that takes two durations.
-So <tt>dur1 / dur2</tt> is legal under the second version,
-but requires a diagnostic under the first.
+<tt>move_iterator</tt> solution shown in proposed wording.
 </p>
+</blockquote>
 
 <p><i>[
-Howard adds:
+2009-07 post-Frankfurt:
 ]</i></p>
 
 
 <blockquote>
-Please see the thread starting with c++std-lib-22980 for more information.
+Howard to deconceptize. Move to Review after that happens.
 </blockquote>
 
 <p><i>[
-Batavia (2009-05):
+2009-08-01 Howard deconceptized:
 ]</i></p>
 
+
 <blockquote>
-Move to Open, pending proposed wording (and preferably an implementation).
 </blockquote>
 
 <p><i>[
-2009-07-27 Howard adds:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
 <p>
-I've addressed this issue under the proposed wording for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a> which
-cleans up several places under 20.9.3 [time.duration] which used the
-phrase "diagnostic required".
+We can't think of any reason we can't just define reverse
+iterator's pointer types to be the same as the underlying iterator's
+pointer type, and get it by calling the right arrow directly.
 </p>
 <p>
-For clarity's sake, here is an example implementation of the constrained <tt>operator/</tt>:
+Here is the proposed wording that was replaced:
 </p>
+<blockquote><pre>template &lt;class Iterator&gt; 
+class reverse_iterator { 
+  ...
+  typedef <del>typename iterator_traits&lt;</del>Iterator<del>&gt;::pointer</del> pointer;
+</pre></blockquote>
 
-<blockquote><pre>template &lt;class _Duration, class _Rep, bool = __is_duration&lt;_Rep&gt;::value&gt;
-struct __duration_divide_result
-{
-};
-
-template &lt;class _Duration, class _Rep2,
-    bool = is_convertible&lt;_Rep2,
-                          typename common_type&lt;typename _Duration::rep, _Rep2&gt;::type&gt;::value&gt;
-struct __duration_divide_imp
-{
-};
-
-template &lt;class _Rep1, class _Period, class _Rep2&gt;
-struct __duration_divide_imp&lt;duration&lt;_Rep1, _Period&gt;, _Rep2, true&gt;
-{
-    typedef duration&lt;typename common_type&lt;_Rep1, _Rep2&gt;::type, _Period&gt; type;
-};
+<p>
+Change 24.5.1.3.5 [reverse.iter.opref]:
+</p>
 
-template &lt;class _Rep1, class _Period, class _Rep2&gt;
-struct __duration_divide_result&lt;duration&lt;_Rep1, _Period&gt;, _Rep2, false&gt;
-    : __duration_divide_imp&lt;duration&lt;_Rep1, _Period&gt;, _Rep2&gt;
-{
-};
-
-template &lt;class _Rep1, class _Period, class _Rep2&gt;
-inline
-typename __duration_divide_result&lt;duration&lt;_Rep1, _Period&gt;, _Rep2&gt;::type
-operator/(const duration&lt;_Rep1, _Period&gt;&amp; __d, const _Rep2&amp; __s)
-{
-    typedef typename common_type&lt;_Rep1, _Rep2&gt;::type _Cr;
-    duration&lt;_Cr, _Period&gt; __r = __d;
-    __r /= static_cast&lt;_Cr&gt;(__s);
-    return __r;
-}
+<blockquote><pre>pointer operator-&gt;() const;
+</pre>
+<blockquote>
+<i>Returns:</i>
+<blockquote><pre><del>&amp;(operator*());</del>
+<ins>this-&gt;tmp = current;</ins>
+<ins>--this-&gt;tmp;</ins>
+<ins>return this-&gt;tmp;</ins>
 </pre></blockquote>
+</blockquote>
+</blockquote>
+</blockquote>
+
 
-<p>
-<tt>__duration_divide_result</tt> is basically a custom-built <tt>enable_if</tt>
-that will contain <tt>type</tt> only if <tt>Rep2</tt> is not a <tt>duration</tt>
-and if <tt>Rep2</tt> is implicitly convertible to
-<tt>common_type&lt;typename Duration::rep, Rep2&gt;::type</tt>. <tt>__is_duration</tt>
-is simply a private trait that answers <tt>false</tt>, but is specialized for
-<tt>duration</tt> to answer <tt>true</tt>.
-</p>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-The constrained <tt>operator%</tt> works identically.
+Change 24.5.1.3.5 [reverse.iter.opref]:
 </p>
+
+<blockquote><pre>pointer operator-&gt;() const;
+</pre>
+<blockquote>
+<i>Returns:</i>
+<blockquote><pre><del>&amp;(operator*());</del>
+<ins>deref_tmp = current;
+--deref_tmp;
+return deref_tmp::operator-&gt;();</ins>
+</pre></blockquote>
+</blockquote>
 </blockquote>
 
 
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
+
+
 
 
 
 
 
 <hr>
-<h3><a name="950"></a>950. unique_ptr converting ctor shouldn't accept array form</h3>
-<p><b>Section:</b> 20.8.9.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-08-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.ctor">active issues</a> in [unique.ptr.single.ctor].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="1056"></a>1056. Must all Engines and Distributions be Streamable?</h3>
+<p><b>Section:</b> 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-11-03</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
 <p><b>Discussion:</b></p>
+
 <p>
-<tt>unique_ptr</tt>'s of array type should not convert to
-<tt>unique_ptr</tt>'s which do not have an array type.
+Both the concepts <tt>RandomNumberEngine</tt> and <tt>RandomNumberDistribution</tt> have
+requirements to be <tt>InputStreamable</tt> and <tt>OutputStreamable</tt>.
+</p>
+<p>
+I have no problems leaving the WP in an inconsistent state on the best-faith
+assumption these concepts will be provided later, however disagree with the
+proposers that these constraints are not separable, orthogonal to the basic
+concepts of generating random number distributions.
+</p>
+<p>
+These constraints should be dropped, and applied to specific algorithms as
+needed.
+</p>
+<p>
+If a more refined concept (certainly deemed useful by the proposers) is
+proposed there is no objection, but the basic concept should not require
+persistence via streaming.
 </p>
 
-<blockquote><pre>struct Deleter
-{
-   void operator()(void*) {}
-};
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
-int main()
-{
-   unique_ptr&lt;int[], Deleter&gt; s;
-   unique_ptr&lt;int, Deleter&gt; s2(std::move(s));  <font color="#c80000">// should not compile</font>
-}
-</pre></blockquote>
+<blockquote>
+Move to Open.
+</blockquote>
 
 <p><i>[
-Post Summit:
+2009-05-31 Alisdair adds:
 ]</i></p>
 
 
 <blockquote>
 <p>
-Walter: Does the "diagnostic required" apply to both arms of the "and"?
-</p>
-<p>
-Tom Plum: suggest to break into several sentences
+Working on constraining the stream iterators, I have a few more observations
+to make on the concepts proposed while constraining the random number
+facility.
 </p>
 <p>
-Walter: suggest "comma" before the "and" in both places
+While I still believe the concerns are orthogonal, I don't believe the
+existing constraints go far enough either!  The goal we want to achieve is
+not that a <tt>RandomNumberEngine</tt> / <tt>RandomNumberDistribution</tt> supports the stream
+operators, but that it is <tt>Serializable</tt>.  I.e. there is a relationship
+between the insert and extract operations that guarantees to restore the
+state of the original object.  This implies a coupling of the concepts
+together in a broader concept (<tt>Serializable</tt>) with at least one axiom to
+assert the semantics.
 </p>
 <p>
-Recommend Review.
+One problem is that <tt>istream</tt> and <tt>ostream</tt> may be fundamentally different
+types, although we can hook a relation if we are prepared to drop down to
+the <tt>char</tt> type and <tt>char_traits</tt> template parameters.  Doing so ties us to a
+form of serialization that demands implementation via the std iostreams
+framework, which seems overly prescriptive.  I believe the goal is generally
+to support serialization without regard to how it is expressed - although
+this is getting even more inventive in terms of concepts we do not have
+today.
 </p>
 </blockquote>
 
 <p><i>[
-Batavia (2009-05):
+2009-11-03 Alisdair adds:
 ]</i></p>
 
+
 <blockquote>
-The post-Summit comments have been applied to the proposed resolution.
-We now agree with the proposed resolution.
-Move to Tentatively Ready.
+<p>
+I can't find the record in the wiki minutes, but it was agreed at both
+Frankfurt and Santa Cruz that this issue is NAD.
+</p>
+<p>
+The agreement in SC was that I would provide you with the rationale (see
+below) to include when moving to NAD.
+</p>
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt
+2009-11-03 Howard adds:
 ]</i></p>
 
 
 <blockquote>
-Moved from Tentatively Ready to Open only because the wording needs to be
-improved for enable_if type constraining, possibly following Robert's
-formula.
+Moved to Tentatively NAD after 5 positive votes on c++std-lib.
 </blockquote>
 
-<p><i>[
-2009-08-01 Howard updates wording and sets to Review.
-]</i></p>
-
 
+<p><b>Proposed resolution:</b></p>
 
 
-<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
 <p>
-Change 20.8.9.2.1 [unique.ptr.single.ctor]:
+The issue suggests a more refined concept should be used if we want to
+require streaming, to separate concerns from the basic
+<tt>RandomNumberEngine</tt> behaviour.  In Frankfurt it was observed
+that <tt>RandomNumberEngine</tt> <em>is</em> that more refined concept,
+and the basic concept used in the framework is
+<tt>UniformRandomNumberGenerator</tt>, which it refines.
 </p>
 
-<blockquote>
-<pre>template &lt;class U, class E&gt; unique_ptr(unique_ptr&lt;U, E&gt;&amp;&amp; u);
-</pre>
-<blockquote>
 <p>
--20- <i>Requires:</i> If <tt>D</tt> is not a reference type,
-construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
-shall be well formed and shall not throw an exception. <del>If <tt>D</tt> is
-a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>
-(diagnostic required). <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be
-implicitly convertible to <tt>pointer</tt>. [<i>Note:</i> These requirements
-imply that <tt>T</tt> and <tt>U</tt> are complete types. &#8212; <i>end note</i>]</del>
+We concur, and expect this to have no repurcussions re-writing this
+clause now concepts are removed.
 </p>
 
-<p><ins>
-<i>Remarks:</i> If <tt>D</tt> is
-a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>, else this
-constructor shall not participate in overload resolution. <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be
-implicitly convertible to <tt>pointer</tt>, else this
-constructor shall not participate in overload resolution. <tt>U</tt> shall not be
-an array type, else this
-constructor shall not participate in overload resolution. [<i>Note:</i> These requirements
-imply that <tt>T</tt> and <tt>U</tt> are complete types. &#8212; <i>end note</i>]
-</ins></p>
 
-</blockquote>
-</blockquote>
+
+
+
+<hr>
+<h3><a name="1068"></a>1068. class random_device should be movable</h3>
+<p><b>Section:</b> 26.5.6 [rand.device] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-18  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.device">issues</a> in [rand.device].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 
 <p>
-Change 20.8.9.2.3 [unique.ptr.single.asgn]:
+class <tt>random_device</tt> should be movable.
 </p>
 
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
 <blockquote>
-<pre>template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u);
-</pre>
+Move to Open, and recommend this issue be deferred until after the next
+Committee Draft is issued.
+</blockquote>
+
+<p><i>[
+2009-10 post-Santa Cruz:
+]</i></p>
+
+
 <blockquote>
+Leave open. Walter to provide drafting as part of his planned paper.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1069"></a>1069. class seed_seq should support efficient move operations</h3>
+<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-18  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
 <p>
--6- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
-<tt>D</tt> shall not throw an exception. <del><tt>unique_ptr&lt;U,
-E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>.
-[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
-are complete types. &#8212; <i>end note</i>]</del>
+class <tt>seed_seq</tt> should support efficient move operations.
 </p>
 
-<p><ins>
-<i>Remarks:</i> <tt>unique_ptr&lt;U,
-E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>, else this
-operator shall not participate in overload resolution.
-<tt>U</tt> shall not be an array type, else this
-operator shall not participate in overload resolution.
-[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
-are complete types. &#8212; <i>end note</i>]
-</ins></p>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
+<blockquote>
+Move to Open, and recommend this issue be deferred until after the next
+Committee Draft is issued.
 </blockquote>
+
+<p><i>[
+2009-10 post-Santa Cruz:
+]</i></p>
+
+
+<blockquote>
+Leave open. Walter to provide drafting as part of his planned paper.
 </blockquote>
 
 
 
+<p><b>Proposed resolution:</b></p>
+
+
 
 
 
 <hr>
-<h3><a name="951"></a>951. Various threading bugs #1</h3>
-<p><b>Section:</b> 20.9.2.1 [time.traits.is_fp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-08-01</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1071"></a>1071. is_bind_expression should derive from integral_constant&lt;bool&gt;</h3>
+<p><b>Section:</b> 20.7.11.1.1 [func.bind.isbind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 
 <p>
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>.
+Class template is_bind_expression 20.7.11.1.1 [func.bind.isbind]:
 </p>
 
+<blockquote><pre>namespace std {
+  template&lt;class T&gt; struct is_bind_expression {
+    static const bool value = see below;
+  };
+}
+</pre></blockquote>
 <p>
-20.9.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?
+<tt>is_bind_expression</tt> should derive from <tt>std::integral_constant&lt;bool&gt;</tt> like
+other similar trait types.
 </p>
+
 <p><i>[
-2009-05-10 Howard adds:
+Daniel adds:
 ]</i></p>
 
-
 <blockquote>
-<tt>IntegralLike</tt>.
+We need the same thing for the trait <tt>is_placeholder</tt> as well.
 </blockquote>
+<p><i>[
+2009-03-22 Daniel provided wording.
+]</i></p>
+
 
 <p><i>[
 Batavia (2009-05):
@@ -19257,11 +16121,7 @@ Batavia (2009-05):
 
 <blockquote>
 <p>
-As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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.
+We recommend this be deferred until after the next Committee Draft is issued.
 </p>
 <p>
 Move to Open.
@@ -19269,1468 +16129,1182 @@ Move to Open.
 </blockquote>
 
 <p><i>[
-2009-08-01 Howard adds:
+2009-05-31 Peter adds:
 ]</i></p>
 
 
 <blockquote>
 <p>
-I have surveyed all clauses of 20.9.2.2 [time.traits.duration_values],
-20.9.2.3 [time.traits.specializations] and 20.9.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.
+I am opposed to the proposed resolution and to the premise of the issue
+in general. The traits's default definitions should NOT derive from
+<tt>integral_constant</tt>, because this is harmful, as it misleads people into
+thinking that <tt>is_bind_expression&lt;E&gt;</tt> always derives from
+<tt>integral_constant</tt>, whereas it may not.
 </p>
-
 <p>
-Indeed, <tt>treat_as_floating_point</tt>
-becomes completely superfluous if <tt>duration::rep</tt> can never be a class type.
+<tt>is_bind_expression</tt> and <tt>is_placeholder</tt> allow user
+specializations, and in fact, this is their primary purpose. Such user
+specializations may not derive from <tt>integral_constant</tt>, and the
+places where <tt>is_bind_expression</tt> and <tt>is_placeholder</tt> are
+used intentionally do not require such derivation.
 </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.
+The long-term approach here is to switch to
+<tt>BindExpression&lt;E&gt;</tt> and <tt>Placeholder&lt;P&gt;</tt>
+explicit concepts, of course, but until that happens, I say leave them
+alone.
 </p>
+</blockquote>
 
-<p>
-In 20.9.2.1 [time.traits.is_fp] p1:
-</p>
+<p><i>[
+2009-10 post-Santa Cruz:
+]</i></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>
+Move to Tentatively Ready.  We are comfortable with requiring user specializations
+to derive from <tt>integral_constant</tt>.
 </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><b>Proposed resolution:</b></p>
+<ol>
+<li>
 <p>
-I am amenable to improved wording of this paragraph (and any others), but to 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.9 [time] without firmly grounded and
-documented rationale, example implementation, testing, and user
-experience which relates a positive experience.
+In 20.7.11.1.1 [func.bind.isbind] change as indicated:
 </p>
-
+<blockquote><pre>namespace std {
+ template&lt;class T&gt; struct is_bind_expression <ins>: integral_constant&lt;bool, <i>see below</i>&gt; { };</ins><del>{
+   static const bool value = <i>see below</i>;
+ };</del>
+}
+</pre></blockquote>
+</li>
+<li>
 <p>
-I recommend NAD unless someone wants to produce some clarifying wording.
+In 20.7.11.1.1 [func.bind.isbind]/2 change as indicated:
 </p>
+<blockquote><pre><del>static const bool value;</del>
+</pre>
+<blockquote>
+-2- <del><tt>true</tt> if <tt>T</tt> is a type returned from <tt>bind</tt>, <tt>false</tt> otherwise.</del>
+  <ins>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 it shall be
+publicly derived from
+          <tt>integral_constant&lt;bool, false&gt;</tt>.</ins>
 </blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
+</blockquote>
+</li>
+<li>
+<p>
+In 20.7.11.1.2 [func.bind.isplace] change as indicated:
+</p>
+<blockquote><pre>namespace std {
+ template&lt;class T&gt; struct is_placeholder <ins>: integral_constant&lt;int, <i>see below</i>&gt; { };</ins><del>{
+   static const int value = <i>see below</i>;
+ };</del>
+}
+</pre></blockquote>
+</li>
+<li>
 <p>
+In 20.7.11.1.2 [func.bind.isplace]/2 change as indicated:
 </p>
+<blockquote><pre><del>static const int value;</del>
+</pre>
+<blockquote>
+-2- <del>value is <tt>J</tt> if <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, 0 otherwise.</del>
+  <ins>If <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, <tt>is_placeholder&lt;T&gt;</tt>
+shall be publicly
+          derived from <tt>integral_constant&lt;int, J&gt;</tt> otherwise it shall
+be publicly derived
+          from <tt>integral_constant&lt;int, 0&gt;</tt>.</ins>
+</blockquote>
+</blockquote>
+</li>
+</ol>
 
 
 
 
 
 <hr>
-<h3><a name="953"></a>953. Various threading bugs #3</h3>
-<p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-08-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
+<h3><a name="1076"></a>1076. unary/binary_negate need constraining and move support</h3>
+<p><b>Section:</b> 20.7.10 [negators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-20  <b>Last modified:</b> 2009-10-26</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
-
 <p>
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>.
+The class templates <tt>unary/binary_negate</tt> need constraining and move support.
 </p>
-
 <p>
-20.9.1 [time.clock.req] says that a clock's <tt>rep</tt> member is "an
-arithmetic type or a class emulating an arithmetic type." What are the
-requirements for such a type?
+Ideally these classes would be deprecated, allowing <tt>unary/binary_function</tt> to
+also be deprecated.  However, until a generic negate adaptor is introduced
+that can negate any <tt>Callable</tt> type, they must be supported so should be
+constrained.  Likewise, they should be movable, and support adopting a
+move-only predicate type.
+</p>
+<p>
+In order to preserve ABI compatibility, new rvalue overloads are supplied in
+preference to changing the existing pass-by-const-ref to pass-by-value.
+</p>
+<p>
+Do not consider the issue of forwarding mutable lvalues at this point,
+although remain open to another issue on the topic.
 </p>
 
 <p><i>[
-2009-05-10 Howard adds:
+2009-05-01 Daniel adds:
 ]</i></p>
 
-
 <blockquote>
-This wording was aimed directly at the <tt>ArithmeticLike</tt> concept.
-</blockquote>
-
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<p>
+IMO the currently proposed resolution needs some updates
+because it is ill-formed at several places:
+</p>
 
-<blockquote>
+<ol>
+<li>
 <p>
-We recommend this issue be addressed in the context of providing concepts
-for the entire <tt>thread</tt> header.
+In concept AdaptableUnaryFunction change
 </p>
+<blockquote><pre>typename X::result_type;
+typename X::argument_type;
+</pre></blockquote>
 <p>
-May resolve for now by specifying arithmetic types,
-and in future change to <tt>ArithmeticLike</tt>.
-However, Alisdair believes this is not feasible.
+to
 </p>
+<blockquote><pre>Returnable result_type = typename X::result_type;
+typename argument_type = typename X::argument_type;
+</pre></blockquote>
 <p>
-Bill disagrees.
+[The replacement "Returnable result_type" instead of "typename
+result_type" is non-editorial, but maybe you prefer that as well]
 </p>
+</li>
+<li>
 <p>
-We look forward to proposed wording.  Move to Open.
+In concept AdaptableBinaryFunction change
 </p>
-</blockquote>
-
-<p><i>[
-2009-08-01 Howard adds:
-]</i></p>
-
-
-<blockquote>
-See commented dated 2009-08-01 in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
+<blockquote><pre>typename X::result_type;
+typename X::first_argument_type;
+typename X::second_argument_type;
+</pre></blockquote>
+<p>
+to
+</p>
+<blockquote><pre>Returnable result_type = typename X::result_type;
+typename first_argument_type = typename X::first_argument_type;
+typename second_argument_type = typename X::second_argument_type;
+</pre></blockquote>
 <p>
+[The replacement "Returnable result_type" instead of "typename
+result_type" is non-editorial, but maybe you prefer that as well.]
 </p>
+</li>
 
-
-
-
-
-<hr>
-<h3><a name="954"></a>954. Various threading bugs #4</h3>
-<p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-08-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
+<li>
 <p>
-Table 55 -- Clock Requirements (in 20.9.1 [time.clock.req])
+In class unary/binary_function
 </p>
-
 <ol type="a">
 <li>
-the requirements for <tt>C1::time_point</tt> require <tt>C1</tt> and <tt>C2</tt>
-to "refer to the same epoch", but "epoch" is not defined.
-</li>
-<li>
-"Different clocks may share a <tt>time_point</tt> definition if it is
-valid to compare their <tt>time_point</tt>s by comparing their
-respective <tt>duration</tt>s." What does "valid" mean here? And, since
-<tt>C1::rep</tt> is "**THE** representation type of the native
-<tt>duration</tt> and <tt>time_point</tt>" (emphasis added), there
-doesn't seem to be much room for some other representation.
-</li>
-<li>
-<tt>C1::is_monotonic</tt> has type "<tt>const bool</tt>". The
-"<tt>const</tt>" should be removed.
+I suggest to change "ReturnType" to "Returnable" in both cases.
 </li>
 <li>
-<tt>C1::period</tt> has type <tt>ratio</tt>. <tt>ratio</tt> isn't a type, 
-it's a template. What is the required type?
+I think you want to replace the remaining occurrences of "Predicate" by "P"
+(in both classes in copy/move from a predicate)
 </li>
 </ol>
-
-<p><i>[
-2009-05-10 Howard adds:
-]</i></p>
-
-
-<ol type="a">
-<li>
-<p>
-"epoch" is purposefully not defined beyond the common English
-<a href="http://www.dictionary.net/epoch">definition</a>.  The C standard
-also chose not to define epoch, though POSIX did.  I believe it is a strength
-of the C standard that epoch is not defined.  When it is known that two <tt>time_point</tt>s
-refer to the same epoch, then a definition of the epoch is not needed to compare
-the two <tt>time_point</tt>s, or subtract them.
-</p>
-<p>
-A <tt>time_point</tt> and a <tt>Clock</tt> implicitly refer to an (unspecified) epoch.
-The <tt>time_point</tt> represents an offset (<tt>duration</tt>) from an epoch.
-</p>
 </li>
 <li>
 <p>
-The sentence:
-</p>
-<blockquote>
-Different clocks 
-may share a <tt>time_point</tt>
-definition if it is valid to 
-compare their <tt>time_point</tt>s by 
-comparing their respective 
-<tt>duration</tt>s.
-</blockquote>
-
-<p>
-is redundant and could be removed.  I believe the sentence which follows the above:
+I think you need to change the proposed signatures of not1 and not2, because
+they would still remain unconstrained: To make them constrained at least a
+single requirement needs to be added to enable requirement implication. This
+could be done via a dummy ("requires True&lt;true&gt;") or just explicit as follows:
 </p>
-
+<ol type="a">
+<li>
+<blockquote><pre>template &lt;AdaptableUnaryFunction P&gt;
+requires Predicate&lt; P, P::argument_type&gt;
+unary_negate&lt;P&gt; not1(const P&amp;&amp; pred);
+template &lt;AdaptableUnaryFunction P&gt;
+requires Predicate&lt; P, P::argument_type &gt;
+unary_negate&lt;P&gt; not1(P&amp;&amp; pred);
+</pre>
 <blockquote>
-<tt>C1</tt> and <tt>C2</tt> shall refer to the same epoch.
+-3- Returns: unary_negate&lt;P&gt;(pred).
+</blockquote>
 </blockquote>
-
 <p>
-is sufficient.  If two clocks share the same epoch, then by definition, comparing
-their <tt>time_point</tt>s is valid.
+[Don't we want a move call for the second overload as in
 </p>
-</li>
-<li>
-<tt>is_monotonic</tt> is meant to never change (be <tt>const</tt>).  It is also
-desired that this value be usable in compile-time computation and branching.
-</li>
-<li>
+<blockquote><pre>unary_negate&lt;P&gt;(std::move(pred))
+</pre></blockquote>
 <p>
-This should probably instead be worded:
+in the Returns clause ?]
 </p>
-<blockquote>
-An instantiation of <tt>ratio</tt>.
-</blockquote>
 </li>
-</ol>
-
-<p><i>[
-Batavia (2009-05):
-]</i></p>
-
-<blockquote>
+<li>
+<pre>template &lt;AdaptableBinaryFunction P&gt;
+requires Predicate&lt; P, P::first_argument_type, P::second_argument_type &gt;
+binary_negate&lt;P&gt; not2(const P&amp; pred);
+template &lt;AdaptableBinaryFunction P&gt;
+requires Predicate&lt; P, P::first_argument_type, P::second_argument_type &gt;
+binary_negate&lt;P&gt; not2(P&amp;&amp; pred);
+</pre>
 <p>
-Re (a): It is not clear to us whether "epoch" is a term of art.
+-5- Returns: binary_negate&lt;P&gt;(pred).
 </p>
 <p>
-Re (b), (c), and (d):  We agree with Howard's comments,
-and would consider adding to (c) a <tt>static constexpr</tt> requirement.
+[Don't we want a move call for the second overload as in
 </p>
+<blockquote><pre>binary_negate&lt;P&gt;(std::move(pred))
+</pre></blockquote>
 <p>
-Move to Open pending proposed wording.
+in the Returns clause ?]
 </p>
+</li>
+</ol>
+</li>
+</ol>
 </blockquote>
 
 <p><i>[
-2009-05-25 Daniel adds:
-]</i></p>
-
-
-<blockquote>
-In regards to (d) I suggest to say "a specialization of ratio" instead of
-"An instantiation of ratio". This seems to be the better matching standard
-core language term for this kind of entity.
-</blockquote>
-
-<p><i>[
-2009-05-25 Ganesh adds:
+Batavia (2009-05):
 ]</i></p>
 
-
 <blockquote>
 <p>
-Regarding (a), I found this paper on the ISO website using the term "epoch" consistently with the current wording:
+There is concern that complicating the solution
+to preserve the ABI seems unnecessary,
+since we're not in general preserving the ABI.
 </p>
-
 <p>
-<a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM">http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM</a>
+We would prefer a separate paper consolidating all Clause 20
+issues that are for the purpose of providing constrained versions
+of the existing facilities.
 </p>
 <p>
-which is part of ISO/IEC 18026 "Information technology -- Spatial Reference Model (SRM)".
+Move to Open.
 </p>
 </blockquote>
 
 <p><i>[
-2009-08-01 Howard: Moved to Reivew as the wording requested in Batavia has been provided.
+2009-10 post-Santa Cruz:
 ]</i></p>
 
 
-
-
-<p><b>Proposed resolution:</b></p>
-<ol type="a">
-<li>
-<p>
-Change 20.9.1 [time.clock.req] p1:
-</p>
 <blockquote>
--1- A clock is a bundle consisting of a native <tt>duration</tt>, a native <tt>time_point</tt>, and a function <tt>now()</tt> to get the 
-current <tt>time_point</tt>.  <ins>The origin of the clock's <tt>time_point</tt> is referred to as the clock's <i>epoch</i> as defined in 
-section 6.3 of ISO/IEC 18026.</ins>
-A clock shall meet the requirements in Table 45.
+Leave open pending the potential move constructor paper. Note that
+we consider the "constraining" part NAD Concepts.
 </blockquote>
-</li>
-<li>
-<p>
-Remove the sentence from the <tt>time_point</tt> row of the table "Clock Requirements":
-</p>
-<table border="1">
-<caption>Clock requirements</caption>
-<tbody><tr>
-<td>
-<tt>C1::time_point</tt>
-</td>
-<td>
-<tt>chrono::time_point&lt;C1&gt;</tt> or <tt>chrono::time_point&lt;C2, C1::duration&gt;</tt>
-</td>
-<td>
-The native <tt>time_point</tt> type of the clock.
-<del>Different clocks may share a <tt>time_point</tt> definition if it is valid to compare their <tt>time_point</tt>s by comparing their respective <tt>duration</tt>s.</del>
-<tt>C1</tt> and <tt>C2</tt> shall refer to the same epoch.
-</td>
-</tr>
-</tbody></table>
-</li>
-</ol>
-<ol start="4" type="a">
-<li>
-<p>
-Change the row starting with <tt>C1::period</tt> of the table "Clock Requirements":
-</p>
-<table border="1">
-<caption>Clock requirements</caption>
-<tbody><tr>
-<td>
-<tt>C1::period</tt>
-</td>
-<td>
-<ins>a specialization of</ins> <tt>ratio</tt>
-</td>
-<td>
-The tick period of the clock in seconds.
-</td>
-</tr>
-</tbody></table>
-
-</li>
-</ol>
 
 
 
-
-
-<hr>
-<h3><a name="955"></a>955. Various threading bugs #5</h3>
-<p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-06-07</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Proposed resolution:</b></p>
 <p>
-20.9.1 [time.clock.req] requires that a clock type have a member
-typedef named <tt>time_point</tt> that names an instantiation of the
-template <tt>time_point</tt>, and a member named <tt>duration</tt> that
-names an instantiation of the template <tt>duration</tt>. This mixing of
-levels is confusing. The typedef names should be different from the
-template names.
+Add new concepts where appropriate::
 </p>
 
-<p><i>[
-Post Summit, Anthony provided proposed wording.
-]</i></p>
-
-
-<p><i>[
-2009-05-04 Howard adds:
-]</i></p>
+<blockquote><pre>auto concept AdaptableUnaryFunction&lt; typename X &gt; {
+  typename X::result_type;
+  typename X::argument_type;
+}
 
+auto concept AdaptableBinaryFunction&lt; typename X &gt; {
+  typename X::result_type;
+  typename X::first_argument_type;
+  typename X::second_argument_type;
+}
+</pre></blockquote>
 
-<blockquote>
 <p>
-The reason that the typedef names were given the same name as the class templates
-was so that clients would not have to stop and think about whether they were
-using the clock's native <tt>time_point</tt> / <tt>duration</tt> or the class
-template directly.  In this case, one person's confusion is another person's
-encapsulation.  The detail that sometimes one is referring to the clock's
-native types, and sometimes one is referring to an independent type is
-<em>purposefully</em> "hidden" because it is supposed to be an unimportant
-detail.  It can be confusing to have to remember when to type <tt>duration</tt>
-and when to type <tt>duration_type</tt>, and there is no need to require the
-client to remember something like that.
+Revise as follows:
 </p>
 
 <p>
-For example, here is code that I once wrote in testing out the usability of
-this facility:
+Base 20.7.3 [base] (Only change is constrained Result)
 </p>
 
-<blockquote><pre>template &lt;class Clock, class Duration&gt;
-void do_until(const std::chrono::<b>time_point</b>&lt;Clock, Duration&gt;&amp; t)
-{
-    typename Clock::<b>time_point now</b> = Clock::now();
-    if (t &gt; now)
-    {
-        typedef typename std::common_type
-        &lt;
-            Duration,
-            typename std::chrono::system_clock::<b>duration</b>
-        &gt;::type CD;
-        typedef std::chrono::<b>duration</b>&lt;double, std::nano&gt; ID;
-
-        CD d = t - now;
-        ID us = duration_cast&lt;ID&gt;(d);
-        if (us &lt; d)
-            ++us;
-        ...
-    }
-}
-</pre></blockquote>
-
+<blockquote>
 <p>
-I see no rationale to require the client to append <tt>_type</tt> to <em>some</em>
-of those declarations.  It seems overly burdensome on the author of <tt>do_until</tt>:
+-1-  The following classes are provided to simplify the typedefs of the
+argument and result types:
 </p>
+<pre>namespace std {
+  template &lt;class Arg, <del>class</del> <ins>ReturnType</ins> Result&gt;
+  struct unary_function {
+     typedef Arg    argument_type;
+     typedef Result result_type;
+  };
 
-<blockquote><pre>template &lt;class Clock, class Duration&gt;
-void do_until(const std::chrono::<b>time_point</b>&lt;Clock, Duration&gt;&amp; t)
-{
-    typename Clock::<b>time_point<font color="#c80000">_type</font></b> now = Clock::now();
-    if (t &gt; now)
-    {
-        typedef typename std::common_type
-        &lt;
-            Duration,
-            typename std::chrono::system_clock::<b>duration<font color="#c80000">_type</font></b>
-        &gt;::type CD;
-        typedef std::chrono::<b>duration</b>&lt;double, std::nano&gt; ID;
-
-        CD d = t - now;
-        ID us = duration_cast&lt;ID&gt;(d);
-        if (us &lt; d)
-            ++us;
-        ...
-    }
+  template &lt;class Arg1, class Arg2, <del>class</del> <ins>ReturnType</ins> Result&gt;
+  struct binary_function {
+     typedef Arg1   first_argument_type;
+     typedef Arg2   second_argument_type;
+     typedef Result result_type;
+  };
 }
 </pre></blockquote>
 
 <p>
-Additionally I'm fairly certain that this suggestion hasn't been implemented.
-If it had, it would have been discovered that it is incomplete.  <tt>time_point</tt>
-also has a nested type (purposefully) named <tt>duration</tt>.
+Negators 20.7.10 [negators]:
 </p>
+
 <blockquote>
-That is, the current proposed wording would put the WP into an inconsistent state.
-</blockquote>
 <p>
-In contrast,
-the current WP has been implemented and I've received very favorable feedback
-from people using this interface in real-world code.
+-1- Negators <tt>not1</tt> and <tt>not2</tt> take a unary and a binary predicate,
+respectively, and return their complements (5.3.1).
 </p>
 
-</blockquote>
+<pre>template &lt;<del>class</del> <ins>AdaptableUnaryFunction</ins> P<del>redicate</del>&gt;
+  <ins>requires Predicate&lt; P, P::argument_type &gt;</ins>
+  class unary_negate
+    : public unary_function&lt;<del>typename</del> P<del>redicate</del>::argument_type,bool&gt; {
+  public:
+    <ins>unary_negate(const unary_negate &amp; ) = default;</ins>
+    <ins>unary_negate(unary_negate &amp;&amp; );</ins>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+    <ins>requires CopyConstructible&lt; P &gt;</ins>
+       explicit unary_negate(const Predicate&amp; pred); 
+    <ins>requires MoveConstructible&lt; P &gt;
+       explicit unary_negate(Predicate &amp;&amp; pred);</ins>
 
+    bool operator()(const <del>typename</del> P<del>redicate</del>::argument_type&amp; x) const;
+  };
+</pre>
 <blockquote>
-<p>
-Bill agrees that distinct names should be used for distinct kinds of entities.
-</p>
-<p>
-Walter would prefer not to suffix type names,
-especially for such well-understood terms as "duration".
-</p>
-<p>
-Howard reminds us that the proposed resolution is incomplete, per his comment
-in the issue.
-</p>
-<p>
-Move to Open.
-</p>
+-2 <tt>operator()</tt> returns <tt>!pred(x)</tt>.
 </blockquote>
 
-<p><i>[
-2009-06-07 Howard adds:
-]</i></p>
-
-
+<pre>template &lt;class Predicate&gt;
+  unary_negate&lt;Predicate&gt; not1(const Predicate&amp;amp; pred);
+<ins>template &lt;class Predicate&gt;
+  unary_negate&lt;Predicate&gt; not1(Predicate&amp;&amp; pred);</ins>
+</pre>
 <blockquote>
-<p>
-Not meaning to be argumentative, but we have a decade of positive experience
-with the precedent of using the same name for the nested type as an external
-class representing an identical concept.
-</p>
+-3-  <i>Returns:</i> <tt>unary_negate&lt;Predicate&gt;(pred)</tt>.
+</blockquote>
 
-<blockquote><pre>template&lt;class Category, class T, class Distance = ptrdiff_t,
-         class Pointer = T*, class Reference = T&amp;&gt;
-struct <b>iterator</b>
-{
-    ...
-};
+<pre>template &lt;<del>class</del> <ins>AdaptableBinaryFunction</ins> P<del>redicate</del> &gt;
+  <ins>requires Predicate&lt; P, P::first_argument_type, P::second_argument_type &gt;</ins>
+  class binary_negate
+    : public binary_function&lt;<del>typename</del> P<del>redicate</del>::first_argument_type,
+                              <del>typename</del> P<del>redicate</del>::second_argument_type, bool&gt; {
+  public:
+    <ins>biary_negate(const binary_negate &amp; ) = default;</ins>
+    <ins>binary_negate(binary_negate &amp;&amp; );</ins>
 
-template &lt;BidirectionalIterator Iter&gt;
-class <b>reverse_iterator</b>
-{
-    ...
-};
+    <ins>requires CopyConstructible&lt; P &gt;</ins>
+       explicit binary_negate(const Predicate&amp; pred);
+    <ins>requires MoveConstructible&lt; P &gt;
+       explicit binary_negate(const Predicate&amp; pred);</ins>
 
-template &lt;ValueType T, Allocator Alloc = allocator&lt;T&gt; &gt;
-    requires NothrowDestructible&lt;T&gt;
-class list
-{
-public:
-    typedef <i>implementation-defined</i>     <b>iterator</b>;
-    ...
-    typedef reverse_iterator&lt;iterator&gt; <b>reverse_iterator</b>;
-    ...
-};
-</pre></blockquote>
+    bool operator()(const <del>typename</del> P<del>redicate</del>::first_argument_type&amp; x,
+                    const <del>typename</del> P<del>redicate</del>::second_argument_type&amp; y) const;
+  };
+</pre>
+<blockquote>
+-4- <tt>operator()</tt> returns <tt>!pred(x,y)</tt>.
+</blockquote>
 
-<p>
-I am aware of <em>zero</em> complaints regarding the use of <tt>iterator</tt>
-and <tt>reverse_iterator</tt> as nested types of the containers despite these
-names also having related meaning at namespace std scope.
-</p>
+<pre>template &lt;class Predicate&gt;
+  binary_negate&lt;Predicate&gt; not2(const Predicate&amp; pred);
+<ins>template &lt;class Predicate&gt;
+  binary_negate&lt;Predicate&gt; not2(Predicate&amp;&amp; pred);</ins>
+</pre>
 
-<p>
-Would we really be doing programmers a favor by renaming these nested types?
-</p>
+<blockquote>
+-5- <i>Returns:</i> <tt>binary_negate&lt;Predicate&gt;(pred)</tt>.
+</blockquote>
+</blockquote>
 
-<blockquote><pre>template &lt;ValueType T, Allocator Alloc = allocator&lt;T&gt; &gt;
-    requires NothrowDestructible&lt;T&gt;
-class list
-{
-public:
-    typedef <i>implementation-defined</i>     <b>iterator_type</b>;
-    ...
-    typedef reverse_iterator&lt;iterator&gt; <b>reverse_iterator_type</b>;
-    ...
-};
-</pre></blockquote>
 
-<p>
-I submit that such design contributes to needless verbosity which ends up
-reducing readability.
-</p>
-</blockquote>
 
 
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.9 [time]:
-</p>
 
-<blockquote><pre>...
-template &lt;class Clock, class Duration = typename Clock::duration<ins>_type</ins>&gt; class time_point;
-...
-</pre></blockquote>
+<hr>
+<h3><a name="1079"></a>1079. UK-265: <code>RandomAccessIterator</code>'s <code>operator-</code> has nonsensical effects clause</h3>
+<p><b>Section:</b> 24.2.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2009-03-20  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses UK 265</b></p>
 
+<p>UK-265:</p>
 <p>
-Change 20.9.1 [time.clock.req]:
+This effects clause is nonesense. It looks more like an axiom stating
+equivalence, and certainly an effects clause cannot change the state of
+two arguments passed by const reference
 </p>
 
-<blockquote>
-<table border="1">
-<caption>Table 45 -- Clock requirements</caption>
-<tbody><tr>
-<th>Expression</th>
-<th>Return type</th>
-<th>Operational semantics</th>
-</tr>
-<tr>
-<td>...</td>
-<td>...</td>
-<td>...</td>
-</tr>
-<tr>
-<td><tt>C1::duration<ins>_type</ins></tt></td>
-<td><tt>chrono::duration&lt;C1::rep, C1::period&gt;</tt></td>
-<td>The native <tt>duration</tt> type of the clock.</td>
-</tr>
-<tr>
-<td><tt>C1::time_point<ins>_type</ins></tt></td>
-<td><tt>chrono::time_point&lt;C1&gt;</tt> or <tt>chrono::time_point&lt;C2, C1::duration<ins>_type</ins>&lt;</tt></td>
-<td>The native <tt>time_point</tt> type of the clock.   Different clocks may  share a <tt>time_point<ins>_type</ins></tt>
-definition if it is valid to 
-compare their <tt>time_point<ins>_type</ins></tt>s by 
-comparing their respective 
-<tt>duration<ins>_type</ins></tt>s. <tt>C1</tt> and <tt>C2</tt> shall 
-refer to the same epoch.</td>
-</tr>
-<tr>
-<td>...</td>
-<td>...</td>
-<td>...</td>
-</tr>
-<tr>
-<td><tt>C1::now()</tt></td>
-<td><tt>C1::time_point<ins>_type</ins></tt></td>
-<td>Returns a <tt>time_point<ins>_type</ins></tt> object 
-representing the current point 
-in time.
-</td>
-</tr>
-</tbody></table>
-</blockquote>
+<p><i>[
+2009-09-18 Alisdair adds:
+]</i></p>
 
-<p>
-Change 20.9.5.1 [time.clock.system]:
-</p>
 
 <blockquote>
 <p>
--1- Objects of class <tt>system_clock</tt> represent wall clock time from the system-wide realtime clock.
+For random access iterators, the definitions of <tt>(b-a)</tt> and
+<tt>(a&lt;b)</tt> are circular:
 </p>
 
-<blockquote><pre>class system_clock { 
-public: 
-  typedef <i>see below</i> rep; 
-  typedef ratio&lt;<i>unspecified</i>, <i>unspecified</i>&gt; period; 
-  typedef chrono::duration&lt;rep, period&gt; duration<ins>_type</ins>; 
-  typedef chrono::time_point&lt;system_clock&gt; time_point<ins>_type</ins>; 
-  static const bool is_monotonic = <i>unspecified</i> ; 
-
-  static time_point<ins>_type</ins> now(); 
-
-  // Map to C API 
-  static time_t to_time_t (const time_point<ins>_type</ins>&amp; t); 
-  static time_point<ins>_type</ins> from_time_t(time_t t); 
-};
-</pre></blockquote>
-
 <p>
--2- <tt>system_clock::duration<ins>_type</ins>::min() &lt; system_clock::duration<ins>_type</ins>::zero()</tt> shall be <tt>true</tt>.
+From table Table 104 -- Random access iterator requirements:
 </p>
 
-<pre>time_t to_time_t(const time_point<ins>_type</ins>&amp; t);
-</pre>
+<blockquote><pre>b - a :==&gt;  (a &lt; b) ? distance(a,b) : -distance(b,a)
 
-<blockquote>
--3- <i>Returns:</i> A <tt>time_t</tt> object that represents the same
-point in time as <tt>t</tt> when both values are truncated to the
-coarser of the precisions of <tt>time_t</tt> and <tt>time_point<ins>_type</ins></tt>.
+a &lt; b :==&gt;  b - a &gt; 0
+</pre></blockquote>
 </blockquote>
 
-<pre><tt>time_point<ins>_type</ins></tt> from_time_t(time_t t);
-</pre>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
 
 <blockquote>
--4- <i>Returns:</i> A <tt>time_point<ins>_type</ins></tt> object that represents the same point
-in time as <tt>t</tt> when both values are truncated to the coarser of the
-precisions of <tt>time_t</tt> and <tt>time_point<ins>_type</ins></tt>.
-</blockquote>
+Moved to Ready.
 </blockquote>
 
-<p>
-Change 20.9.5.2 [time.clock.monotonic]:
-</p>
-
-<blockquote><pre>class monotonic_clock { 
-public: 
-  typedef <i>unspecified</i>                                rep; 
-  typedef ratio&lt;<i>unspecified</i> , <i>unspecified</i>&gt;           period; 
-  typedef chrono::duration&lt;rep, period&gt;              duration<ins>_type</ins>; 
-  typedef chrono::time_point&lt;<i>unspecified</i> , duration<ins>_type</ins>&gt; time_point<ins>_type</ins>; 
-  static const bool is_monotonic =                   true; 
 
-  static time_point<ins>_type</ins> now();
-};
-</pre></blockquote>
-
-<p>
-Change 20.9.5.3 [time.clock.hires]:
-</p>
 
-<blockquote><pre>class high_resolution_clock { 
-public: 
-  typedef <i>unspecified</i>                                rep; 
-  typedef ratio&lt;<i>unspecified</i> , <i>unspecified</i>&gt;           period; 
-  typedef chrono::duration&lt;rep, period&gt;              duration<ins>_type</ins>; 
-  typedef chrono::time_point&lt;<i>unspecified</i> , duration<ins>_type</ins>&gt; time_point<ins>_type</ins>; 
-  static const bool is_monotonic =                   true; 
+<p><b>Proposed resolution:</b></p>
 
-  static time_point<ins>_type</ins> now();
-};
-</pre></blockquote>
+<p>Modify 24.2.5 [random.access.iterators]p7-9 as follows:</p>
 
+<blockquote><pre>difference_type operator-(const X&amp; a, const X&amp; b);
+</pre>
+<ol start="7">
+  <li><i>Precondition</i>: there exists a value <code>n</code> of
+  <code>difference_type</code> such that <code>a == b + n</code>.</li>
+  <li><del><i>Effects</i>: <code>b == a + (b - a)</code></del></li>
+  <li><i>Returns</i>: <del><code>(a &lt; b) ? distance(a,b) :
+  -distance(b,a)</code></del><ins><code>n</code></ins></li>
+</ol>
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="956"></a>956. Various threading bugs #6</h3>
-<p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
+<h3><a name="1089"></a>1089. Response to JP 76</h3>
+<p><b>Section:</b> 30 [thread] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread">issues</a> in [thread].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
+<p><b>Addresses JP 76</b></p>
+
 <p>
-20.9.1 [time.clock.req] uses the word "native" in several places,
-but doesn't define it. What is a "native <tt>duration</tt>"?
+A description for "Throws: Nothing." are not unified.
 </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><b>Proposed resolution:</b></p>
 <p>
+At the part without throw, "Throws: Nothing." should be described.
 </p>
 
-
-
-
-
-<hr>
-<h3><a name="957"></a>957. Various threading bugs #7</h3>
-<p><b>Section:</b> 20.9.5.1 [time.clock.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.system">issues</a> in [time.clock.system].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-20.9.5.1 [time.clock.system]: <tt>to_time_t</tt> is overspecified. It
-requires truncation, but should allow rounding. For example, suppose a
-system has a clock that gives times in milliseconds, but <tt>time()</tt> rounds
-those times to the nearest second. Then <tt>system_clock</tt> can't use any
-resolution finer than one second, because if it did, truncating times
-between half a second and a full second would produce the wrong <tt>time_t</tt>
-value.
+Add "Throws: Nothing." to the following.
 </p>
 
+<ul>
+<li>
+30.3.1.6 [thread.thread.static] p1
+</li>
+<li>
+30.4.3.1 [thread.lock.guard] p4
+</li>
+<li>
+30.4.3.2.1 [thread.lock.unique.cons] p6
+</li>
+<li>
+30.5.1 [thread.condition.condvar] p7 and p8
+</li>
+<li>
+30.5.2 [thread.condition.condvarany] p6, p7, p19, p21 and p25
+</li>
+</ul>
+
 <p><i>[
-Post Summit Anthony Williams provided proposed wording.
+Summit:
 ]</i></p>
 
+<blockquote>
+Pass on to editor.
+</blockquote>
 
 <p><i>[
-Batavia (2009-05):
+Post Summit:  Editor declares this non-editorial.
 ]</i></p>
 
-<blockquote>
-Move to Review pending input from Howard. and other stakeholders.
-</blockquote>
 
 <p><i>[
-2009-05-23 Howard adds:
+2009-08-01 Howard provided wording:
 ]</i></p>
 
 
 <blockquote>
-I am in favor of the wording provided by Anthony.
-</blockquote>
-
 
-<p><b>Proposed resolution:</b></p>
 <p>
-In 20.9.5.1 [time.clock.system] replace paragraphs 3 and 4 with:
+The definition of "<i>Throws:</i> Nothing." that I added is probably going to
+be controversial, but I beg you to consider it seriously.
 </p>
 
 <blockquote>
-<pre>time_t to_time_t(const time_point&amp; t);
-</pre>
-<blockquote>
--3- <i>Returns:</i> A <tt>time_t</tt> object that represents the same
-point in time as <tt>t</tt> when both values are <del>truncated</del>
-<ins>restricted</ins> to the coarser of the precisions of
-<tt>time_t</tt> and <tt>time_point</tt>. <ins> It is implementation
-defined whether values are rounded or truncated to the required
-precision.</ins>
-</blockquote>
-
-<pre>time_point from_time_t(time_t t);
-</pre>
-<blockquote>
--4- <i>Returns:</i> A <tt>time_point</tt> object that represents the
-same point in time as <tt>t</tt> when both values are <del>truncated</del>
-<ins>restricted</ins> to the
-coarser of the precisions of <tt>time_t</tt> and <tt>time_point</tt>.
-<ins>It is implementation defined whether values are
-rounded or truncated to the required precision.</ins>
-</blockquote>
-</blockquote>
-
-
-
-
+<p>
+In C++ there are three "flow control" options for a function:
+</p>
 
-<hr>
-<h3><a name="958"></a>958. Various threading bugs #8</h3>
-<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-08-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-30.5.1 [thread.condition.condvar]: the specification for <tt>wait_for</tt>
-with no predicate has an effects clause that says it calls <tt>wait_until</tt>,
-and a returns clause that sets out in words how to determine the return
-value. Is this description of the return value subtly different from the
-description of the value returned by <tt>wait_until</tt>? Or should the effects
-clause and the returns clause be merged?
-</p>
+<ol>
+<li>
+It can return, either with a value, or with <tt>void</tt>.
+</li>
+<li>
+It can call a function which never returns, such as <tt>std::exit</tt> or
+<tt>std::terminate</tt>.
+</li>
+<li>
+It can throw an exception.
+</li>
+</ol>
 
-<p><i>[
-Summit:
-]</i></p>
+The above list can be abbreviated with:
 
+<ol>
+<li><b>R</b>eturns.</li>
+<li><b>E</b>nds program.</li>
+<li><b>T</b>hrows exception.</li>
+</ol>
 
-<blockquote>
-Move to open. Associate with LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> and any other monotonic-clock
-related issues.
-</blockquote>
+<p>
+In general a function can have the behavior of any of these 3, or any combination
+of any of these three, depending upon run time data.
+</p>
 
-<p><i>[
-2009-08-01 Howard adds:
-]</i></p>
+<ol>
+<li><b>R</b></li>
+<li><b>E</b></li>
+<li><b>T</b></li>
+<li><b>RE</b></li>
+<li><b>RT</b></li>
+<li><b>ET</b></li>
+<li><b>RET</b></li>
+</ol>
 
+<p>
+A function with no throw spec, and no documentation, is in general a <b>RET</b>
+function.  It may return, it may end the program, or it may throw.  When we
+specify a function with an empty throw spec:
+</p>
 
-<blockquote>
-I believe that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> (currently Ready) addresses this issue, and
-that this issue should be marked NAD, solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> (assuming
-it moves to WP).
-</blockquote>
+<blockquote><pre>void f() throw();
+</pre></blockquote>
 
+<p>
+We are saying that <tt>f()</tt> is an <b>RE</b> function:  It may return or end
+the program, but it will not throw.
+</p>
 
+<p>
+I posit that there are very few places in the library half of the standard
+where we intend for functions to be able to end the program (call <tt>terminate</tt>).
+And none of those places where we do say <tt>terminate</tt> could be called,
+do we currently say "<i>Throws:</i> Nothing.".
+</p>
 
-<p><b>Proposed resolution:</b></p>
 <p>
+I believe that if we define "<i>Throws:</i> Nothing." to mean <b>R</b>,
+we will both clarify many, many places in the standard, <em>and</em> give us a
+good rationale for choosing between "<i>Throws:</i> Nothing." (<b>R</b>)
+and <tt>throw()</tt> (<b>RE</b>) in the future.  Indeed, this may give us motivation
+to change several <tt>throw()</tt>s to "<i>Throws:</i> Nothing.".
 </p>
+</blockquote>
 
+<p>
+I did not add the following changes as JP 76 requested as I believe we want to
+allow these functions to throw:
+</p>
 
+<blockquote>
+<p>
+Add a paragraph under 30.4.3.1 [thread.lock.guard] p4:
+</p>
 
+<blockquote><pre>explicit lock_guard(mutex_type&amp; m);
+</pre>
 
+<p><ins>
+<i>Throws:</i> Nothing.
+</ins></p>
+</blockquote>
 
-<hr>
-<h3><a name="959"></a>959. Various threading bugs #9</h3>
-<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-08-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-30.5.1 [thread.condition.condvar]: <tt>condition_variable::wait_for</tt>
-is required to compute the absolute time by adding the duration value to
-<tt>chrono::monotonic_clock::now()</tt>, but <tt>monotonic_clock</tt> is not required to
-exist.
+Add a paragraph under 30.4.3.2.1 [thread.lock.unique.cons] p6:
 </p>
 
-<p><i>[
-Summit:
-]</i></p>
-
+<blockquote><pre>explicit unique_lock(mutex_type&amp; m);
+</pre>
 
-<blockquote>
-Move to open. Associate with LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> and any other monotonic-clock
-related issues.
+<p><ins>
+<i>Throws:</i> Nothing.
+</ins></p>
 </blockquote>
 
-<p><i>[
-2009-08-01 Howard adds:
-]</i></p>
+<p>
+Add a paragraph under 30.5.2 [thread.condition.condvarany] p19, p21 and p25:
+</p>
 
+<blockquote><pre>template &lt;class Lock, class Rep, class Period&gt; 
+  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
+</pre>
 
-<blockquote>
-I believe that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> (currently Ready) addresses this issue, and
-that this issue should be marked NAD, solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> (assuming
-it moves to WP).
+<p><ins>
+<i>Throws:</i> Nothing.
+</ins></p>
 </blockquote>
 
+<blockquote><pre>template &lt;class Lock, class Duration, class Predicate&gt; 
+  bool wait_until(Lock&amp; lock, const chrono::time_point&lt;Clock, Duration&gt;&amp; rel_time, Predicate pred);
+</pre>
 
+<p><ins>
+<i>Throws:</i> Nothing.
+</ins></p>
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
+<blockquote><pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt; 
+  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);
+</pre>
 
+<p><ins>
+<i>Throws:</i> Nothing.
+</ins></p>
+</blockquote>
 
+</blockquote>
 
-<hr>
-<h3><a name="960"></a>960. Various threading bugs #10</h3>
-<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-03-27</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-30.4.1 [thread.mutex.requirements]: paragraph 4 is entitled
-"Error conditions", but according to 17.5.1.4 [structure.specifications], "Error
-conditions:" specifies "the error conditions for error codes reported by
-the function." It's not clear what this should mean when there is no
-function in sight.
-</p>
+</blockquote>
 
 <p><i>[
-Summit:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Move to open.
+Defer pending further developments with exception restriction annotations.
 </blockquote>
 
-<p><i>[
-Beman provided proposed wording.
-]</i></p>
-
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change 30.4.1 [thread.mutex.requirements] Mutex requirements,
-paragraph 4 as indicated:
+Add a paragraph after 17.5.1.4 [structure.specifications] p4:
 </p>
 
 <blockquote>
 <p>
--4- <del><i>Error conditions:</i></del>
-<ins>The error conditions for error codes, if any, reported by member
-functions of type Mutex shall be:</ins>
+-3- Descriptions of function semantics contain the following elements
+(as appropriate):<sup>158</sup>
 </p>
 <ul>
+<li>...</li>
 <li>
-<tt>not_enough_memory</tt> -- if there is not enough memory to construct
-the mutex object.
-</li>
-<li>
-<tt>resource_unavailable_try_again</tt> -- if any native handle type
-manipulated is not available.
-</li>
-<li>
-<tt>operation_not_permitted</tt> -- if the thread does not have the
-necessary permission to change the state of the mutex object.
-</li>
-<li>
-<tt>device_or_resource_busy</tt> -- if any native handle type
-manipulated is already locked.
-</li>
-<li>
-<tt>invalid_argument</tt> -- if any native handle type manipulated as
-part of mutex construction is incorrect.
+<i>Throws:</i> any exceptions thrown by the function, and the conditions
+that would cause the exception
 </li>
+<li>...</li>
 </ul>
-</blockquote>
 
+<p>
+-4- For non-reserved replacement and handler functions, ...
+</p>
 
+<p><ins>
+A "<i>Throws:</i> Nothing." element indicates that the function shall
+return ordinarily, and not exit via an exception.  This element also
+indicates that the function <em>shall</em> return. [<i>Note:</i> This
+differs from an empty throw specification which may cause a function to
+call <tt>unexpected</tt> and subsequently <tt>terminate</tt>. &#8212;
+<i>end note</i>]
+</ins></p>
+</blockquote>
 
+<p>
+Add a paragraph under 30.3.1.6 [thread.thread.static] p1:
+</p>
 
+<blockquote><pre>unsigned hardware_concurrency();
+</pre>
 
-<hr>
-<h3><a name="961"></a>961. Various threading bugs #11</h3>
-<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-03-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-30.4.1 [thread.mutex.requirements] describes required member
-functions of mutex types, and requires that they throw exceptions under
-certain circumstances. This is overspecified. User-defined types can
-abort on such errors without affecting the operation of templates
-supplied by standard-library.
+-1- <i>Returns:</i> ...
 </p>
 
-<p><i>[
-Summit:
-]</i></p>
-
-<blockquote>
-Move to open. Related to conceptualization and should probably be
-tackled as part of that.
+<p><ins>
+<i>Throws:</i> Nothing.
+</ins></p>
 </blockquote>
 
+<p>
+Add a paragraph under 30.5.1 [thread.condition.condvar] p7 and p8:
+</p>
 
-<p><b>Proposed resolution:</b></p>
+<blockquote>
 <p>
+<i>[Informational, not to be incluced in the WP: The POSIX spec allows only:</i>
 </p>
+<dl>
+<dt><i>[EINVAL]</i></dt>
+<dd><i>The value <tt>cond</tt> does not refer to an initialized condition variable. &#8212; end informational]</i></dd>
+</dl>
 
+<pre>void notify_one();
+</pre>
 
+<p>
+-7- <i>Effects:</i> ...
+</p>
 
+<p><ins>
+<i>Throws:</i> Nothing.
+</ins></p>
+</blockquote>
 
+<blockquote><pre>void notify_all();
+</pre>
 
-<hr>
-<h3><a name="962"></a>962. Various threading bugs #12</h3>
-<p><b>Section:</b> 30.4.3.2.2 [thread.lock.unique.locking] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-07-21</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.lock.unique.locking">active issues</a> in [thread.lock.unique.locking].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.lock.unique.locking">issues</a> in [thread.lock.unique.locking].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-30.4.3.2.2 [thread.lock.unique.locking]:  <tt>unique_lock::lock</tt> is
-required to throw an object of type <tt>std::system_error</tt> "when the
-postcondition cannot be achieved." The postcondition is <tt>owns == true</tt>,
-and this is trivial to achieve. Presumably, the requirement is intended
-to mean something more than that.
+-8- <i>Effects:</i> ...
 </p>
 
-<p><i>[
-Summit:
-]</i></p>
-
-<blockquote>
-Move to open.
+<p><ins>
+<i>Throws:</i> Nothing.
+</ins></p>
 </blockquote>
 
-<p><i>[
-Beman has volunteered to provide proposed wording.
-]</i></p>
 
+<p>
+Add a paragraph under 30.5.2 [thread.condition.condvarany] p6 and p7:
+</p>
 
-<p><i>[
-2009-07-21 Beman added wording to address 30.2.2 [thread.req.exception]
-in response to the Frankfurt notes in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>.
-]</i></p>
+<blockquote>
+<pre>void notify_one();
+</pre>
 
+<p>
+-6- <i>Effects:</i> ...
+</p>
 
+<p><ins>
+<i>Throws:</i> Nothing.
+</ins></p>
+</blockquote>
 
+<blockquote><pre>void notify_all();
+</pre>
 
-<p><b>Proposed resolution:</b></p>
+<p>
+-7- <i>Effects:</i> ...
+</p>
 
-<p><i>Change Exceptions 30.2.2 [thread.req.exception] as indicated:</i></p>
-<blockquote>
-<p>Some functions described in this Clause are specified to throw exceptions of 
-type <code>system_error</code> (19.5.5). Such exceptions shall be thrown if <ins>
-any of the <i>Error conditions</i> are detected or</ins> a call to an operating 
-system or other underlying API results in an error that prevents the library 
-function from <del>satisfying its postconditions or from returning a meaningful 
-value</del> <ins>meeting its specifications</ins>. <ins>Nevertheless, failure to 
-allocate storage shall be reported as described in [res.on.exception.handling].</ins></p>
+<p><ins>
+<i>Throws:</i> Nothing.
+</ins></p>
 </blockquote>
 
-<p><i>Change thread assignment 30.3.1.4 [thread.thread.assign], join(), 
-paragraph 8 as indicated:</i></p>
-<blockquote>
-<p><i>Throws:</i> <code>std::system_error</code> when <del>the postconditions cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
 
-</blockquote>
 
-<p><i>Change thread assignment 30.3.1.4 [thread.thread.assign], detach(), paragraph 
-13 as indicated:</i></p>
-<blockquote>
 
-<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
-postconditions cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
 
-</blockquote>
 
-<p><i>Change Mutex requirements 30.4.1 [thread.mutex.requirements], paragraph 
-11, as indicated:</i></p>
-<blockquote>
 
-<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
-postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
-</blockquote>
-<p><i>Change unique_lock locking 30.4.3.2.2 [thread.lock.unique.locking], 
-paragraph 3, as indicated:</i></p>
-<blockquote>
+<hr>
+<h3><a name="1090"></a>1090. Missing description of <tt>packaged_task</tt> member <tt>swap</tt>,  missing non-member <tt>swap</tt></h3>
+<p><b>Section:</b> 30.6.10 [futures.task] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Class template <tt>packaged_task</tt> in 30.6.10 [futures.task] shows a member <tt>swap</tt>
+declaration, but misses to
+document it's effects (No prototype provided). Further on this class
+misses to provide a non-member
+swap.
+</p>
 
-<p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
-</blockquote>
-<p><i>Change unique_lock locking 30.4.3.2.2 [thread.lock.unique.locking], 
-paragraph 8, as indicated:</i></p>
-<blockquote>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
-<p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
-</blockquote>
-<p><i>Change unique_lock locking 30.4.3.2.2 [thread.lock.unique.locking], 
-paragraph 13, as indicated:</i></p>
 <blockquote>
-
-<p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
+<p>
+Alisdair notes that paragraph 2 of the proposed resolution has already been
+applied in the current Working Draft.
+</p>
+<p>
+We note a pending <tt>future</tt>-related paper by Detlef;
+we would like to wait for this paper before proceeding.
+</p>
+<p>
+Move to Open.
+</p>
 </blockquote>
-<p><i>Change unique_lock locking 30.4.3.2.2 [thread.lock.unique.locking], 
-paragraph 18, as indicated:</i></p>
-<blockquote>
 
-<p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
-</blockquote>
-<p><i>Change unique_lock locking 30.4.3.2.2 [thread.lock.unique.locking], 
-paragraph 22, as indicated:</i></p>
-<blockquote>
+<p><i>[
+2009-05-24 Daniel removed part 2 of the proposed resolution.
+]</i></p>
 
-<p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
-</blockquote>
-<p><i>Change Function call_once 30.4.5.2 [thread.once.callonce], paragraph 4, as 
-indicated</i></p>
-<blockquote>
-  <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>, 
-  or any exception thrown by <code>func</code>.</p>
-</blockquote>
-<p><i>Change Class condition_variable 30.5.1 [thread.condition.condvar], 
-paragraph 12, as indicated:</i></p>
-<blockquote>
 
-<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
-postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
-</blockquote>
-<p><i>Change Class condition_variable 30.5.1 [thread.condition.condvar], 
-paragraph 19, as indicated:</i></p>
-<blockquote>
+<p><i>[
+2009-10 post-Santa Cruz:
+]</i></p>
 
-<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
-postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
-</blockquote>
-<p><i>Change Class condition_variable_any 30.5.2 [thread.condition.condvarany], 
-paragraph 10, as indicated:</i></p>
-<blockquote>
 
-<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
-postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
-</blockquote>
-<p><i>Change Class condition_variable_any 30.5.2 [thread.condition.condvarany], 
-paragraph 16, as indicated:</i></p>
 <blockquote>
-
-<p><i>Throws:</i> <code>std::system_error</code> when <del>the returned value, effects, or 
-postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
+Move to Tentatively Ready, removing bullet 3 from the proposed
+resolution but keeping the other two bullets.
 </blockquote>
 
-<p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been 
-applied to the working paper, change Change 30.5.1 [thread.condition.condvar] as 
-indicated:</i></p>
-<blockquote>
-<pre>template &lt;class Rep, class Period&gt; 
-bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
-              const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);</pre>
-<pre>...</pre>
-
-<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
-postcondition cannot be achieved</del> <ins>an exception is required ([thread.req.exception])</ins>.</p>
-</blockquote>
 
-<p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been 
-applied to the working paper, change Change 30.5.1 [thread.condition.condvar] as 
-indicated:</i></p>
-<blockquote>
-<pre>template &lt;class Rep, class Period, class Predicate&gt; 
-  bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
-                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, 
-                Predicate pred);</pre>
-  <pre>...</pre>
 
-<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
-postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
-</blockquote>
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>
+In 30.6.10 [futures.task], immediately after the definition of class
+template packaged_task add:
+</p>
+<blockquote><pre><ins>
+template&lt;class R, class... Argtypes&gt;
+void swap(packaged_task&lt;R(ArgTypes...)&gt;&amp;, packaged_task&lt;R(ArgTypes...)&gt;&amp;);
+</ins>
+</pre></blockquote>
+</li>
+</ol>
 
-<p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been 
-applied to the working paper, change 30.5.2 [thread.condition.condvarany] as 
-indicated:</i></p>
-<blockquote>
-<pre>template &lt;class Lock, class Rep, class Period&gt; 
-  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);</pre>
-  <pre>...</pre>
+<ol start="4">
 
-<p><i>Throws:</i> <code>std::system_error</code> when <del>the returned value, effects or 
-postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
-</blockquote>
+<li>
+<p>
+At the end of 30.6.10 [futures.task] (after p. 20), add add the following
+prototype description:
+</p>
 
-<p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been 
-applied to the working paper, change 30.5.2 [thread.condition.condvarany] as 
-indicated:</i></p>
+<blockquote><pre><ins>
+template&lt;class R, class... Argtypes&gt;
+void swap(packaged_task&lt;R(ArgTypes...)&gt;&amp; x, packaged_task&lt;R(ArgTypes...)&gt;&amp; y);
+</ins></pre>
 <blockquote>
-<pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt; 
-  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);</pre>
-  <pre>...</pre>
-
-<p><i>Throws:</i> <code>std::system_error</code> when <del>the returned value, effects or 
-postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
+<p><ins>
+<i>Effects:</i> <tt>x.swap(y)</tt>
+</ins></p>
+<p><ins>
+<i>Throws:</i> Nothing.
+</ins></p>
 </blockquote>
-
+</blockquote>
+</li>
+</ol>
 
 
 
 
 
 <hr>
-<h3><a name="963"></a>963. Various threading bugs #13</h3>
-<p><b>Section:</b> 30.3.1.5 [thread.thread.member] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-03-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.member">active issues</a> in [thread.thread.member].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.member">issues</a> in [thread.thread.member].</p>
+<h3><a name="1093"></a>1093. Multiple definitions for random_shuffle algorithm</h3>
+<p><b>Section:</b> 25.3.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.random.shuffle">issues</a> in [alg.random.shuffle].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
+
 <p>
-30.3.1.5 [thread.thread.member]:  <tt>thread::detach</tt> is required to
-throw an exception if the thread is "not a detachable thread".
-"Detachable" is never defined.
+There are a couple of issues with the declaration of the <tt>random_shuffle</tt>
+algorithm accepting a random number engine.
 </p>
 
-<p><i>[
-Howard adds:
-]</i></p>
-
-
-<blockquote>
-Due to a mistake on my part, 3 proposed resolutions appeared at approximately
-the same time.  They are all three noted below in the discussion.
-</blockquote>
+<ol type="i">
+<li>
+The Iterators must be shuffle iterators, yet this requirement is missing.
+</li>
+<li>
+The <tt>RandomNumberEngine</tt> concept is now provided by the random number
+library
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">n2836</a>)
+and the placeholder should be removed.
+</li>
+</ol>
 
 <p><i>[
-Summit, proposed resolution:
+2009-05-02 Daniel adds:
 ]</i></p>
 
 
 <blockquote>
 <p>
-In 30.3.1.5 [thread.thread.member] change:
+this issue completes adding necessary requirement to the
+third new <tt>random_shuffle</tt> overload. The current suggestion is:
 </p>
 
-<blockquote><pre>void detach();
-</pre>
-<blockquote>
-<p>...</p>
-<p>-14- <i>Error conditions:</i></p>
-<ul>
-<li><tt>no_such_process</tt> --  <ins>if the thread is</ins> not <del>a</del> valid<del> thread</del>.</li>
-<li><tt>invalid_argument</tt> -- <ins>if the thread is</ins> not <del>a detachable</del> <ins>joinable</ins><del> thread</del>.</li>
-</ul>
-</blockquote>
-
-</blockquote>
-
-</blockquote>
-
-<p><i>[
-Post Summit, Jonathan Wakely adds:
-]</i></p>
-
+<blockquote><pre>template&lt;RandomAccessIterator Iter, UniformRandomNumberGenerator Rand&gt;
+requires ShuffleIterator&lt;Iter&gt;
+void random_shuffle(Iter first, Iter last, Rand&amp;&amp; g);
+</pre></blockquote>
 
-<blockquote>
 <p>
-A <tt>thread</tt> is detachable if it is joinable. As we've defined joinable,
-we can just use that.
+IMO this is still insufficient and I suggest to add the requirement
 </p>
+<blockquote><pre>Convertible&lt;Rand::result_type, Iter::difference_type&gt;
+</pre></blockquote>
 <p>
-This corresponds to the pthreads specification, where pthread_detach
-fails if the thread is not joinable:
+to the list (as the two other overloads already have).
 </p>
-<blockquote>
-EINVAL: The  implementation  has  detected  that  the value specified by
-thread does not refer to a joinable thread.
-</blockquote>
+
 <p>
-Jonathan recommends this proposed wording:
+Rationale:
 </p>
+
 <blockquote>
 <p>
-In 30.3.1.5 [thread.thread.member] change:
+Its true that this third overload is somewhat different from the remaining
+two. Nevertheless we know from <tt>UniformRandomNumberGenerator</tt>, that
+it's <tt>result_type</tt> is an integral type and that it satisfies
+<tt>UnsignedIntegralLike&lt;result_type&gt;</tt>.
+</p>
+<p>
+To realize it's designated task, the algorithm has to invoke the
+<tt>Callable</tt> aspect of <tt>g</tt> and needs to perform some algebra involving
+it's <tt>min()/max()</tt> limits to compute another index value that
+at this point is converted into <tt>Iter::difference_type</tt>. This is so,
+because 24.2.5 [random.access.iterators] uses this type as argument
+of it's algebraic operators. Alternatively consider the equivalent
+iterator algorithms in 24.4.4 [iterator.operations] with the same result.
+</p>
+<p>
+This argument leads us to the conclusion that we also need
+<tt>Convertible&lt;Rand::result_type, Iter::difference_type&gt;</tt> here.
 </p>
-
-<blockquote><pre>void detach();
-</pre>
-<blockquote>
-<p>...</p>
-<p>-14- <i>Error conditions:</i></p>
-<ul>
-<li>...</li>
-<li><tt>invalid_argument</tt> -- not a <del>detachable</del> <ins>joinable</ins> thread.</li>
-</ul>
 </blockquote>
 
 </blockquote>
-</blockquote>
-</blockquote>
 
 <p><i>[
-Post Summit, Anthony Williams adds:
+Batavia (2009-05):
 ]</i></p>
 
-
 <blockquote>
 <p>
-This is covered by the precondition that <tt>joinable()</tt> be <tt>true</tt>.
+Alisdair notes that point (ii) has already been addressed.
 </p>
 <p>
-Anthony recommends this proposed wording:
+We agree with the proposed resolution to point (i)
+with Daniel's added requirement.
 </p>
-
-<blockquote>
 <p>
-In 30.3.1.5 [thread.thread.member] change:
+Move to Review.
 </p>
+</blockquote>
+
+<p><i>[
+2009-06-05 Daniel updated proposed wording as recommended in Batavia.
+]</i></p>
+
+
+<p><i>[
+2009-07-28 Alisdair adds:
+]</i></p>
+
 
-<blockquote><pre>void detach();
-</pre>
 <blockquote>
-<p>...</p>
-<p>-14- <i>Error conditions:</i></p>
-<ul>
-<li>...</li>
-<li><del><tt>invalid_argument</tt> -- not a detachable thread.</del></li>
-</ul>
+Revert to Open, with a note there is consensus on direction but the
+wording needs updating to reflect removal of concepts.
 </blockquote>
 
-</blockquote>
+<p><i>[
+2009-10 post-Santa Cruz:
+]</i></p>
 
-</blockquote>
 
+<blockquote>
+Leave Open, Walter to work on it.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
+<p>
+Change in  [algorithms.syn] and 25.3.12 [alg.random.shuffle]:
+</p>
+
+<blockquote><pre><del>concept UniformRandomNumberGenerator&lt;typename Rand&gt; { }</del>
+template&lt;RandomAccessIterator Iter, UniformRandomNumberGenerator Rand&gt;
+  <ins>requires ShuffleIterator&lt;Iter&gt; &amp;&amp;
+  Convertible&lt;Rand::result_type, Iter::difference_type&gt;</ins>
+  void random_shuffle(Iter first, Iter last, Rand&amp;&amp; g);
+</pre></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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-03-22</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1094"></a>1094. Response to JP 65 and JP 66</h3>
+<p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-24  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
+<p><b>Addresses JP 65 and JP 66</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?
+Switch from "unspecified-bool-type" to "explicit operator bool() const". 
+</p>
+
+<p>
+Replace <tt>operator unspecified-bool-type() const;</tt>" with <tt>explicit operator bool() const;</tt>
 </p>
 
 <p><i>[
-Summit:
+Batavia (2009-05):
 ]</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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>.
+We agree with the proposed resolution.
+Move to Review.
 </blockquote>
 
 <p><i>[
-Post Summit Howard adds:
+2009 Santa Cruz:
 ]</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.
+Moved to Ready.
 </blockquote>
 
 
+
 <p><b>Proposed resolution:</b></p>
+<p>
+Change the synopis in 27.5.4 [ios]:
+</p>
+
+<blockquote><pre><ins>explicit</ins> operator <del><i>unspecified-bool-type</i></del> <ins>bool</ins>() const;
+</pre></blockquote>
+
+<p>
+Change 27.5.4.3 [iostate.flags]:
+</p>
+
+<blockquote><pre><ins>explicit</ins> operator <del><i>unspecified-bool-type</i></del> <ins>bool</ins>() const;
+</pre>
+
+<blockquote>
+<p>
+-1- <i>Returns:</i> <ins><tt>!fail()</tt></ins> <del>If <tt>fail()</tt> then a value that will evaluate
+false in a boolean context; otherwise a value that will evaluate true in
+a boolean context. The value type returned shall not be convertible to
+int.</del>
+</p>
+<p>
+<del>[<i>Note:</i> This conversion can be used in contexts where a bool is expected
+(e.g., an <tt>if</tt> condition); however, implicit conversions (e.g.,
+to <tt>int</tt>) that can occur with <tt>bool</tt> are not allowed,
+eliminating some sources of user error. One possible implementation
+choice for this type is pointer-to-member. <i>-- end note</i>]</del>
+</p>
+</blockquote>
+</blockquote>
+
+
 
 
 
 
 
 <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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-08-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1095"></a>1095. <i>Shared objects and the library</i> wording unclear</h3>
+<p><b>Section:</b> 17.6.3.10 [res.on.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-03-27  <b>Last modified:</b> 2009-10-21</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</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?
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2775.htm">N2775</a>,
+<i>Small library thread-safety revisions</i>, among other changes, removed a note from
+17.6.3.10 [res.on.objects] that read:
 </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.
+[<i>Note:</i> This prohibition against concurrent non-const access means that
+modifying an object of a standard library type shared between threads
+without using a locking mechanism may result in a data race. <i>--end note</i>.]
 </blockquote>
 
+<p>
+That resulted in wording which is technically correct but can only be
+understood by reading the lengthy and complex 17.6.4.8 [res.on.data.races]
+Data race avoidance. This has the effect of making
+17.6.3.10 [res.on.objects] unclear, and has already resulted in a query
+to the LWG reflector. See c++std-lib-23194.
+</p>
+
 <p><i>[
-2009-08-01 Howard provides wording.
+Batavia (2009-05):
 ]</i></p>
 
-
 <blockquote>
 <p>
-The proposed wording is inspired by the POSIX spec which says:
+The proposed wording seems to need a bit of tweaking
+("really bad idea" isn't quite up to standardese).
+We would like feedback
+as to whether the original Note's removal was intentional.
 </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.
+Change the phrase "is a really bad idea"
+to "risks undefined behavior" and
+move to Review status.
 </p>
 </blockquote>
 
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
+
+<blockquote>
+Note: Change to read: "Modifying...", Delete 'thus', move to Ready
+</blockquote>
+
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change 30.5.1 [thread.condition.condvar] p12, p19 and
-30.5.2 [thread.condition.condvarany] p10, p16:
+Change 17.6.3.10 [res.on.objects] as indicated:
 </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>
+<p>
+The behavior of a program is undefined if calls to standard library
+functions from different threads may introduce a data race. The
+conditions under which this may occur are specified in 17.6.4.7.
+</p>
+<p><ins>
+[<i>Note:</i> Modifying an object of a standard library type shared between
+threads risks undefined behavior unless objects of the type are explicitly
+specified as being sharable without data races or the user supplies a
+locking mechanism. <i>--end note</i>]
+</ins></p>
 </blockquote>
 
 
@@ -20738,176 +17312,90 @@ cannot be achieved.</del>
 
 
 <hr>
-<h3><a name="967"></a>967. Various threading bugs #17</h3>
-<p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-06-27</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="1097"></a>1097. #define __STDCPP_THREADS</h3>
+<p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-04-03  <b>Last modified:</b> 2009-10-21</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
+<p><b>Addresses DE 18</b></p>
+
 <p>
-the error handling for the constructor for <tt>condition_variable</tt>
-distinguishes lack of memory from lack of other resources, but the error
-handling for the thread constructor does not. Is this difference
-intentional?
+Freestanding implementations do not (necessarily) have
+  support for multiple threads (see 1.10 [intro.multithread]).
+  Applications and libraries may want to optimize for the
+  absence of threads.  I therefore propose a preprocessor
+  macro to indicate whether multiple threads can occur.
 </p>
 
-<p><i>[
-Beman has volunteered to provide proposed wording.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p><i>Change Exceptions 30.2.2 [thread.req.exception] as indicated:</i></p>
-<blockquote>
-<p>Some functions described in this Clause are 
-specified to throw exceptions of type <code>system_error</code> (19.5.5). Such exceptions 
-shall be thrown if any of the <i>Error conditions</i> are detected or a call to an operating system or other underlying API 
-results in an error that prevents the library function from meeting its specifications.
-<ins><i>[Note:</i> See 17.6.4.10 [res.on.exception.handling] for exceptions thrown to report 
-storage allocation failures. <i>--end 
-note]</i></ins></p>
-
-</blockquote>
-
-<p><span style="font-style: italic;">Change Mutex requirements 30.4.1 [thread.mutex.requirements], 
-paragraph 4, as indicated:</span></p>
-<blockquote>
-
-<p><i>Error conditions:</i></p>
-  <blockquote>
-
-<ul>
-<li><del> <code>not_enough_memory</code> &#8212; if there is not enough memory to construct 
-the mutex object.</del></li>
-
-<li><code>resource_unavailable_try_again</code> &#8212; if any native handle type 
-manipulated is not available.</li>
-
-<li><code>operation_not_permitted</code> &#8212; if the thread does not have the 
-necessary permission to change the state of the mutex object.</li>
-
-<li><code>device_or_resource_busy</code> &#8212; if any native handle type 
-manipulated is already locked.</li>
-
-<li><code>invalid_argument</code> &#8212; if any native handle type manipulated as 
-part of mutex construction is incorrect.</li>
-</ul>
-  </blockquote>
-</blockquote>
-
-<p><span style="font-style: italic;">Change Class condition_variable 30.5.1 [thread.condition.condvar], 
-default constructor, as indicated:</span></p>
-<blockquote>
-  <p><code>condition_variable();</code></p>
-  <blockquote>
-    <p><i>Effects:</i> Constructs an object of type <code>condition_variable</code>.</p>
-    <p><ins><i>Throws:</i> <code>std::system_error</code> when an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
-    <p><i>Error conditions:</i></p>
-    <blockquote>
-    <ul>
-      <li><del><code>not_enough_memory</code> &amp;msash; if a memory limitation prevents 
-      initialization.</del></li>
-      <li> <code>resource_unavailable_try_again</code> &amp;msash; if some non-memory 
-      resource limitation prevents initialization.</li>
-      <li> <code>device_or_resource_busy</code> &amp;msash; if attempting to initialize a 
-      previously-initialized but as of yet undestroyed <code>condition_variable</code>.</li>
-    </ul>
-    </blockquote>
-  </blockquote>
-</blockquote>
-
-
-
+<p>
+There is ample prior implementation experience for this
+  feature with various spellings of the macro name.  For
+  example, gcc implicitly defines <tt>_REENTRANT</tt>
+  if multi-threading support is selected on the compiler
+  command-line.
+</p>
 
+<p>
+While this is submitted as a library issue, it may be more
+  appropriate to add the macro in 16.8 cpp.predefined in the
+  core language.
+</p>
 
-<hr>
-<h3><a name="968"></a>968. Various threading bugs #18</h3>
-<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-06-27</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-30.4.1 [thread.mutex.requirements]: several functions are
-required to throw exceptions "if the thread does not have the necessary
-permission ...". "The necessary permission" is not defined.
+See also
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html">N2693</a>.
 </p>
 
 <p><i>[
-Summit:
+Batavia (2009-05):
 ]</i></p>
 
 <blockquote>
-Move to open.
+<p>
+We agree with the issue, and believe it is properly a library issue.
+</p>
+<p>
+We prefer that the macro be conditionally defined
+as part of the <tt>&lt;thread&gt;</tt> header.
+</p>
+<p>
+Move to Review.
+</p>
 </blockquote>
 
-
 <p><i>[
-Beman has volunteered to provide proposed wording.
+2009-10 Santa Cruz:
 ]</i></p>
 
 
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><i>Change Exceptions 30.2.2 [thread.req.exception] as indicated:</i></p>
-<blockquote>
-<p>Some functions described in this Clause are 
-specified to throw exceptions of type <code>system_error</code> (19.5.5). Such exceptions 
-shall be thrown if any of the <i>Error conditions</i> are detected or a call to an operating system or other underlying API 
-results in an error that prevents the library function from meeting its specifications.
-<i>[Note:</i> See 17.6.4.10 [res.on.exception.handling] for exceptions thrown to report 
-storage allocation failures. <i>&#8212;end 
-note]</i></p>
-
-<p><ins><i>[Example:</i></ins></p>
-
 <blockquote>
-
-<p><ins>A function in this clause that is specified to throw exceptions of type <code>
-system_error</code> and specifies <i>Error conditions</i> that include <code>
-operation_not_permitted</code> for a thread that does not have the privilege to 
-perform the operation. During the execution of this function, an <code>errno</code> 
-of <code>EPERM</code> is reported by a POSIX API call used by the 
-implementation. Since POSIX specifies an <code>errno</code> of <code>EPERM</code> 
-when "the caller does not have the privilege to perform the operation", 
-the implementation maps <code>EPERM</code>&nbsp; to an <code>error_condition</code> 
-of <code>operation_not_permitted</code> (19.5 [syserr]) and an exception of type <code>
-system_error</code> is thrown. </ins></p>
-
+Move to Ready.
 </blockquote>
 
-<p><ins><i>&#8212;end example]</i></ins></p>
-
-<p><span style="font-style: italic;">Editorial note: For the sake of exposition, 
-the existing text above is shown with the changes proposed in issues 962 and 967. The 
-proposed additional example is independent of whether or not the 962 and 967 
-proposed resolutions are accepted.</span></p>
-
-</blockquote>
 
-<p><span style="font-style: italic;">Change Mutex requirements 30.4.1 [thread.mutex.requirements], 
-paragraph 4, as indicated:</span></p>
 
+<p><b>Proposed resolution:</b></p>
+<p>
+Insert a new subsection before 18.2 [support.types], entitled
+"Feature Macros" (support.macros):
+</p>
 <blockquote>
-
-<p>&#8212; <code>operation_not_permitted</code> &#8212; if the thread does not have the 
-<del>necessary permission to change the state of the mutex object</del> <ins>privilege to perform the operation</ins>.</p>
-
-</blockquote>
-
-<p><span style="font-style: italic;">Change Mutex requirements 30.4.1 [thread.mutex.requirements], 
-paragraph 12, as indicated:</span></p>
-
+<p>
+The standard library defines the following macros; no explicit
+prior inclusion of any header file is necessary.
+</p>
 <blockquote>
-
-<p>&#8212; <code>operation_not_permitted</code> &#8212; if the thread does not have the 
-<del>necessary permission to change the state of the mutex</del> <ins>privilege to perform the operation</ins>.</p>
-
+<dl>
+<dt><tt>__STDCPP_THREADS</tt></dt>
+<dd>
+The macro <tt>__STDCPP_THREADS</tt> shall be defined if and only if a
+    program can have more than one thread of execution (1.10 [intro.multithread]).
+If the macro is defined, it shall have the same
+    value as the predefined macro <tt>__cplusplus</tt> (16.8 [cpp.predefined]).
+</dd>
+</dl>
+</blockquote>
 </blockquote>
 
 
@@ -20916,558 +17404,442 @@ paragraph 12, as indicated:</span></p>
 
 
 <hr>
-<h3><a name="971"></a>971. Spurious diagnostic conversion function</h3>
-<p><b>Section:</b> 19.5.2.6 [syserr.errcode.nonmembers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
- <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-01-19  <b>Last modified:</b> 2009-07-22</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
+<h3><a name="1098"></a>1098. definition of get_pointer_safety()</h3>
+<p><b>Section:</b> 20.8.15.6 [util.dynamic.safety] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-04-03  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.dynamic.safety">issues</a> in [util.dynamic.safety].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
+<p><b>Addresses DE 18</b></p>
+
 <p>
-Anthony Williams raised the question in c++std-lib-22987 "why is there
-<tt>std::make_error_code(std::errc)</tt>? What purpose does this serve?"
+ In 20.8.15.6 [util.dynamic.safety], <tt>get_pointer_safety()</tt> purports
+to define behavior for
+ non-safely derived pointers (3.7.4.3 [basic.stc.dynamic.safety]).  However,
+ the cited core-language section in paragraph 4 specifies undefined behavior
+ for the use of such pointer values.  This seems an unfortunate near-contradiction.
+ I suggest to specify the term <i>relaxed pointer safety</i> in
+ the core language section and refer to it from the library description.
+ This issue deals with the library part, the corresponding core issue (c++std-core-13940)
+ deals with the core modifications.
 </p>
+
 <p>
-The function <tt>make_error_code(errc e)</tt> is not required, since
-<tt>make_error_condition(errc e)</tt> is the function that is needed for <tt>errc</tt>
-conversions. <tt>make_error_code(errc e)</tt> appears to be a holdover from my
-initial confusion over the distinction between POSIX and operating
-systems that conform to the POSIX spec.
+See also
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html">N2693</a>.
 </p>
 
 <p><i>[
-Post Summit:
-]</i></p>
-
-
-<blockquote>
-Recommend Review.
-</blockquote>
-
-<p><i>[
 Batavia (2009-05):
 ]</i></p>
 
 <blockquote>
-The designer of the facility (Christopher Kohlhoff)
-strongly disagrees that there is an issue here,
-and especially disagrees with the proposed resolution.
-Bill would prefer to be conservative and not apply this proposed resolution.
-Move to Open, and recommend strong consideration for NAD status.
+<p>
+We recommend if this issue is to be moved,
+the issue be moved concurrently with the cited Core issue.
+</p>
+<p>
+We agree with the intent of the proposed resolution.
+We would like input from garbage collection specialists.
+</p>
+<p>
+Move to Open.
+</p>
 </blockquote>
 
 <p><i>[
-2009-05-21 Beman adds:
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-My mistake. Christopher and Bill are correct and the issue should be
-NAD. The function is needed by users.
+The core issue is 853 and is in Ready status.
 </blockquote>
 
-<p><i>[
-2009-07-21 Christopher Kohlhoff adds rationale for <tt>make_error_code</tt>:
-]</i></p>
-
-
-<blockquote>
-<p>
-Users (and indeed library implementers) may need to use the
-<tt>errc</tt> codes in portable code. For example:
-</p>
-
-<blockquote><pre>void do_foo(error_code&amp; ec)
-{
-#if defined(_WIN32)
-  // Windows implementation ...
-#elif defined(linux)
-  // Linux implementation ...
-#else
-  // do_foo not supported on this platform
-  ec = make_error_code(errc::not_supported);
-#endif
-}
-</pre></blockquote>
-</blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change System error support 19.5 [syserr], Header <tt>&lt;system_error&gt;</tt>
-synopsis, as indicated:
+In 20.8.15.6 [util.dynamic.safety] p16, replace the description of
+<tt>get_pointer_safety()</tt> with:
 </p>
 
-<blockquote><pre><del>error_code make_error_code(errc e);</del>
-error_condition make_error_condition(errc e);
-</pre></blockquote>
-
+<blockquote>
 <p>
-Delete from Class error_code non-member functions
-19.5.2.6 [syserr.errcode.nonmembers]:
+<tt>pointer_safety get_pointer_safety();</tt>
 </p>
-
-<blockquote><pre><del>error_code make_error_code(errc e);</del>
-</pre>
 <blockquote>
-<del><i>Returns:</i> <tt>error_code(static_cast&lt;int&gt;(e),
-generic_category)</tt>.</del>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="974"></a>974. <tt>duration&lt;double&gt;</tt> should not implicitly convert to <tt>duration&lt;int&gt;</tt></h3>
-<p><b>Section:</b> 20.9.3.1 [time.duration.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-21  <b>Last modified:</b> 2009-08-01</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-The following code should not compile because it involves implicit truncation
-errors (against the design philosophy of the <tt>duration</tt> library).
-</p>
-
-<blockquote><pre>duration&lt;double&gt; d(3.5);
-duration&lt;int&gt; i = d;  <font color="#c80000">// implicit truncation, should not compile</font>
-</pre></blockquote>
-
-<p>
-This intent was codified in the example implementation which drove this proposal
-but I failed to accurately translate the code into the specification in this
-regard.
+<del><i>Returns:</i> an enumeration value indicating the implementation's treatment
+of pointers that are not safely derived (3.7.4.3). Returns
+<tt>pointer_safety::relaxed</tt> if pointers that are not safely derived will be
+treated the same as pointers that are safely derived for the duration of
+the program. Returns <tt>pointer_safety::preferred</tt> if pointers that are not
+safely derived will be treated the same as pointers that are safely
+derived for the duration of the program but allows the implementation to
+hint that it could be desirable to avoid dereferencing pointers that are
+not safely derived as described. [<i>Example:</i> <tt>pointer_safety::preferred</tt>
+might be returned to detect if a leak detector is running to avoid
+spurious leak reports. -- <i>end note</i>] Returns <tt>pointer_safety::strict</tt> if
+pointers that are not safely derived might be treated differently than
+pointers that are safely derived.</del>
 </p>
+<p><ins>
+<i>Returns:</i> Returns <tt>pointer_safety::strict</tt> if the implementation has
+   strict pointer safety (3.7.4.3 [basic.stc.dynamic.safety]). It is
+   implementation-defined whether <tt>get_pointer_safety</tt> returns
+   <tt>pointer_safety::relaxed</tt> or <tt>pointer_safety::preferred</tt> if the
+   implementation has relaxed pointer safety
+   (3.7.4.3 [basic.stc.dynamic.safety]).<sup>Footnote</sup>
+</ins></p>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<p><ins>
+<i>Throws:</i> nothing
+</ins></p>
 
-<blockquote>
-<p>
-We agree with the proposed resolution.
-</p>
-<p>
-Move to Tentatively Ready.
+<p><ins>
+Footnote) <tt>pointer_safety::preferred</tt> might be returned to indicate to the
+   program that a leak detector is running so that the program can avoid
+   spurious leak reports.
+</ins>
 </p>
-</blockquote>
-
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
 
-
-<blockquote>
-Moved from Tentatively Ready to Open only because the wording needs to be
-improved for enable_if type constraining, possibly following Robert's
-formula.
 </blockquote>
-
-<p><i>[
-2009-08-01 Howard adds:
-]</i></p>
+</blockquote>
 
 
-<blockquote>
-Addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a>.
-</blockquote>
 
 
 
-<p><b>Proposed resolution:</b></p>
+<hr>
+<h3><a name="1099"></a>1099. Various issues</h3>
+<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-21  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Change 20.9.3.1 [time.duration.cons], p4:
+Notes
 </p>
-
 <blockquote>
-<pre>template &lt;class Rep2, class Period2&gt; 
-  duration(const duration&lt;Rep2, Period2&gt;&amp; d);
-</pre>
+<p>
+[2009-03-21 Sat] p. 535 at the top we need MoveConstructible V1,
+MoveConstructible V2 (where V1,V2 are defined on 539).  Also make_tuple
+on 550
+</p>
+
 <blockquote>
--4- <i>Requires:</i> <tt>treat_as_floating_point&lt;rep&gt;::value</tt>
-shall be <tt>true</tt> or <ins>both</ins> <tt>ratio_divide&lt;Period2,
-period&gt;::type::den</tt> shall be 1
-<ins>and <tt>treat_as_floating_point&lt;Rep2&gt;::value</tt>
-shall be <tt>false</tt></ins>.
-Diagnostic required.
-[<i>Note:</i> This requirement prevents implicit truncation error when
-converting between integral-based <tt>duration</tt> types. Such a
-construction could easily lead to confusion about the value of the
-<tt>duration</tt>. -- <i>end note</i>]
-</blockquote>
-</blockquote>
+<p>
+CD-1 reads:
+</p>
 
+<blockquote><pre>template &lt;MoveConstructible T1, MoveConstructible T2&gt; 
+pair&lt;V1, V2&gt; make_pair(T1&amp;&amp;, T2&amp;&amp;); 
+</pre></blockquote>
 
+<p>
+Actually I'm guessing we need something like <tt>MoveConstructible&lt;V1,T1&gt;</tt>,
+i.e. "<tt>V1</tt> can be constructed from an rvalue of type <tt>T1</tt>."
+</p>
 
+<p>
+Ditto for <tt>make_tuple</tt>
+</p>
+</blockquote>
 
+<p>
+[2009-03-21 Sat] p1183 thread ctor, and in general, we need a way to
+talk about "copiable from generalized rvalue ref argument" for cases
+where we're going to forward and copy.  
+</p>
+<blockquote>
+<p>
+   This issue may well be quite large.  Language in para 4 about "if
+   an lvalue" is wrong because types aren't expressions.
+</p>
 
-<hr>
-<h3><a name="976"></a>976. Class template std::stack should be movable</h3>
-<p><b>Section:</b> 23.3.5.3.1 [stack.defn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-02-01  <b>Last modified:</b> 2009-07-14</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<blockquote>
 <p>
-The synopsis given in 23.3.5.3.1 [stack.defn] does not show up
+Maybe we should define the term "move" so we can just say in the
+effects, "<tt>f</tt> is moved into the newly-created thread" or something, and
+agree (and ideally document) that saying "<tt>f</tt> is moved" implies 
 </p>
 
-<blockquote><pre>requires MoveConstructible&lt;Cont&gt; stack(stack&amp;&amp;);
-requires MoveAssignable&lt;Cont&gt; stack&amp; operator=(stack&amp;&amp;);
+<blockquote><pre>F x(move(f))
 </pre></blockquote>
 
 <p>
-although the other container adaptors do provide corresponding
-members.
+is required to work.  That would cover both ctors at once.
 </p>
+</blockquote>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<p>
+   p1199, call_once has all the same issues.
+</p>
+</blockquote>
+<p>
+[2009-03-21 Sat] p869 InputIterator pointer type should not be required
+to be convertible to const value_type*, rather it needs to have a
+operator-&gt; of its own that can be used for the value type.
+</p>
 
 <blockquote>
+This one is serious and unrelated to the move issue.
+</blockquote>
+
 <p>
-We agree with the proposed resolution.
+[2009-03-21 Sat] p818 stack has the same problem with default ctor.
 </p>
 <p>
-Move to Tentatively Ready.
+[2009-03-21 Sat] p816 priority_queue has the same sorts of problems as queue, only more so
+</p>
+<blockquote><pre>   requires MoveConstructible&lt;Cont&gt; 
+     explicit priority_queue(const Compare&amp; x = Compare(), Cont&amp;&amp; = Cont()); 
+</pre>
+<p>
+   Don't require MoveConstructible when default constructing Cont.
+   Also missing semantics for move ctor.
 </p>
 </blockquote>
+<p>
+ [2009-03-21 Sat] Why are Allocators required to be CopyConstructible as
+ opposed to MoveConstructible?
+</p>
+<p>
+ [2009-03-21 Sat] p813 queue needs a separate default ctor (Cont needn't
+ be MoveConstructible).  No documented semantics for move c'tor.  Or
+ *any* of its 7 ctors!
+</p>
+<p>
+ [2009-03-21 Sat] std::array should have constructors for C++0x,
+ consequently must consider move construction.
+</p>
 
 <p><i>[
-2009-07 Frankfurt
+2009-05-01 Daniel adds:
 ]</i></p>
 
 
 <blockquote>
-Moved from Tentatively Ready to Open only because the wording needs to be
-tweaked for concepts removal.
+This could be done as part of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1035">1035</a>, which already handles
+deviation of <tt>std::array</tt> from container tables.
 </blockquote>
 
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-In the class stack synopsis of 23.3.5.3.1 [stack.defn] insert:
+ [2009-03-21 Sat] p622 all messed up.
 </p>
-
-<blockquote><pre>template &lt;ObjectType T, StackLikeContainer Cont = deque&lt;T&gt; &gt; 
-  requires SameType&lt;Cont::value_type, T&gt; 
-        &amp;&amp; NothrowDestructible&lt;Cont&gt; 
-class stack { 
-public: 
-   ...
-   requires CopyConstructible&lt;Cont&gt; explicit stack(const Cont&amp;); 
-   requires MoveConstructible&lt;Cont&gt; explicit stack(Cont&amp;&amp; = Cont()); 
-   <ins>requires MoveConstructible&lt;Cont&gt; stack(stack&amp;&amp;);</ins>
-   <ins>requires MoveAssignable&lt;Cont&gt; stack&amp; operator=(stack&amp;&amp;);</ins>
-   template &lt;class Alloc&gt; 
-     requires Constructible&lt;Cont, const Alloc&amp;&gt; 
-     explicit stack(const Alloc&amp;);
-   ...
-};
-</pre></blockquote>
-
+<blockquote>
 <p>
-[Remark: This change should be done in sync with the resolution of
-paper
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2819.html">N2819</a>]
+   para 8 "implementation-defined" is the wrong term; should be "see
+   below" or something.  
+</p>
+<p>
+   para 12 "will be selected" doesn't make any sense because we're not
+   talking about actual arg types.
 </p>
-
-
-
-
-
-
-<hr>
-<h3><a name="977"></a>977. insert iterators inefficient for expensive to move types</h3>
-<p><b>Section:</b> 24.7 [insert.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-02  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#insert.iterators">active issues</a> in [insert.iterators].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#insert.iterators">issues</a> in [insert.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-The new concepts for the insert iterators mandate an extra copy when
-inserting an lvalue:
+   paras 9-13 need to be totally rewritten for concepts.
 </p>
-
-<blockquote><pre>requires CopyConstructible&lt;Cont::value_type&gt;
-  back_insert_iterator&lt;Cont&gt;&amp; 
-  operator=(const Cont::value_type&amp; value);
-</pre>
-<blockquote>
--1- <i>Effects:</i> <tt>push_back(*container, <b>Cont::value_type(</b>value<b>)</b>);</tt>
-</blockquote>
 </blockquote>
 
 <p>
-The reason is to convert <tt>value</tt> into an rvalue because the current
-<tt>BackInsertionContainer</tt> concept only handles <tt>push_back</tt>-ing
-rvalues:
+ [2009-03-21 Sat] Null pointer comparisons (p587) have all become
+ unconstrained.  Need to fix that
 </p>
-
-<blockquote><pre>concept BackInsertionContainer&lt;typename C&gt; : Container&lt;C&gt; { 
-  void push_back(C&amp;, value_type&amp;&amp;); 
-}
-</pre></blockquote>
-
 <p>
-Without the conversion of <tt>value</tt> to an rvalue, the assignment operator
-fails to concept check.
+ [2009-03-21 Sat] mem_fun_t etc. definition doesn't match declaration.
+  We think CopyConstructible is the right reqt.
 </p>
-
 <p>
-A solution is to modify the <tt>BackInsertionContainer</tt> concept so that
-the client can pass in the parameter type for <tt>push_back</tt> similar to
-what is already done for the <tt>OutputIterator</tt> concept:
+ make_pair needs Constructible&lt;V1, T1&amp;&amp;&gt; requirements!
 </p>
-
-<blockquote><pre>concept BackInsertionContainer&lt;typename C, typename Value = C::value_type&amp;&amp;&gt;
-  : Container&lt;C&gt; { 
-     void push_back(C&amp;, Value); 
-}
-</pre></blockquote>
-
 <p>
-This allows the assignment operator to be adjusted appropriately:
+ make_tuple needs something similar
 </p>
-
-<blockquote><pre>requires BackInsertionContainer&lt;Cont, Cont::value_type const&amp;&gt; &amp;&amp;
-         CopyConstructible&lt;Cont::value_type&gt;
-  back_insert_iterator&lt;Cont&gt;&amp; 
-  operator=(const Cont::value_type&amp; value);
+<p>
+ tuple bug in synopsis:
+</p>
+<blockquote><pre>   template &lt;class... UTypes&gt;
+   requires Constructible&lt;Types, const UTypes&amp;&gt;...
+   template &lt;class... UTypes&gt;
+   requires Constructible&lt;Types, RvalueOf&lt;UTypes&gt;::type&gt;...
 </pre>
-<blockquote>
--1- <i>Effects:</i> <tt>push_back(*container, value);</tt>
-</blockquote>
+<p>
+   Note: removal of MoveConstructible requirements in std::function makes
+   these routines unconstrained!
+</p>
 </blockquote>
 
 <p><i>[
-We may want to propagate this fix to other concepts such as <tt>StackLikeContainer</tt>.
+2009-05-02 Daniel adds:
 ]</i></p>
 
 
-<p><i>[
-Solution and wording collaborated on by Doug and Howard.
-]</i></p>
+<blockquote>
+This part of the issue is already covered by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>.
+</blockquote>
+
+<p>
+ these unique_ptr constructors are broken [ I think this is covered in "p622 all messed up" ]
+</p>
+<blockquote><pre> unique_ptr(pointer p, implementation-defined d);
+ unique_ptr(pointer p, implementation-defined d);
+</pre></blockquote>
+<p>
+ multimap range constructor should not have MoveConstructible&lt;value_type&gt; requirement.
+</p>
+<blockquote>
+   same with insert(..., P&amp;&amp;); multiset has the same issue, as do
+   unordered_multiset and unordered_multimap. Review these!
+</blockquote>
 
+</blockquote>
 
 <p><i>[
 Batavia (2009-05):
 ]</i></p>
 
 <blockquote>
-<p>
-Howard notes that "these operations behaved efficiently until concepts were added."
-</p>
-<p>
-Alisdair is uncertain that the proposed resolution is syntactically correct.
-</p>
-<p>
-Move to Open, and recommend the issue be deferred until after the next
-Committee Draft is issued.
-</p>
+Move to Open, pending proposed wording from Dave for further review.
 </blockquote>
 
+<p><i>[
+2009-10 post-Santa Cruz:
+]</i></p>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 23.2.6.1 [container.concepts.free]:
-</p>
 
 <blockquote>
-<pre>concept FrontInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
-    : Container&lt;C&gt; { 
-  void push_front(C&amp;, <del>value_type&amp;&amp;</del> <ins>Value</ins>); 
-
-  axiom FrontInsertion(C c, <del>value_type</del> <ins>Value</ins> x) { 
-    x == (push_front(c, x), front(c)); 
-  } 
-}
-</pre>
-
-<p>...</p>
-
-<pre>concept BackInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
-    : Container&lt;C&gt; { 
-  void push_back(C&amp;, <del>value_type&amp;&amp;</del> <ins>Value</ins>); 
-}
-</pre>
-
-<p>...</p>
-
-<pre>concept InsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
-    : Container&lt;C&gt; { 
-  iterator insert(C&amp;, const_iterator, <del>value_type&amp;&amp;</del> <ins>Value</ins>); 
+Tentatively NAD.  We are not sure what has been addressed and what hasn't.
+Recommend closing unless someone sorts this out into something more readable.
+</blockquote>
 
-  axiom Insertion(C c, const_iterator position, <del>value_type</del> <ins>Value</ins> v) { 
-    v == *insert(c, position, v); 
-  } 
-}
-</pre>
 
-</blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-Change 23.2.6.2 [container.concepts.member]:
 </p>
 
-<blockquote>
-<pre>auto concept MemberFrontInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
-    : MemberContainer&lt;C&gt; { 
-  void C::push_front(<del>value_type&amp;&amp;</del> <ins>Value</ins>); 
-
-  axiom MemberFrontInsertion(C c, <del>value_type</del> <ins>Value</ins> x) { 
-    x == (c.push_front(x), c.front()); 
-  } 
-}
-</pre>
-
-<p>...</p>
-
-<pre>auto concept MemberBackInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
-    : MemberContainer&lt;C&gt; { 
-  void C::push_back(<del>value_type&amp;&amp;</del> <ins>Value</ins>); 
-}
-</pre>
 
-<p>...</p>
 
-<pre>auto concept MemberInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
-    : MemberContainer&lt;C&gt; { 
-  iterator C::insert(const_iterator, <del>value_type&amp;&amp;</del> <ins>Value</ins>); 
 
-  axiom MemberInsertion(C c, const_iterator position, <del>value_type</del> <ins>Value</ins> v) { 
-    v == *c.insert(position, v); 
-  } 
-}
-</pre>
-</blockquote>
 
+<hr>
+<h3><a name="1100"></a>1100. <tt>auto_ptr</tt> to <tt>unique_ptr</tt> conversion</h3>
+<p><b>Section:</b> 20.8.14.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25  <b>Last modified:</b> 2009-10-21</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.ctor">active issues</a> in [unique.ptr.single.ctor].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Change 23.2.6.3 [container.concepts.maps]:
+Message c++std-lib-23182 led to a discussion in which several people
+expressed interest in being able to convert an <tt>auto_ptr</tt> to a
+<tt>unique_ptr</tt> without the need to call <tt>release</tt>.  Below is
+wording to accomplish this.
 </p>
 
-<blockquote>
-<pre>template &lt;MemberFrontInsertionContainer C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt; 
-concept_map FrontInsertionContainer&lt;C<ins>, Value</ins>&gt; { 
-  typedef Container&lt;C&gt;::value_type value_type;
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
-  void push_front(C&amp; c, <del>value_type&amp;&amp;</del> <ins>Value</ins> v) { c.push_front(static_cast&lt;<del>value_type&amp;&amp;</del> <ins>Value</ins>&gt;(v)); } 
-}
-</pre>
+<blockquote>
+<p>
+Pete believes it not a good idea to separate parts of a class's definition.
+Therefore, if we do this,
+it should be part of <tt>unique-ptr</tt>'s specification.
+</p>
+<p>
+Alisdair believes the lvalue overload may be not necessary.
+</p>
+<p>
+Marc believes it is more than just sugar,
+as it does ease the transition to <tt>unique-ptr</tt>.
+</p>
+<p>
+We agree with the resolution as presented.
+Move to Tentatively Ready.
+</p>
+</blockquote>
 
-<p>...</p>
+<p><i>[
+2009-07 Frankfurt
+]</i></p>
 
-<pre>template &lt;MemberBackInsertionContainer C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt; 
-concept_map BackInsertionContainer&lt;C<ins>, Value</ins>&gt; { 
-  typedef Container&lt;C&gt;::value_type value_type;
 
-  void push_back(C&amp; c, <del>value_type&amp;&amp;</del> <ins>Value</ins> v) { c.push_back(static_cast&lt;<del>value_type&amp;&amp;</del> <ins>Value</ins>&gt;(v)); } 
-}
-</pre>
+<blockquote>
+Moved from Tentatively Ready to Open only because the wording needs to be
+tweaked for concepts removal.
+</blockquote>
 
-<p>...</p>
+<p><i>[
+2009-08-01 Howard deconceptifies wording:
+]</i></p>
 
-<pre>template &lt;MemberInsertionContainer C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt; 
-concept_map InsertionContainer&lt;C<ins>, Value</ins>&gt; { 
-  typedef Container&lt;C&gt;::value_type value_type;
-  Container&lt;C&gt;::iterator insert(C&amp; c, Container&lt;C&gt;::const_iterator i, <del>value_type&amp;&amp;</del> <ins>Value</ins> v) 
-  { return c.insert(i, static_cast&lt;<del>value_type&amp;&amp;</del> <ins>Value</ins>&gt;(v)); } 
-}
-</pre>
 
+<blockquote>
+I also moved the change from D.10 [depr.auto.ptr]
+to 20.8.14.2 [unique.ptr.single] per the Editor's request
+in Batavia (as long as I was making changes anyway).  Set back
+to Review.
 </blockquote>
 
-<p>
-Change 24.7.1 [back.insert.iterator]:
-</p>
-
-<blockquote><pre>template &lt;BackInsertionContainer Cont&gt; 
-class back_insert_iterator {
-  ...
-  requires <ins>BackInsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
-           <del>CopyConstructible&lt;Cont::value_type&gt;</del>
-    back_insert_iterator&lt;Cont&gt;&amp; 
-      operator=(const Cont::value_type&amp; value);
-  ...
-</pre></blockquote>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
-<p>
-Change 24.7.2.2 [back.insert.iter.op=]:
-</p>
 
 <blockquote>
-<pre>requires <ins>BackInsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
-         <del>CopyConstructible&lt;Cont::value_type&gt;</del>
-  back_insert_iterator&lt;Cont&gt;&amp; 
-    operator=(const Cont::value_type&amp; value);
-</pre>
-<blockquote>
--1- <i>Effects:</i> <tt>push_back(*container, <del>Cont::value_type(</del>value<del>)</del>);</tt>
-</blockquote>
+Move to Ready.
 </blockquote>
 
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-Change 24.7.3 [front.insert.iterator]:
+Add to 20.8.14.2 [unique.ptr.single]:
 </p>
 
-<blockquote><pre>template &lt;FrontInsertionContainer Cont&gt; 
-class front_insert_iterator {
-  ...
-  requires <ins>FrontInsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
-           <del>CopyConstructible&lt;Cont::value_type&gt;</del>
-    front_insert_iterator&lt;Cont&gt;&amp; 
-      operator=(const Cont::value_type&amp; value);
-  ...
+<blockquote><pre>template &lt;class T, class D&gt;
+class unique_ptr
+{
+public:
+<ins>    template &lt;class U&gt;
+      unique_ptr(auto_ptr&lt;U&gt;&amp; u);
+    template &lt;class U&gt;
+      unique_ptr(auto_ptr&lt;U&gt;&amp;&amp; u);</ins>
+};
 </pre></blockquote>
 
 <p>
-Change 24.7.4.2 [front.insert.iter.op=]:
+Add to 20.8.14.2.1 [unique.ptr.single.ctor]:
 </p>
 
-<blockquote>
-<pre>requires <ins>FrontInsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
-         <del>CopyConstructible&lt;Cont::value_type&gt;</del>
-  front_insert_iterator&lt;Cont&gt;&amp; 
-    operator=(const Cont::value_type&amp; value);
+<blockquote><pre>template &lt;class U&gt;
+  unique_ptr(auto_ptr&lt;U&gt;&amp; u);
+template &lt;class U&gt;
+  unique_ptr(auto_ptr&lt;U&gt;&amp;&amp; u);
 </pre>
 <blockquote>
--1- <i>Effects:</i> <tt>push_front(*container, <del>Cont::value_type(</del>value<del>)</del>);</tt>
-</blockquote>
-</blockquote>
-
 <p>
-Change 24.7.5 [insert.iterator]:
+<i>Effects:</i> Constructs a <tt>unique_ptr</tt> with <tt>u.release()</tt>.
 </p>
 
-<blockquote><pre>template &lt;InsertionContainer Cont&gt; 
-class insert_iterator {
-  ...
-  requires <ins>InsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
-           <del>CopyConstructible&lt;Cont::value_type&gt;</del>
-    insert_iterator&lt;Cont&gt;&amp; 
-      operator=(const Cont::value_type&amp; value);
-  ...
-</pre></blockquote>
+<p>
+<i>Postconditions:</i> <tt>get() == </tt> the value <tt>u.get()</tt> had before
+the construciton, modulo any required offset adjustments resulting from the cast from
+<tt>U*</tt> to <tt>T*</tt>.  <tt>u.get() == nullptr</tt>.
+</p>
 
 <p>
-Change 24.7.6.2 [insert.iter.op=]:
+<i>Throws:</i> nothing.
 </p>
 
-<blockquote>
-<pre>requires <ins>InsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
-         <del>CopyConstructible&lt;Cont::value_type&gt;</del>
-  insert_iterator&lt;Cont&gt;&amp; 
-    operator=(const Cont::value_type&amp; value);
-</pre>
-<blockquote>
 <p>
--1- <i>Effects:</i>
+<i>Remarks:</i> <tt>U*</tt> shall be implicitly convertible to <tt>T*</tt> and
+<tt>D</tt> shall be the same type as <tt>default_delete&lt;T&gt;</tt>, else these
+constructors shall not participate in overload resolution.
 </p>
-<blockquote><pre>iter = insert(*container, iter, <del>Cont::value_type(</del>value<del>)</del>); 
-++iter;
-</pre></blockquote>
 </blockquote>
 </blockquote>
 
@@ -21477,21 +17849,26 @@ Change 24.7.6.2 [insert.iter.op=]:
 
 
 <hr>
-<h3><a name="978"></a>978. Hashing smart pointers</h3>
-<p><b>Section:</b> 20.7.17 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-02-02  <b>Last modified:</b> 2009-07-28</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1104"></a>1104. <tt>basic_ios::move</tt> should accept lvalues</h3>
+<p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-I don't see an open issue on supporting <tt>std::hash</tt> for smart pointers
-(<tt>unique_ptr</tt> and <tt>shared_ptr</tt> at least).
+With the rvalue reference changes in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
+<tt>basic_ios::move</tt> no longer has the most convenient signature:
 </p>
+
+<blockquote><pre>void move(basic_ios&amp;&amp; rhs);
+</pre></blockquote>
+
 <p>
-It seems reasonable to at least expect support for the smart
-pointers, especially as they support comparison for use in ordered
-associative containers.
+This signature should be changed to accept lvalues.  It does not need to be
+overloaded to accept rvalues.  This is a special case that only derived clients
+will see.  The generic <tt>move</tt> still needs to accept rvalues.
 </p>
 
 <p><i>[
@@ -21500,100 +17877,124 @@ Batavia (2009-05):
 
 <blockquote>
 <p>
-Howard points out that the client can always supply a custom hash function.
-</p>
-<p>
-Alisdair replies that the smart pointer classes are highly likely
-to be frequently used as hash keys.
-</p>
-<p>
-Bill would prefer to be conservative.
+Tom prefers, on general principles, to provide both overloads.
+Alisdair agrees.
 </p>
 <p>
-Alisdair mentions that this issue may also be viewed as a subissue or
-duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.
+Howard points out that there is no backward compatibility issue
+as this is new to C++0X.
 </p>
 <p>
-Move to Open, and recommend the issue be deferred until after the next
-Committee Draft is issued.
+We agree that both overloads should be provided,
+and Howard will provide the additional wording.
+Move to Open.
 </p>
 </blockquote>
 
 <p><i>[
-2009-05-31 Peter adds:
+2009-05-23 Howard adds:
 ]</i></p>
 
 
 <blockquote>
-<blockquote>
-Howard points out that the client can always supply a custom hash function.
-</blockquote>
-<p>
-Not entirely true. The client cannot supply the function that hashes the
-address of the control block (the equivalent of the old <tt>operator&lt;</tt>, now
-proudly carrying the awkward name of '<tt>owner_before</tt>'). Only the
-implementation can do that, not necessarily via specializing <tt>hash&lt;&gt;</tt>, of
-course.
-</p>
-<p>
-This hash function makes sense in certain situations for <tt>shared_ptr</tt>
-(when one needs to switch from <tt>set/map</tt> using ownership ordering to
-<tt>unordered_set/map</tt>) and is the only hash function that makes sense for
-<tt>weak_ptr</tt>.
-</p>
+Added overload, moved to Review.
 </blockquote>
 
 <p><i>[
-2009-07-28 Alisdair provides wording.
+2009 Santa Cruz:
 ]</i></p>
 
 
+<blockquote>
+Move to Ready.
+</blockquote>
+
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add the following declarations to the synopsis of <tt>&lt;memory&gt;</tt>
-in 20.8 [memory]
+Add a signature to the existing prototype in the synopsis of 27.5.4 [ios]
+and in 27.5.4.2 [basic.ios.members]:
 </p>
 
-<blockquote><pre>// 20.8.10.X hash support
-template &lt;class T&gt; struct hash;
-template &lt;class T, class D&gt; struct hash&lt;unique_ptr&lt;T,D&gt;&gt;;
-template &lt;class T&gt; struct hash&lt;shared_ptr&lt;T&gt;&gt;;
+<blockquote><pre><ins>void move(basic_ios&amp; rhs);</ins>
+void move(basic_ios&amp;&amp; rhs);
 </pre></blockquote>
 
+
+
+
+
+<hr>
+<h3><a name="1106"></a>1106. Multiple exceptions from connected <tt>shared_future::get()</tt>?</h3>
+<p><b>Section:</b> 30.6.7 [future.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Thomas J. Gritzan <b>Opened:</b> 2009-04-03  <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#future.shared_future">issues</a> in [future.shared_future].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Add a new subclause 20.8.10.X hash support
+It is not clear, if multiple threads are waiting in a 
+<tt>shared_future::get()</tt> call, if each will rethrow the stored exception.
 </p>
-
-<blockquote>
 <p>
-20.8.10.X hash support [util.smartptr.hash]
+Paragraph 9 reads: 
 </p>
-
-<pre>template &lt;class T, class D&gt; struct hash&lt;unique_ptr&lt;T,D&gt;&gt;;
-</pre>
-
 <blockquote>
-A partial specialization of the class template <tt>hash</tt> (20.7.17 [unord.hash]) shall be provided for instances of the
-<tt>unique_ptr</tt> template suitable for use as a key in unordered
-associative containers (23.5 [unord]) if and only if there is a
-<tt>hash</tt> specialization available for the type <tt>D::pointer</tt>.
-For an object <tt>p</tt> of type <tt>unqiue_ptr&lt;T,D&gt;</tt> the
-<tt>hash</tt> shall evaluate to the same value as <tt>hash&lt;typename
-D::pointer&gt;{}(p.get())</tt>.
+<i>Throws:</i> the stored exception, if an exception was stored and not 
+retrieved before.
 </blockquote>
+<p>
+The "not retrieved before" suggests that only one exception is thrown, 
+but one exception for each call to <tt>get()</tt> is needed, and multiple calls 
+to <tt>get()</tt> even on the same <tt>shared_future</tt> object seem to be allowed. 
+</p>
+<p>
+I suggest removing "and not retrieved before" from the Throws paragraph. 
+I recommend adding a note that explains that multiple calls on <tt>get()</tt> are 
+allowed, and each call would result in an exception if an exception was 
+stored. 
+</p>
 
-<pre>template &lt;class T&gt; struct hash&lt;shared_ptr&lt;T&gt;&gt;;
-</pre>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
 <blockquote>
-A partial specialization of the class template <tt>hash</tt> (20.7.17 [unord.hash])
-shall be provided for instances of the <tt>shared_ptr</tt> template
-suitable for use as a key in unordered associative containers
-(23.5 [unord]). For an object <tt>p</tt> of type <tt>shared_ptr&lt;T&gt;</tt>
-the <tt>hash</tt> shall evaluate
-to the same value as <tt>hash&lt;T*&gt;{}(p.get())</tt>.
+<p>
+We note there is a pending paper by Detlef
+on such <tt>future</tt>-related issues;
+we would like to wait for his paper before proceeding.
+</p>
+<p>
+Alisdair suggests we may want language to clarify that this
+<tt>get()</tt> function can be called from several threads
+with no need for explicit locking.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 30.6.7 [future.shared_future]:
+</p>
+
+<blockquote><pre>const R&amp; shared_future::get() const; 
+R&amp; shared_future&lt;R&amp;&gt;::get() const; 
+void shared_future&lt;void&gt;::get() const;
+</pre>
+<blockquote>
+<p>...</p>
+<p>
+-9- <i>Throws:</i> the stored exception, if an exception was stored<del> and not retrieved before</del>.
+<ins>
+[<i>Note:</i> Multiple calls on <tt>get()</tt> are 
+allowed, and each call would result in an exception if an exception was 
+stored. &#8212; <i>end note</i>]
+</ins>
+</p>
 </blockquote>
 </blockquote>
 
@@ -21601,34 +18002,69 @@ to the same value as <tt>hash&lt;T*&gt;{}(p.get())</tt>.
 
 
 
+
 <hr>
-<h3><a name="983"></a>983. <tt>unique_ptr</tt> reference deleters should not be moved from</h3>
-<p><b>Section:</b> 20.8.9.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-10  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single">active issues</a> in [unique.ptr.single].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="1108"></a>1108. thread.req.exception overly constrains implementations</h3>
+<p><b>Section:</b> 30.2.2 [thread.req.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Christopher Kohlhoff <b>Opened:</b> 2009-04-25  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Dave brought to my attention that when a <tt>unique_ptr</tt> has a non-const reference
-type deleter, move constructing from it, even when the <tt>unique_ptr</tt> containing
-the reference is an rvalue, could have surprising results:
+The current formulation of 30.2.2 [thread.req.exception]/2 reads:
 </p>
-
-<blockquote><pre>D d(some-state);
-unique_ptr&lt;A, D&amp;&gt; p(new A, d);
-unique_ptr&lt;A, D&gt; p2 = std::move(p);
-<font color="#c80000">// has d's state changed here?</font>
-</pre></blockquote>
-
+<blockquote>
+The error_category of the <tt>error_code</tt> reported by such an
+exception's <tt>code()</tt> member function is as specified in the error
+condition Clause.
+</blockquote>
 <p>
-I agree with him.  It is the <tt>unique_ptr</tt> that is the rvalue, not the
-deleter.  When the deleter is a reference type, the <tt>unique_ptr</tt> should
-respect the "lvalueness" of the deleter.
+This constraint on the code's associated <tt>error_categor</tt> means an
+implementation must perform a mapping from the system-generated
+error to a <tt>generic_category()</tt> error code. The problems with this
+include:
 </p>
 
+<ul>
+<li>
+The mapping is always performed, even if the resultant value is
+ never used.
+</li>
+<li>
 <p>
-Thanks Dave.
+The original error produced by the operating system is lost.
+</p>
+</li>
+</ul>
+<p>
+The latter was one of Peter Dimov's main objections (in a private
+email discussion) to the original <tt>error_code</tt>-only design, and led to
+the creation of <tt>error_condition</tt> in the first place. Specifically,
+<tt>error_code</tt> and <tt>error_condition</tt> are intended to perform the following
+roles:
+</p>
+<ul>
+<li>
+<tt>error_code</tt> holds the original error produced by the operating
+ system.
+</li>
+<li>
+<tt>error_condition</tt> and the generic category provide a set of well
+ known error constants that error codes may be tested against.
+</li>
+</ul>
+<p>
+Any mapping determining correspondence of the returned error code to
+the conditions listed in the error condition clause falls under the
+"latitude" granted to implementors in 19.5.1.5 [syserr.errcat.objects].
+(Although obviously their latitude is restricted a little by the
+need to match the right error condition when returning an error code
+from a library function.)
+</p>
+<p>
+It is important that this <tt>error_code/error_condition</tt> usage is done
+correctly for the thread library since it is likely to set the
+pattern for future TR libraries that interact with the operating
+system.
 </p>
 
 <p><i>[
@@ -21636,396 +18072,246 @@ Batavia (2009-05):
 ]</i></p>
 
 <blockquote>
-Seems correct, but complicated enough that we recommend moving to Review.
+Move to Open, and recommend the issue be deferred until after the next
+Committee Draft is issued.
+</blockquote>
+
+<p><i>[
+2009-10 post-Santa Cruz:
+]</i></p>
+
+
+<blockquote>
+Move to Tentatively Ready.
 </blockquote>
 
 
+
 <p><b>Proposed resolution:</b></p>
 <p>
-Change 20.8.9.2.1 [unique.ptr.single.ctor], p20-21
+Change 30.2.2 [thread.req.exception]/2:
 </p>
 
 <blockquote>
-<pre>template &lt;class U, class E&gt; unique_ptr(unique_ptr&lt;U, E&gt;&amp;&amp; u);
-</pre>
-
-<blockquote>
-
 <p>
--20- <i>Requires:</i> If <tt><del>D</del> <ins>E</ins></tt> is not a reference type,
-construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
-shall be well formed and shall not throw an exception.
+-2- <del>The <tt>error_category</tt> (19.5.1.1) of the <tt>error_code</tt> reported by
+such an exception's <tt>code()</tt> member function 
+is as specified in the error condition Clause.</del>
 <ins>
-Otherwise <tt>E</tt> is a reference type and construction of the deleter
-<tt>D</tt> from an lvalue of type <tt>E</tt> shall be well formed and
-shall not throw an exception.
+The <tt>error_code</tt> reported by such an exception's <tt>code()</tt> member
+function shall compare equal to one of the conditions specified in
+the function's error condition Clause. [<i>Example:</i> When the thread
+constructor fails:
 </ins>
-If <tt>D</tt> is
-a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>
-(diagnostic required). <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be
-implicitly convertible to <tt>pointer</tt>. [<tt>Note:</tt> These
-requirements imply that <tt>T</tt> and <tt>U</tt> are complete types.
-<i>-- end note</i>]
 </p>
+<blockquote><pre><ins>
+ec.category() == implementation-defined // probably system_category
+ec == errc::resource_unavailable_try_again // holds true
+</ins></pre></blockquote>
 
-<p>
--21- <i>Effects:</i> Constructs a <tt>unique_ptr</tt> which owns the
-pointer which <tt>u</tt> owns (if any). If the deleter
-<ins><tt>E</tt></ins> is not a reference type, <del>it</del> <ins>this
-deleter</ins> is move constructed from <tt>u</tt>'s deleter, otherwise
-<del>the reference</del> <ins>this deleter</ins> is copy constructed
-from <tt>u</tt>.'s deleter. After the construction, <tt>u</tt> no longer
-owns a pointer. [<i>Note:</i> The deleter constructor can be implemented
-with <tt>std::forward&lt;<del>D</del><ins>E</ins>&gt;</tt>. <i>-- end
-note</i>]
-</p>
+<p><ins>
+&#8212; <i>end example</i>]
+</ins></p>
 
 </blockquote>
-</blockquote>
 
+
+
+
+
+
+<hr>
+<h3><a name="1110"></a>1110. Is <tt>for_each</tt> overconstrained?</h3>
+<p><b>Section:</b> 25.2.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-29  <b>Last modified:</b> 2009-10-27</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Change 20.8.9.2.3 [unique.ptr.single.asgn], p1-3
+Quoting working paper for reference (25.2.4 [alg.foreach]):
 </p>
 
 <blockquote>
-<pre>unique_ptr&amp; operator=(unique_ptr&amp;&amp; u);
+<pre>template&lt;InputIterator Iter, Callable&lt;auto, Iter::reference&gt; Function&gt;
+  requires CopyConstructible&lt;Function&gt;
+  Function for_each(Iter first, Iter last, Function f);
 </pre>
 <blockquote>
-
 <p>
--1- <i>Requires:</i> <ins>If the deleter <tt>D</tt> is not a reference type,</ins>
-<del>A</del><ins>a</ins>ssignment of the deleter <tt>D</tt> from an rvalue <tt>D</tt> shall not throw an exception.
-<ins>
-Otherwise the deleter <tt>D</tt> is a reference type,
-and assignment of the deleter <tt>D</tt> from an lvalue <tt>D</tt> shall not throw an exception.</ins>
+1 Effects: Applies f to the result of dereferencing every iterator in the
+ range [first,last), starting from first and proceeding to last - 1.
 </p>
-
 <p>
--2- <i>Effects:</i> reset(u.release()) followed by
-a<ins>n</ins> <del>move</del> assignment from <del><tt>u</tt>'s deleter to this deleter</del>
-<ins><tt>std::forward&lt;D&gt;(u.get_deleter())</tt></ins>.
+2 Returns: f.
 </p>
-
 <p>
--3- <i>Postconditions:</i> This <tt>unique_ptr</tt> now owns the pointer
-which <tt>u</tt> owned, and <tt>u</tt> no longer owns it. <del>[<i>Note:</i> If
-<tt>D</tt> is a reference type, then the referenced lvalue deleters are
-move assigned. <i>-- end note</i>]</del>
+3 Complexity: Applies f exactly last - first times.
 </p>
 </blockquote>
 </blockquote>
 
 <p>
-Change 20.8.9.2.3 [unique.ptr.single.asgn], p6-7
+P2 implies the passed object <tt>f</tt> should be invoked at each stage, rather than
+some copy of <tt>f</tt>.  This is important if the return value is to usefully
+accumulate changes.  So the requirements are an object of type <tt>Function</tt> can
+be passed-by-value, invoked multiple times, and then return by value.  In
+this case, <tt>MoveConstructible</tt> is sufficient. This would open support for
+move-only functors, which might become important in concurrent code as you
+can assume there are no other references (copies) of a move-only type and so
+freely use them concurrently without additional locks.
 </p>
 
-<blockquote>
-<pre>template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u);
-</pre>
-<blockquote>
+<p><i>[
+See further discussion starting with c++std-lib-23686.
+]</i></p>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
 
+<blockquote>
 <p>
-<i>Requires:</i> <ins>If the deleter <tt>E</tt> is not a reference type,</ins>
-<del>A</del><ins>a</ins>ssignment of the deleter <tt>D</tt> from an rvalue
-<tt><del>D</del><ins>E</ins></tt> shall not throw an exception.
-<ins>
-Otherwise the deleter <tt>E</tt> is a reference type,
-and assignment of the deleter <tt>D</tt> from an lvalue <tt>E</tt> shall not throw an exception.</ins>
-<tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>.
-[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U&gt;</tt>
-are complete types. <i>-- end note</i>]
+Pete suggests we may want to look at this in a broader context
+involving other algorithms.
+We should also consider the implications of parallelism.
 </p>
-
 <p>
-<i>Effects:</i> <tt>reset(u.release())</tt> followed by
-a<ins>n</ins> <del>move</del> assignment from <del><tt>u</tt>'s deleter to this deleter</del>
-<ins><tt>std::forward&lt;E&gt;(u.get_deleter())</tt></ins>.
-<del>If either
-<tt>D</tt> or <tt>E</tt> is a reference type, then the referenced lvalue
-deleter participates in the move assignment.</del>
+Move to Open, and recommend the issue be deferred until after the next
+Committee Draft is issued.
 </p>
-
-</blockquote>
 </blockquote>
 
+<p><i>[
+2009-10-14 Daniel de-conceptified the proposed resolution.
+]</i></p>
 
 
+<blockquote>
+<p>
+The note in 25.1 [algorithms.general]/9 already says the right thing:
+</p>
+<blockquote>
+Unless otherwise specified, algorithms that take function objects
+as arguments are permitted to copy those function objects freely.
+</blockquote>
+<p>
+So we only need to ensure that the wording for <tt>for_each</tt> is sufficiently
+clear, which is the intend of the following rewording.
+</p>
+</blockquote>
 
+<p><i>[
+2009-10-15 Daniel proposes:
+]</i></p>
 
 
-<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Rani Sharoni <b>Opened:</b> 2009-02-12  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<blockquote>
+<ul>
+<li>
 <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.
+Add a new Requires clause just after the prototype declaration (25.2.4 [alg.foreach]):
 </p>
-
+<blockquote>
 <p>
-<b>Regression</b>
+<ins><i>Requires:</i> <tt>Function</tt> shall be <tt>MoveConstructible</tt>
+( [moveconstructible]), <tt>CopyConstructible</tt> is not required.</ins>
 </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
+</blockquote>
 </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>
+Change 25.2.4 [alg.foreach]/2 as indicated:
 </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>
+<blockquote>
+<i>Returns:</i> <ins>std::move(</ins>f<ins>)</ins>.
+</blockquote>
+</li>
+</ul>
+</blockquote>
 
 <p><i>[
-Batavia (2009-05):
+2009-10 post-Santa Cruz:
 ]</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>
+Move to Tentatively Ready, using Daniel's wording without the portion
+saying "CopyConstructible is not required".
 </blockquote>
 
+<p><i>[
+2009-10-27 Daniel adds:
+]</i></p>
 
-<p><b>Proposed resolution:</b></p>
-
-<p>
-23.2.1 [container.requirements.general]  paragraph 10 add footnote:
-</p>
 
 <blockquote>
 <p>
--10- 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>
+I see that during the Santa Cruz meeting the originally proposed addition
 </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>
-
+, <tt>CopyConstructible</tt> is not required.
 </blockquote>
 
 <p>
-23.3.2.3 [deque.modifiers] change paragraph 2 to say:
+was removed. I don't think that this removal was a good idea. The combination
+of 25.1 [algorithms.general]/9
 </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>
+[<i>Note:</i> Unless otherwise specified, algorithms that take function objects
+as arguments are permitted to copy those function objects freely.[..]
 </blockquote>
 
 <p>
-23.3.2.3 [deque.modifiers] change paragraph 6 to say:
+with the fact that <tt>CopyConstructible</tt> is a refinement <tt>MoveConstructible</tt>
+makes it necessary that such an explicit statement is given. Even the
+existence of the usage of <tt>std::move</tt> in the <i>Returns</i> clause doesn't
+help much, because this would still be well-formed for a <tt>CopyConstructible</tt>
+without move constructor. Let me add that the originally proposed
+addition reflects current practice in the standard, e.g. 25.3.9 [alg.unique]/5
+usages a similar terminology.
 </p>
 
-<blockquote>
--6- <i>Throws:</i> Nothing unless an exception is thrown by the copy
-constructor<ins>, move constructor</ins> or assignment operator of <tt>T</tt>.
-</blockquote>
-
 <p>
-23.3.6.2 [vector.capacity] remove paragraph 2
+For similar wording need in case for auto_ptr see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>.
 </p>
 
-<blockquote>
-<del>-2- <i>Requires:</i> If <tt>value_type</tt> has a move constructor,
-that constructor shall not throw any exceptions.</del>
+<p><i>[
+Howard: Moved from Tentatively Ready to Open.
+]</i></p>
+
 </blockquote>
 
-<p>
-23.3.6.2 [vector.capacity] paragraph 3 change to say:
-</p>
 
-<blockquote>
--3- <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><b>Proposed resolution:</b></p>
+<ul>
+<li>
 <p>
-23.3.6.2 [vector.capacity] paragraph 12 change to say:
+Add a new Requires clause just after the prototype declaration (25.2.4 [alg.foreach]):
 </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:
+<ins><i>Requires:</i> <tt>Function</tt> shall be <tt>MoveConstructible</tt>
+( [moveconstructible]).</ins>
 </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>
-
+</li>
+<li>
 <p>
-23.3.6.4 [vector.modifiers] change paragraph 2 to say:
+Change 25.2.4 [alg.foreach]/2 as indicated:
 </p>
 
 <blockquote>
--2- <i>Remarks:</i> Causes reallocation if the new size is greater than
-the old capacity. If no reallocation happens, all the iterators and
-references before the insertion point remain valid. If an exception is
-thrown other than by the copy constructor<ins>, move constructor</ins>
-or assignment operator of <tt>T</tt> or by any <tt>InputIterator</tt>
-operation there are no effects.
+<i>Returns:</i> <ins>std::move(</ins>f<ins>)</ins>.
 </blockquote>
+</li>
+</ul>
 
-<p>
-23.3.6.4 [vector.modifiers] change paragraph 6 to say:
-</p>
 
-<blockquote>
--6- <i>Throws:</i> Nothing unless an exception is thrown by the copy
-constructor<ins>, move constructor</ins> or assignment operator of <tt>T</tt>.
-</blockquote>
 
 
 
@@ -22033,258 +18319,185 @@ constructor<ins>, move constructor</ins> or assignment operator of <tt>T</tt>.
 
 
 <hr>
-<h3><a name="987"></a>987. <tt>reference_wrapper</tt> and function types</h3>
-<p><b>Section:</b> 20.7.5 [refwrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-18  <b>Last modified:</b> 2009-07-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap">issues</a> in [refwrap].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1112"></a>1112. bitsets and new style for loop</h3>
+<p><b>Section:</b> 20.3.7 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">Tentatively NAD Future</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-06  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Future">Tentatively NAD Future</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The synopsis in 20.7.5 [refwrap] says:
+<tt>Std::bitset</tt> is a homogeneous container-like sequence of bits, yet it does
+not model the Range concept so cannot be used with the new for-loop syntax.
+It is the only such type in the library that does NOT support the new for
+loop.
 </p>
-
-<blockquote><pre>template &lt;<b>ObjectType</b> T&gt; class reference_wrapper
-...
-</pre></blockquote>
-
 <p>
-And then paragraph 3 says:
+The obvious reason is that bitset does not support iterators.
 </p>
-
-<blockquote>
 <p>
-The template instantiation <tt>reference_wrapper&lt;T&gt;</tt> shall be
-derived from <tt>std::unary_function&lt;T1, R&gt;</tt> only if the type
-<tt>T</tt> is any of the following:
+At least two reasonable solutions are available:
 </p>
-
-<ul>
+<ol type="i">
 <li>
-a <b>function type</b> or a pointer to function type taking one argument of
-type <tt>T1</tt> and returning <tt>R</tt>
+Add an iterator interface to <tt>bitset</tt>, bringing its interface close to that
+of <tt>std::array</tt>
 </li>
-</ul>
-</blockquote>
-
+<li>
+Provide an unspecified concept_map for <tt>Range&lt;bitset&gt;</tt>.
+</li>
+</ol>
 <p>
-But function types are not <tt>ObjectType</tt>s.
+The latter will still need some kind of iterator-like adapter for <tt>bitset</tt>,
+but gives implementers greater freedom on the details. E.g. begin/end return
+some type that simply invokes <tt>operator[]</tt> on the object it wraps, and
+increments its index on <tt>operator++</tt>.  A vendor can settle for <tt>InputIterator</tt>
+support, rather than wrapping up a full <tt>RandomAccessIterator</tt>.
 </p>
-
 <p>
-Paragraph 4 contains the same contradiction.
+I have a mild preference for option (ii) as I think it is less work to
+specify at this stage of the process, although (i) is probably more useful
+in the long run.
 </p>
-
-<p><i>[
-Post Summit:
-]</i></p>
-
-
-<blockquote>
 <p>
-Jens: restricted reference to ObjectType
+Hmm, my wording looks a little woolly, as it does not say what the element
+type of the range is.  Do I get a range of <tt>bool</tt>, <tt>bitset&lt;N&gt;::reference</tt>, or
+something else entirely?
 </p>
 <p>
-Recommend Review.
+I guess most users will assume the behaviour of reference, but expect to
+work with <tt>bool</tt>.  <tt>Bool</tt> is OK for read-only traversal, but you really need to
+take a reference to a <tt>bitset::reference</tt> if you want to write back.
 </p>
-</blockquote>
 
 <p><i>[
-Post Summit, Peter adds:
+Batavia (2009-05):
 ]</i></p>
 
-
 <blockquote>
-<p>
-In <a href="https://svn.boost.org/trac/boost/ticket/1846">https://svn.boost.org/trac/boost/ticket/1846</a>
-however Eric Niebler makes the very reasonable point that <tt>reference_wrapper&lt;F&gt;</tt>,
-where <tt>F</tt> is a function type, represents a reference to a function,
-a legitimate entity. So <tt>boost::ref</tt> was changed to allow it.
-</p>
-<p>
-<a href="https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp">https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp</a>
-</p>
-<p>
-Therefore, I believe an alternative proposed resolution for issue 987 could simply
-allow <tt>reference_wrapper</tt> to be used with function types.
-</p>
+Move to Open.
+We further recommend this be deferred until after the next Committee Draft.
 </blockquote>
 
 <p><i>[
-Post Summit, Howard adds:
+2009-05-25 Alisdair adds:
 ]</i></p>
 
 
 <blockquote>
 <p>
-I agree with Peter (and Eric).  I got this one wrong on my first try.  Here
-is code that demonstrates how easy (and useful) it is to instantiate
-<tt>reference_wrapper</tt> with a function type:
-</p>
-
-<blockquote><pre>#include &lt;functional&gt;
-
-template &lt;class F&gt;
-void test(F f);
-
-void f() {}
-
-int main()
-{
-    test(std::ref(f));
-}
-</pre></blockquote>
-
-<p>
-Output (link time error shows type of <tt>reference_wrapper</tt> instantiated
-with function type):
-</p>
-
-<blockquote><pre>Undefined symbols:
-  "void test&lt;std::reference_wrapper&lt;void ()()&gt; &gt;(std::reference_wrapper&lt;void ()()&gt;)",...
-</pre></blockquote>
-
-<p>
-I've taken the liberty of changing the proposed wording to allow function types
-and set to Open.  I'll also freely admit that I'm not positive <tt>ReferentType</tt>
-is the correct concept.
+I just stumbled over the <tt>Range concept_map</tt> for <tt>valarray</tt> and this should
+probably set the precedent on how to write the wording.
 </p>
 
-</blockquote>
-
-
-
 <p><i>[
-Batavia (2009-05):
+Howard: I've replaced the proposed wording with Alisdair's suggestion.
 ]</i></p>
 
-<blockquote>
-<p>
-Howard observed that <tt>FunctionType</tt>,
-a concept not (yet?) in the Working Paper,
-is likely the correct constraint to be applied.
-However, the proposed resolution provides an adequate approximation.
-</p>
-<p>
-Move to Review.
-</p>
+
 </blockquote>
 
 <p><i>[
-2009-05-23 Alisdair adds:
+2009-07-24 Daniel modifies the proposed wording for non-concepts.
 ]</i></p>
 
 
-<blockquote>
-<p>
-By constraining to <tt>PointeeType</tt> we rule out the ability for <tt>T</tt> to be a
-reference, and call in reference-collapsing.  I'm not sure if this is
-correct and intended, but would like to be sure the case was considered.
-</p>
-<p>
-Is dis-allowing reference types and the
-implied reference collapsing the intended result?
-</p>
-</blockquote>
-
 <p><i>[
-2009-07 Frankfurt
+2009-10 post-Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Moved from Review to Open only because the wording needs to be
-tweaked for concepts removal.
+Mark as Tentatively NAD Future due to the loss of concepts.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
+<ol>
+<li>
 <p>
-Change the synopsis in 20.7 [function.objects]:
+Modify the section 20.3.7 [template.bitset] <tt>&lt;bitset&gt;</tt> synopsis by adding
+the following at the end of the synopsis:
 </p>
-
-<blockquote><pre>// 20.6.5, reference_wrapper:
-template &lt;<del>ObjectType</del> <ins>ReferentType</ins> T&gt;
-  <ins>requires PointeeType&lt;T&gt;</ins>
-  class reference_wrapper;
-
-template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
-  reference_wrapper&lt;T&gt; ref(T&amp;);
-
-template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
-  reference_wrapper&lt;const T&gt; cref(const T&amp;);
-
-template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
-  reference_wrapper&lt;T&gt; ref(reference_wrapper&lt;T&gt;);
-template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
-  reference_wrapper&lt;const T&gt; cref(reference_wrapper&lt;T&gt;);
+<blockquote><pre><ins>
+// XX.X.X bitset range access [bitset.range]
+template&lt;size_t N&gt; <i>unspecified-1</i> begin(bitset&lt;N&gt;&amp;);
+template&lt;size_t N&gt; <i>unspecified-2</i> begin(const bitset&lt;N&gt;&amp;);
+template&lt;size_t N&gt; <i>unspecified-1</i> end(bitset&lt;N&gt;&amp;);
+template&lt;size_t N&gt; <i>unspecified-2</i> end(const bitset&lt;N&gt;&amp;);
+</ins>
 </pre></blockquote>
-
+</li>
+<li>
 <p>
-Change the synopsis in 20.7.5 [refwrap]:
+Add a new section <ins>"bitset range access" [bitset.range]</ins>
+after the current section 20.3.7.3 [bitset.operators] with the following series of
+paragraphs:
 </p>
-
-<blockquote><pre>template &lt;<del>ObjectType</del> <ins>ReferentType</ins> T&gt;
-  <ins>requires PointeeType&lt;T&gt;</ins>
-  class reference_wrapper
-   ...
-</pre></blockquote>
-
+<blockquote>
 <p>
-Change the prototypes in 20.7.5.5 [refwrap.helpers]:
+<ins>
+1.  In the <tt>begin</tt> and <tt>end</tt> function templates that follow, <i>unspecified-1</i>
+is a type that meets the requirements of a mutable random access
+iterator (24.2.5 [random.access.iterators]) whose <tt>value_type</tt> is <tt>bool</tt> and
+whose reference type is <tt>bitset&lt;N&gt;::reference</tt>.
+<i>unspecified-2</i> is a type that meets the requirements of a constant
+random access iterator (24.2.5 [random.access.iterators]) whose <tt>value_type</tt>
+is <tt>bool</tt> and whose reference type is <tt>bool</tt>.
+</ins>
 </p>
+<pre><ins>
+template&lt;size_t N&gt; <i>unspecified-1</i> begin(bitset&lt;N&gt;&amp;);
+template&lt;size_t N&gt; <i>unspecified-2</i> begin(const bitset&lt;N&gt;&amp;);
+</ins>
+</pre>
+<blockquote>
+<ins>2.  Returns: an iterator referencing the first bit in the bitset.</ins>
+</blockquote>
+
+<pre><ins>
+template&lt;size_t N&gt; <i>unspecified-1</i> end(bitset&lt;N&gt;&amp;);
+template&lt;size_t N&gt; <i>unspecified-2</i> end(const bitset&lt;N&gt;&amp;);
+</ins></pre>
+
+<blockquote>
+<ins>3.  Returns: an iterator referencing one past the last bit in the
+bitset.</ins>
+</blockquote>
+</blockquote>
+</li>
+</ol>
+
+
+
 
-<blockquote><pre>template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
-  reference_wrapper&lt;T&gt; ref(T&amp;);
-...
-template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
-  reference_wrapper&lt;const T&gt; cref(const T&amp;);
-...
-template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
-  reference_wrapper&lt;T&gt; ref(reference_wrapper&lt;T&gt;);
-...
-template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
-  reference_wrapper&lt;const T&gt; cref(reference_wrapper&lt;T&gt;);
-</pre></blockquote>
 
 
 
-<p><b>Rationale:</b></p>
-<p>
-a) The occurrence of <tt>T&amp;</tt> in the function signature auto-implies
-<tt>std::ReferentType</tt>,
-this is due to 14.11.1.2 [temp.req.impl]/4 bullet 4
-</p>
-<p>
-b) The occurrence of the constrained template <tt>reference_wrapper&lt;T&gt;</tt> in
-the remaining
-signatures lets kick in 14.11.1.2 [temp.req.impl]/4 bullet 1 and adds *all* requirements of
-this template. But we need to add at least *one* requirement (and it
-was an arbitrary,
-but natural decision to require <tt>std::PointeeType</tt> here) to *activate*
-this. If we hadn't done
-this, we were in unconstrained mode!
-</p>
 
 
 
 
 
 <hr>
-<h3><a name="996"></a>996. Move operation not well specified</h3>
-<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-06  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1113"></a>1113. <tt>bitset::to_string</tt> could be simplified</h3>
+<p><b>Section:</b> 20.3.7 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-09  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-There are lots of places in the standard where we talk about "the move
-constructor" but where we mean "the move operation," i.e.  <tt>T( move( x ) )</tt>.
+In <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a> our resolution is changing the signature by adding two
+defaulting arguments to 3 calls.  In principle, this means that ABI breakage
+is not an issue, while API is preserved.
 </p>
 <p>
-We also don't account for whether that operation modifies <tt>x</tt> or not, and
-we need to.
+With that observation, it would be very nice to use the new ability to
+supply default template parameters to function templates to collapse all 3
+signatures into 1.  In that spirit, this issue offers an alternative resolution
+than that of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>.
 </p>
 
 <p><i>[
@@ -22292,142 +18505,195 @@ Batavia (2009-05):
 ]</i></p>
 
 <blockquote>
-Move to Open, pending proposed wording from Dave for further
-review.
+Move to Open,
+and look at the issue again after <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a> has been accepted.
+We further recommend this be deferred until after the next Committee Draft.
 </blockquote>
 
+<p><i>[
+2009-10 post-Santa Cruz:
+]</i></p>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
 
+<blockquote>
+Move to Tentatively Ready.
+</blockquote>
 
 
 
+<p><b>Proposed resolution:</b></p>
 
-<hr>
-<h3><a name="999"></a>999. Taking the address of a function</h3>
-<p><b>Section:</b> 20.8.8.1 [object.addressof] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-03-09  <b>Last modified:</b> 2009-07-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#object.addressof">issues</a> in [object.addressof].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<ol type="A">
+<li>
 <p>
-The same fix (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>) may be applied to <tt>addressof</tt>, which is also constrained to
-<tt>ObjectType</tt>. (That was why <tt>boost::ref</tt> didn't work with functions - it
-tried to apply <tt>boost::addressof</tt> and the <tt>reinterpret_cast&lt;char&amp;&gt;</tt>
-implementation of <tt>addressof</tt> failed.)
+In 20.3.7 [template.bitset]/1 (class bitset) ammend:
 </p>
-
-
-
-<p><i>[
-Batavia (2009-05):
-]</i></p>
-
-<blockquote>
-<p>
-We agree.
-</p>
-<p>
-Move to Tentatively Ready.
-</p>
-</blockquote>
-
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
-
-
-<blockquote>
-Moved from Tentatively Ready to Open only because the wording needs to be
-tweaked for concepts removal.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis in 20.8 [memory]:
-</p>
-
-<blockquote><pre>template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
-  T* addressof(T&amp; r);
+<blockquote><pre>template &lt;class charT <ins>= char</ins>,
+            class traits <ins>= char_traits&lt;charT&gt;</ins>,
+            class Allocator <ins>= allocator&lt;charT&gt;</ins>&gt; 
+  basic_string&lt;charT, traits, Allocator&gt;
+  to_string(charT zero = charT('0'), charT one = charT('1')) const;
+<del>template &lt;class charT, class traits&gt; 
+  basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt; to_string() const; 
+template &lt;class charT&gt; 
+  basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt; to_string() const; 
+basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt; to_string() const;</del>
 </pre></blockquote>
-
+</li>
+<li>
 <p>
-Change 20.8.8.1 [object.addressof]:
+In 20.3.7.2 [bitset.members] prior to p35 ammend:
 </p>
-
-<blockquote><pre>template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
-  T* addressof(T&amp; r);
+<blockquote><pre>template &lt;class charT <ins>= char</ins>,
+            class traits <ins>= char_traits&lt;charT&gt;</ins>,
+            class Allocator <ins>= allocator&lt;charT&gt;</ins>&gt; 
+  basic_string&lt;charT, traits, Allocator&gt;
+  to_string(charT zero = charT('0'), charT one = charT('1')) const;
 </pre></blockquote>
+</li>
+<li>
+Strike 20.3.7.2 [bitset.members] paragraphs 37 -&gt; 39 (including signature
+above 37)
+</li>
+</ol>
 
 
-<p><b>Rationale:</b></p>
-<p>
-a) The occurrence of <tt>T&amp;</tt> in the function signature auto-implies
-<tt>std::ReferentType</tt>,
-this is due to 14.11.1.2 [temp.req.impl]/4 bullet 4
-</p>
-
 
 
 
 
 <hr>
-<h3><a name="1004"></a>1004. Response to UK 179</h3>
-<p><b>Section:</b> 17.6.3.8 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.functions">issues</a> in [res.on.functions].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="1114"></a>1114. Type traits underspecified</h3>
+<p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-05-12  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 
-<p><b>Addresses UK 179</b></p>
+<p>
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>.
+</p>
 
 <p>
-According to the 4th bullet there is a problem if "if any replacement
-function or handler function or destructor operation throws an
-exception". There should be no problem throwing exceptions so long as
-they are caught within the function.
+The current wording in 20.6.1 [meta.rqmts] is still unclear concerning
+it's requirements on the type traits classes regarding ambiguities.
+Specifically it's unclear
 </p>
 
+<ul>
+<li>
+if a predicate trait (20.6.4 [meta.unary], 20.6.5 [meta.rel]) could derive from both
+<tt>true_type</tt>/<tt>false_type</tt>.
+</li>
+<li>
+if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could ambiguously derive
+from the same specified result type.
+</li>
+<li>
+if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could derive from other
+<tt>integral_constant</tt> types making the contained names ambiguous
+</li>
+<li>
+if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could have other base
+classes that contain members hiding the name of the result type members
+or make the contained member names ambiguous.
+</li>
+</ul>
+
 <p><i>[
 Batavia (2009-05):
 ]</i></p>
 
 <blockquote>
-The phrasing "throws an exception" is commonly used elsewhere
-to mean "throws or propagates an exception."
-Move to Open pending a possible more general resolution.
+<p>
+Alisdair would prefer to factor some of the repeated text,
+but modulo a corner case or two,
+he believes the proposed wording is otherwise substantially correct.
+</p>
+<p>
+Move to Open.
+</p>
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt:
+2009-10 post-Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Replace "propagates" in the proposed resolution with the phrase "exits
-via" and move to Ready.
+Move to Tentatively Ready.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
+<p><i>[
+The usage of the notion of a <i>BaseCharacteristic</i> below
+might be
+useful in other places - e.g. to define the base class relation in
+20.7.5 [refwrap], 20.7.14 [func.memfn], or 20.7.15.2 [func.wrap.func].
+In this case it's definition should probably
+be moved to Clause 17
+]</i></p>
+
+
+<ol>
+<li>
 <p>
-Change the 4th bullet of 17.6.3.8 [res.on.functions], p2:
+Change 20.6.1 [meta.rqmts]/1 as indicated:
 </p>
-
 <blockquote>
-<ul>
+[..] It shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, and publicly
+<ins>and unambiguously</ins> derived, directly or indirectly, from
+<ins>its <i>BaseCharacteristic</i>, which is</ins> a specialization of the
+template <tt>integral_constant</tt> (20.6.3), with the arguments to the template
+<tt>integral_constant</tt> determined by the requirements for the particular
+property being described. <ins>The member names of the
+<i>BaseCharacteristic</i> shall be unhidden and unambiguously
+available in the <i>UnaryTypeTrait</i>.</ins>
+</blockquote>
+</li>
+<li>
+<p>
+Change 20.6.1 [meta.rqmts]/2 as indicated:
+</p>
+<blockquote>
+[..] It shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, and publicly
+<ins>and unambiguously</ins> derived, directly or indirectly, from
+<del>an instance</del> <ins>its <i>BaseCharacteristic</i>, which is a
+specialization</ins> of the template <tt>integral_constant</tt> (20.6.3), with
+the arguments to the template <tt>integral_constant</tt> determined by the
+requirements for the particular relationship being described. <ins>The
+member names of the <i>BaseCharacteristic</i> shall be unhidden
+and unambiguously available in the <i>BinaryTypeTrait</i>.</ins>
+</blockquote>
+</li>
 <li>
-if any replacement function or handler function or destructor operation
-<del>throws</del> <ins>exits via</ins> an exception, unless specifically
-allowed in the applicable <i>Required behavior:</i> paragraph.
+<p>
+Change 20.6.4 [meta.unary]/2 as indicated:
+</p>
+<blockquote>
+Each of these templates shall be a <i>UnaryTypeTrait</i> (20.6.1),
+<del>publicly derived directly or indirectly from <tt>true_type</tt> if the
+corresponding condition is true, otherwise from <tt>false_type</tt></del>
+<ins>where its <i>BaseCharacteristic</i> shall be <tt>true_type</tt> if the
+corresponding condition is true, otherwise <tt>false_type</tt></ins>.
+</blockquote>
 </li>
-</ul>
+<li>
+<p>
+Change 20.6.5 [meta.rel]/2 as indicated:
+</p>
+
+<blockquote>
+Each of these templates shall be a <i>BinaryTypeTrait</i> (20.6.1),
+<del>publicly derived directly or indirectly from <tt>true_type</tt> if the
+corresponding condition is true, otherwise from <tt>false_type</tt></del>
+<ins>where its <i>BaseCharacteristic</i> shall be <tt>true_type</tt> if the
+corresponding condition is true, otherwise <tt>false_type</tt></ins>.
 </blockquote>
+</li>
+</ol>
 
 
 
@@ -22435,902 +18701,835 @@ allowed in the applicable <i>Required behavior:</i> paragraph.
 
 
 <hr>
-<h3><a name="1008"></a>1008. <tt>nested_exception</tt> wording unclear</h3>
-<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-04</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1115"></a>1115. <tt>va_copy</tt> missing from Standard macros table</h3>
+<p><b>Section:</b> C.2 [diff.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Miles Zhao <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#diff.library">issues</a> in [diff.library].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses JP 31</b></p>
-
 <p>
-It is difficult to understand in which case <tt>nested_exception</tt> is applied.
+In "Table 122 -- Standard macros" of C.2 [diff.library], which lists the 56 macros
+inherited from C library, <tt>va_copy</tt> seems to be missing. But in
+"Table 21 -- Header <tt>&lt;cstdarg&gt;</tt> synopsis" (18.10 [support.runtime]), there is.
 </p>
 
 <p><i>[
-Summit:
+2009-10 post-Santa Cruz:
 ]</i></p>
 
- 
+
 <blockquote>
-Alisdair will add an example in an update to
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2619.pdf">N2619</a>.
+Mark as Tentatively NAD Editorial, if Pete disagrees, Howard
+will move to Tentatively Ready
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
+<p>
+Add <tt>va_copy</tt> to Table 122 -- Standard macros in C.2 [diff.library].
+</p>
 
 
 
 
 
 <hr>
-<h3><a name="1009"></a>1009. <tt>InputIterator</tt> post-increment dangerous</h3>
-<p><b>Section:</b> 24.2.1 [iterator.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-28</p>
+<h3><a name="1118"></a>1118. tuple query APIs do not support cv-qualification</h3>
+<p><b>Section:</b> 20.5.2.5 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.helper">active issues</a> in [tuple.helper].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 251</b></p>
-
 <p>
-The post-increment operator is dangerous for a general InputIterator.
-The multi-pass guarantees that make it meaningful are defined as part of
-the ForwardIterator refinement. Any change will affect only constrained
-templates that have not yet been written, so should not break existing
-user iterators which remain free to add these operations. This change
-will also affect the generalised OutputIterator, although there is no
-percieved need for the post-increment operator in this case either.
+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-07-28 Alisdair adds:
+2009-05-24 Daniel adds:
 ]</i></p>
 
 
 <blockquote>
-We still think the issue is relevant, but needs totally rewording in
-non-concept language.  We would like to see the issue retained as Open,
-rather than deferred as NAD Concepts.  Review status is no longer
-appropriate.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 24.2.1 [iterator.iterators]:
+All <tt>tuple_size</tt> templates with a base class need to derive publicly, e.g.
 </p>
 
-<blockquote><pre>concept Iterator&lt;typename X&gt; : Semiregular&lt;X&gt; { 
-  MoveConstructible reference = typename X::reference; 
-  <del>MoveConstructible postincrement_result;</del>
-
-  <del>requires HasDereference&lt;postincrement_result&gt;;</del>
-
-  reference operator*(X&amp;&amp;); 
-  X&amp; operator++(X&amp;); 
-  <del>postincrement_result operator++(X&amp;, int);</del>
-}
-</pre>
-
-<p>...</p>
-<pre><del>postincrement_result operator++(X&amp; r, int);</del>
-</pre>
-
-<blockquote>
-<del>-3- <i>Effects:</i> equivalent to <tt>{ X tmp = r; ++r; return tmp; }</tt>.</del>
-</blockquote>
-
-</blockquote>
+<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>
-Change 24.2.2 [input.iterators]:
+The same applies to the tuple_element class hierarchies.
 </p>
-
-<blockquote>
-<pre>concept InputIterator&lt;typename X&gt; : Iterator&lt;X&gt;, EqualityComparable&lt;X&gt; { 
-  ObjectType value_type = typename X::value_type; 
-  MoveConstructible pointer = typename X::pointer; 
-
-  SignedIntegralLike difference_type = typename X::difference_type; 
-
-  requires IntegralType&lt;difference_type&gt; 
-        &amp;&amp; Convertible&lt;reference, const value_type &amp;&gt;; 
-        &amp;&amp; Convertible&lt;pointer, const value_type*&gt;; 
-
-  <del>requires Convertible&lt;HasDereference&lt;postincrement_result&gt;::result_type, const value_type&amp;&gt;;</del>
-
-  pointer operator-&gt;(const X&amp;); 
-}
-</pre>
-</blockquote>
-
 <p>
-Change 24.2.3 [output.iterators]:
+What is actually meant with the comment
 </p>
-
 <blockquote>
-<pre>auto concept OutputIterator&lt;typename X, typename Value&gt; { 
-  requires Iterator&lt;X&gt;; 
-
-  typename reference = Iterator&lt;X&gt;::reference; 
-  <del>typename postincrement_result = Iterator&lt;X&gt;::postincrement_result;</del>
-  requires SameType&lt;reference, Iterator&lt;X&gt;::reference&gt; 
-        <del>&amp;&amp; SameType&lt;postincrement_result, Iterator&lt;X&gt;::postincrement_result&gt;</del>
-        <del>&amp;&amp; Convertible&lt;postincrement_result, const X&amp;&gt;</del>
-        &amp;&amp; HasAssign&lt;reference, Value&gt; 
-        <del>&amp;&amp; HasAssign&lt;HasDereference&lt;postincrement_result&gt;::result_type, Value&gt;</del>;
-}
-</pre>
+this solution relies on 'metafunction forwarding' to inherit the
+nested typename type
 </blockquote>
-
 <p>
-Change 24.2.4 [forward.iterators]:
+?
+</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>[
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1084">1084</a> which is attempting to change this same area in a compatible
-way.
+2009-05-24 Alisdair adds:
 ]</i></p>
 
 
 <blockquote>
-<pre>concept ForwardIterator&lt;typename X&gt; : InputIterator&lt;X&gt;, Regular&lt;X&gt; { 
-  <del>requires Convertible&lt;postincrement_result, const X&amp;&gt;;</del>
-
-  <ins>MoveConstructible postincrement_result;</ins>
-  <ins>requires HasDereference&lt;postincrement_result&gt;
-        &amp;&amp; Convertible&lt;HasDereference&lt;postincrement_result&gt;::result_type, const value_type&amp;&gt;;</ins>
-
-  <ins>postincrement_result operator++(X&amp;, int);</ins>
-
-  axiom MultiPass(X a, X b) { 
-    if (a == b) *a == *b; 
-    if (a == b) ++a == ++b; 
-  } 
-}
-</pre>
-
-<blockquote>
-<p>-4- ...</p>
-</blockquote>
-
-<pre><ins>postincrement_result operator++(X&amp; r, int);</ins>
-</pre>
-
-<blockquote>
 <p>
-<ins>-5- <i>Effects:</i> equivalent to <tt>{ X tmp = r; ++r; return tmp; }</tt>.</ins>
+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>
-</blockquote>
-
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="1011"></a>1011. <tt>next/prev</tt> wrong iterator type</h3>
-<p><b>Section:</b> 24.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-14</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.operations">active issues</a> in [iterator.operations].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 271</b></p>
-
 <p>
-<tt>next/prev</tt> return an incremented iterator without changing the value of
-the original iterator. However, even this may invalidate an
-<tt>InputIterator</tt>. A <tt>ForwardIterator</tt> is required to guarantee the
-'multipass' property.
+"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>
-
-<p><i>[
-Batavia (2009-05):
-]</i></p>
-
-<blockquote>
-We agree with the proposed resolution.
-Move to Tentatively Ready.
 </blockquote>
 
 <p><i>[
-2009-07 Frankfurt
+2009-10 post-Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Moved from Tentatively Ready to Open only because the wording needs to be
-tweaked for concepts removal.
+Move to Open, Alisdair to provide wording. Once wording is
+provided, Howard will move to Review.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change  [iterator.synopsis]:
+Add to 20.5.1 [tuple.general] p2 (Header <tt>&lt;tuple&gt;</tt> synopsis)
 </p>
 
-<blockquote><pre>template &lt;<del>InputIterator</del> <ins>ForwardIterator</ins> Iter&gt; 
-  Iter next(Iter x, 
-    Iter::difference_type n = 1);
-</pre></blockquote>
+<blockquote><pre>// 20.5.2.3, tuple helper classes:
+template &lt;IdentityOf T&gt; class tuple_size; // undefined
+<ins>template &lt;IdentityOf T&gt; class tuple_size&lt; const T &gt; : tuple_size&lt;T&gt; {};</ins>
+<ins>template &lt;IdentityOf T&gt; class tuple_size&lt; volatile T &gt; : tuple_size&lt;T&gt; {};</ins>
+<ins>template &lt;IdentityOf T&gt; class tuple_size&lt; const volatile T &gt; : tuple_size&lt;T&gt; {};</ins>
 
-<p>
-Change 24.4 [iterator.operations], p6:
-</p>
+template &lt;VariableType... Types&gt; class tuple_size&lt;tuple&lt;Types...&gt; &gt;;
 
-<blockquote><pre>template &lt;<del>InputIterator</del> <ins>ForwardIterator</ins> Iter&gt; 
-  Iter next(Iter x, 
-    Iter::difference_type n = 1);
+template &lt;size_t I, IdentityOf T&gt; class tuple_element; // undefined
+<ins>template &lt;size_t I, IdentityOf T&gt; class tuple_element&lt;I, const T&gt;;</ins>
+<ins>template &lt;size_t I, IdentityOf T&gt; class tuple_element&lt;I, volatile T&gt;;</ins>
+<ins>template &lt;size_t I, IdentityOf T&gt; class tuple_element&lt;I, const volatile T&gt;;</ins>
+
+template &lt;size_t I, VariableType... Types&gt;
+  requires True&lt;(I &lt; sizeof...(Types))&gt; class tuple_element&lt;I, tuple&lt;Types...&gt; &gt;;
 </pre></blockquote>
 
+<p>
+Add to 20.5.2.5 [tuple.helper]
+</p>
+<p><i>[
+(note that this solution relies on 'metafunction forwarding' to inherit the
+nested typename type)
+]</i></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;
+requires True&lt;(I &lt; sizeof...(Types))&gt;
+class tuple_element&lt;I, tuple&lt;Types...&gt; &gt; {
+public:
+  typedef TI type;
+};
 
+<ins>template &lt;size_t I, IdentityOf T&gt;
+  class tuple_element&lt;I, const T&gt; : add_const&lt;tuple_element&lt;I,T&gt;&gt; {};</ins>
 
-<hr>
-<h3><a name="1012"></a>1012. <tt>reverse_iterator</tt> default ctor should value initialize</h3>
-<p><b>Section:</b> 24.5.1.2.1 [reverse.iter.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
-<p><b>Discussion:</b></p>
+<ins>template &lt;size_t I, IdentityOf T&gt;
+  class tuple_element&lt;I, volatile T&gt; : add_volatile&lt;tuple_element&lt;I,T&gt;&gt; {};</ins>
 
-<p><b>Addresses UK 277</b></p>
+<ins>template &lt;size_t I, IdentityOf T&gt;
+  class tuple_element&lt;I, const volatile T&gt; : add_cv&lt;tuple_element&lt;I,T&gt;&gt; {};</ins>
+</pre></blockquote>
 
-<p>
-The default constructor default-initializes current, rather than
-value-initializes. This means that when Iterator corresponds to a
-trivial type, the current member is left un-initialized, even when the
-user explictly requests value intialization! At this point, it is not
-safe to perform any operations on the reverse_iterator other than assign
-it a new value or destroy it. Note that this does correspond to the
-basic definition of a singular iterator.
-</p>
 
-<p><i>[
-Summit:
-]</i></p>
 
 
-<blockquote>
-Agree with option i.
-</blockquote>
 
+<hr>
+<h3><a name="1119"></a>1119. tuple query APIs do not support references</h3>
+<p><b>Section:</b> 20.5.2.5 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.helper">active issues</a> in [tuple.helper].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>
+The <tt>tuple</tt> query APIs <tt>tuple_size</tt> and
+<tt>tuple_element</tt> do not support references-to-tuples.  This can be
+annoying when a template deduced a parameter type to be a reference,
+which must be explicitly stripped with <tt>remove_reference</tt> before calling
+these APIs.
 </p>
-
-<p><i>[
-Batavia (2009-05):
-]</i></p>
-
-<blockquote>
-We believe this should be revisited
-in conjunction with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>,
-which nearly duplicates this issue.
-Move to Open.
-</blockquote>
-
-<p><i>[
-2009-07 post-Frankfurt:
-]</i></p>
-
-
-<blockquote>
 <p>
-Change "constructed" to "initialized" in two places in the proposed resolution.
+I am not proposing a resolution at this point, as there is a
+combinatorial explosion with lvalue/rvalue references and
+cv-qualification (see previous issue) that suggests some higher
+refactoring is in order.  This might be something to kick back over to
+Core/Evolution.
 </p>
 <p>
-Move to Tentatively Ready.
+Note that we have the same problem in numeric_limits.
 </p>
-</blockquote>
-
 
+<p><i>[
+2009-10 post-Santa Cruz:
+]</i></p>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Change  [reverse.iter.con]:
-</p>
 
-<blockquote><pre>reverse_iterator();
-</pre>
 <blockquote>
--1- <i>Effects:</i> <del>Default</del> <ins>Value</ins> initializes <tt>current</tt>. Iterator
-operations applied to the resulting iterator have defined behavior if and
-only if the corresponding operations are defined on a <del>default constructed</del>
-<ins>value initialized</ins>
-iterator of type <tt>Iterator</tt>.
-</blockquote>
+Move to Open. Alisdair to provide wording.
 </blockquote>
 
-<p>
-Change 24.5.2.2.1 [move.iter.op.const]:
-</p>
 
-<blockquote><pre>move_iterator();
-</pre>
-<blockquote>
--1- <i>Effects:</i> Constructs a <tt>move_iterator</tt>, <del>default</del> <ins>value</ins>
-initializing <tt>current</tt>.
-<ins>Iterator
-operations applied to the resulting iterator have defined behavior if and
-only if the corresponding operations are defined on a
-value initialized
-iterator of type <tt>Iterator</tt>.</ins>
-</blockquote>
-</blockquote>
 
+<p><b>Proposed resolution:</b></p>
 
 
 
 
 
 <hr>
-<h3><a name="1019"></a>1019. Response to UK 205</h3>
-<p><b>Section:</b> 20.6.3 [meta.help] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.help">issues</a> in [meta.help].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<h3><a name="1121"></a>1121. Support for multiple arguments</h3>
+<p><b>Section:</b> 20.4.2 [ratio.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">Tentatively NAD Future</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-25  <b>Last modified:</b> 2009-11-02</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.arithmetic">issues</a> in [ratio.arithmetic].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Future">Tentatively NAD Future</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 205</b></p>
-
 <p>
-<tt>integral_constant</tt> objects should be usable in integral-constant-expressions.
-The addition to the language of literal types and the enhanced rules for
-constant expressions make this possible.
+Both add and multiply could sensibly be called with more than two arguments.
+The variadic template facility makes such declarations simple, and is likely
+to be frequently wrapped by end users if we do not supply the variant
+ourselves.
+</p>
+<p>
+We deliberately ignore divide at this point as it is not transitive.
+Likewise, subtract places special meaning on the first argument so I do not
+suggest extending that immediately.  Both could be supported with analogous
+wording to that for add/multiply below.
+</p>
+<p>
+Note that the proposed resolution is potentially incompatible with that
+proposed for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, although the addition of the typedef to ratio would be
+equally useful.
 </p>
 
 <p><i>[
-Batavia (2009-05):
-]</i></p>
-
-<blockquote>
-We agree that the <tt>static</tt> data member
-ought be declared <tt>constexpr</tt>,
-but do not see a need for the proposed <tt>operator value_type()</tt>.
-(A use case would be helpful.)
-Move to Open.
-</blockquote>
-
-<p><i>[
-2009-05-23 Alisdair adds:
+2009-10-30 Alisdair adds:
 ]</i></p>
 
 
 <blockquote>
 <p>
-The motivating case in my mind is that we can then use
-<tt>true_type</tt> and <tt>false_type</tt> as integral Boolean expressions, for example inside
-a <tt>static_assert</tt> declaration.  In that sense it is purely a matter of style.
+The consensus of the group when we reviewed this in Santa Cruz was that
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a> would proceed to Ready as planned, and the
+multi-paramater add/multiply templates should be renamed as
+<tt>ratio_sum</tt> and <tt>ratio_product</tt> to avoid the problem
+mixing template aliases with partial specializations.
 </p>
+
 <p>
-Note that Boost has applied the non-explicit conversion operator for many
-years as it has valuable properties for extension into other metaprogramming
-libraries, such as MPL.  If additional rationale is desired I will poll the
-Boost lists for why this extension was originally applied.  I would argue
-that explicit conversion is more appropriate for 0x though.
+It was also suggested to close this issue as NAD Future as it does not
+correspond directly to any NB comment.  NBs are free to submit a
+specific comment (and re-open) in CD2 though.
 </p>
-</blockquote>
-
-<p><i>[
-2009-07-04 Howard adds:
-]</i></p>
 
-
-<blockquote>
 <p>
-Here's a use case which demonstrates the syntactic niceness which Alisdair describes:
+Walter Brown also had concerns on better directing the order of
+evaluation to avoid overflows if we do proceed for 0x rather than TR1,
+so wording may not be complete yet.
 </p>
 
-<blockquote><pre>#define requires(...) class = typename std::enable_if&lt;(__VA_ARGS__)&gt;::type
+<p><i>[
+Alisdair updates wording.
+]</i></p>
+
 
-template &lt;class T, class U,
-    requires(!is_lvalue_reference&lt;T&gt;() ||
-              is_lvalue_reference&lt;T&gt;() &amp;&amp; is_lvalue_reference&lt;U&gt;()),
-    requires(is_same&lt;typename base_type&lt;T&gt;::type,
-                     typename base_type&lt;U&gt;::type&gt;)&gt;
-inline
-T&amp;&amp;
-forward(U&amp;&amp; t)
-{
-    return static_cast&lt;T&amp;&amp;&gt;(t);
-}
-</pre></blockquote>
 </blockquote>
 
 <p><i>[
-2009-07 post-Frankfurt:
+2009-10-30 Howard:
 ]</i></p>
 
 
 <blockquote>
-Move to Tentatively Ready.
+Moved to Tentatively NAD Future after 5 positive votes on c++std-lib.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
+
 <p>
-Add to the <tt>integral_constant</tt> struct definition in 20.6.3 [meta.help]:
+Add the following type traits to p3 20.4 [ratio]
 </p>
 
-<blockquote><pre>template &lt;class T, T v&gt;
-struct integral_constant {
-  static const<ins>expr</ins> T value = v;
-  typedef T value_type;
-  typedef integral_constant&lt;T,v&gt; type;
-  <ins>constexpr operator value_type() { return value; }</ins>
-};
+<blockquote><pre>// ratio arithmetic
+template &lt;class R1, class R2&gt; struct ratio_add;
+template &lt;class R1, class R2&gt; struct ratio_subtract;
+template &lt;class R1, class R2&gt; struct ratio_multiply;
+template &lt;class R1, class R2&gt; struct ratio_divide;
+<ins>template &lt;class R1, class ... RList&gt; struct ratio_sum;</ins>
+<ins>template &lt;class R1, class ... RList&gt; struct ratio_product;</ins>
 </pre></blockquote>
 
+<p>
+after 20.4.2 [ratio.arithmetic] p1: add
+</p>
 
+<blockquote><pre>template &lt;class R1, class ... RList&gt; struct ratio_sum; // declared, never defined
 
+template &lt;class R1&gt; struct ratio_sum&lt;R1&gt; : R1 {};
+</pre>
 
+<blockquote>
+<i>Requires:</i> <tt>R1</tt> is a specialization of class template <tt>ratio</tt>
+</blockquote>
 
-<hr>
-<h3><a name="1020"></a>1020. Response to UK 204</h3>
-<p><b>Section:</b> 20.6.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-03-12</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 204</b></p>
-
-<p>
-It is not possible to create a variant union based on a parameter pack
-expansion, e.g. to implement a classic discriminated union template. 
-</p>
+<pre>template &lt;class R1, class R2, class ... RList&gt; 
+ struct ratio_sum&lt;R1, R2, RList...&gt;
+   : ratio_add&lt; R1, ratio_sum&lt;R2, RList...&gt;&gt; {
+};
+</pre>
 
-<p><b>Original proposed resolutuion:</b></p>
+<blockquote>
+<i>Requires:</i> <tt>R1</tt> and each element in parmater pack
+<tt>RList</tt> is a specialization of class template <tt>ratio</tt>
+</blockquote>
+</blockquote>
 
 <p>
-Restore <tt>aligned_union</tt> template that was removed by LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>. 
+after 20.4.2 [ratio.arithmetic] p3: add
 </p>
 
-<p><i>[
-Summit:
-]</i></p>
+<blockquote><pre>template &lt;class R1, class ... RList&gt; struct ratio_product; // declared, never defined
 
+template &lt;class R1&gt; struct ratio_product&lt;R1&gt; : R1 {};
+</pre>
 
 <blockquote>
-Agree. The need for <tt>aligned_union</tt> is compelling enough to reinstate.
+<i>Requires:</i> <tt>R1</tt> is a specialization of class template <tt>ratio</tt>
 </blockquote>
 
-<p><i>[
-Post Summit, Alisdair adds:
-]</i></p>
-
+<pre>template &lt;class R1, class R2, class ... RList&gt; 
+ struct ratio_sum&lt;R1, R2, RList...&gt;
+   : ratio_add&lt; R1, ratio_product&lt;R2, RList...&gt;&gt; {
+};
+</pre>
 
 <blockquote>
-paper
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2843.html">N2843</a>
-proposes an extension to the <tt>[[align]]</tt> attribute
-that further diminishes the need for this template.  Recommend NAD.
+<i>Requires:</i> <tt>R1</tt> and each element in parmater pack
+<tt>RList</tt> is a specialization of class template <tt>ratio</tt>
+</blockquote>
 </blockquote>
 
 
 
-<p><b>Proposed resolution:</b></p>
 
 
 
 
 
 <hr>
-<h3><a name="1030"></a>1030. Response to JP 44</h3>
-<p><b>Section:</b> 20.8.10.6 [util.smartptr.shared.atomic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1123"></a>1123. no requirement that standard streams be flushed</h3>
+<p><b>Section:</b> 27.5.2.1.6 [ios::Init] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> James Kanze <b>Opened:</b> 2009-05-14  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::Init">issues</a> in [ios::Init].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses JP 44</b></p>
-
-<p>
-The 1st parameter <tt>p</tt> and 2nd parameter <tt>v</tt> is now
-<tt>shared_ptr&lt;T&gt;*</tt>.
-</p>
 <p>
-It should be <tt>shared_ptr&lt;T&gt;&amp;</tt>, or if these are
-<tt>shared_ptr&lt;T&gt;*</tt> then add the "<tt>p</tt> shall not be a
-null pointer" at the requires.
+As currently formulated, the standard doesn't require that there 
+is ever a flush of <tt>cout</tt>, etc.  (This implies, for example, that 
+the classical hello, world program may have no output.)  In the 
+current draft
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>),
+there is a requirement that the objects 
+be constructed before <tt>main</tt>, and before the dynamic 
+initialization of any non-local objects defined after the 
+inclusion of <tt>&lt;iostream&gt;</tt> in the same translation unit.  The only 
+requirement that I can find concerning flushing, however, is in 
+27.5.2.1.6 [ios::Init], where the destructor of the last 
+<tt>std::ios_base::Init</tt> object flushes.  But there is, as far as I 
+can see, no guarantee that such an object ever exists. 
+</p>
+<p>
+Also, the wording in  [iostreams.objects] says that:
+</p>
+<blockquote>
+The objects 
+are constructed and the associations are established at some 
+time prior to or during the first time an object of class 
+<tt>ios_base::Init</tt> is constructed, and in any case before the body 
+of main begins execution.
+</blockquote>
+<p>
+In 27.5.2.1.6 [ios::Init], however, as an 
+effect of the constructor, it says that
+</p>
+<blockquote>
+If <tt>init_cnt</tt> is zero, 
+the function stores the value one in <tt>init_cnt</tt>, then constructs 
+and initializes the objects <tt>cin</tt>, <tt>cout</tt>, <tt>cerr</tt>, <tt>clog</tt> 
+<tt>wcin</tt>, <tt>wcout</tt>, <tt>wcerr</tt>, and <tt>wclog</tt>"
+</blockquote>
+
+<p>
+which seems to forbid earlier 
+construction. 
+</p>
+
+<p>
+(Note that with these changes, the exposition only "<tt>static 
+int init_cnt</tt>" in <tt>ios_base::Init</tt> can be dropped.) 
+</p>
+<p>
+Of course, a determined programmer can still inhibit the 
+flush with things like: 
+</p>
+<blockquote><pre>new std::ios_base::Init ;       //  never deleted 
+</pre></blockquote>
+<p>
+or (in a function): 
+</p>
+<blockquote><pre>std::ios_base::Init ensureConstruction ; 
+//  ... 
+exit( EXIT_SUCCESS ) ; 
+</pre></blockquote>
+<p>
+Perhaps some words somewhere to the effect that all 
+<tt>std::ios_base::Init</tt> objects should have static lifetime 
+would be in order. 
 </p>
 
 <p><i>[
-Summit:
+2009 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Agree. All of the functions need a requirement that <tt>p</tt> (or
-<tt>v</tt>) is a pointer to a valid object.
+Moved to Ready.  Some editorial changes are expected (in addition to the
+proposed wording) to remove <tt>init_cnt</tt> from <tt>Init</tt>.
 </blockquote>
 
-<p><i>[
-2009-07 post-Frankfurt:
-]</i></p>
 
 
-<blockquote>
+<p><b>Proposed resolution:</b></p>
 <p>
-Lawrence explained that these signatures match the regular atomics. The
-regular atomics must not use references because these signatures are
-shared with C. The decision to pass shared_ptrs by pointer rather than
-by reference was deliberate and was motivated by the principle of least
-surprise.
+Change 27.4 [iostream.objects]/2:
 </p>
+
+<blockquote>
+-2- The objects are constructed and the associations are established at
+some time prior to or during the first time an object of class
+<tt>ios_base::Init</tt> is constructed, and in any case before the body
+of main begins execution.<sup>292</sup> The objects are not destroyed
+during program execution.<sup>293</sup>
+<del>If a translation unit includes
+<tt>&lt;iostream&gt;</tt> or explicitly constructs an
+<tt>ios_base::Init</tt> object, these stream objects shall be
+constructed before dynamic initialization of non-local objects defined
+later in that translation unit.</del>
+<ins>The results of including <tt>&lt;iostream&gt;</tt> in a translation
+unit shall be as if <tt>&lt;iostream&gt;</tt> defined an instance of
+<tt>ios_base::Init</tt> with static lifetime. Similarly, the entire
+program shall behave as if there were at least one instance of
+<tt>ios_base::Init</tt> with static lifetime.</ins>
+</blockquote>
+
 <p>
-Lawrence to write wording that requires that the pointers not be null.
+Change 27.5.2.1.6 [ios::Init]/3:
 </p>
+
+<blockquote>
+<pre>Init();
+</pre>
+<blockquote>
+-3- <i>Effects:</i> Constructs an object of class <tt>Init</tt>. 
+<del>If <tt>init_cnt</tt> is zero, the function stores the value one in
+<tt>init_cnt</tt>, then constructs and initializes the objects
+<tt>cin</tt>, <tt>cout</tt>, <tt>cerr</tt>, <tt>clog</tt> (27.4.1),
+<tt>wcin</tt>, <tt>wcout</tt>, <tt>wcerr</tt>, and <tt>wclog</tt>
+(27.4.2). In any case, the function then adds one to the value stored in
+<tt>init_cnt</tt>.</del>
+<ins>Constructs and initializes the objects <tt>cin</tt>, <tt>cout</tt>,
+<tt>cerr</tt>, <tt>clog</tt>, <tt>wcin</tt>, <tt>wcout</tt>,
+<tt>wcerr</tt> and <tt>wclog</tt> if they have not already been
+constructed and initialized.</ins>
+</blockquote>
 </blockquote>
 
+<p>
+Change 27.5.2.1.6 [ios::Init]/4:
+</p>
 
+<blockquote>
+<pre>~Init();
+</pre>
+<blockquote>
+-4- <i>Effects:</i> Destroys an object of class <tt>Init</tt>.
+<del>The function subtracts one from the value stored in <tt>init_cnt</tt> and,
+if the resulting stored value is one,</del>
+<ins>If there are no other instances of the class still in
+existance,</ins>
+calls <tt>cout.flush()</tt>,
+<tt>cerr.flush()</tt>, <tt>clog.flush()</tt>, <tt>wcout.flush()</tt>,
+<tt>wcerr.flush()</tt>, <tt>wclog.flush()</tt>.
+</blockquote>
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 
 
 
 
 
 <hr>
-<h3><a name="1031"></a>1031. Response to US 78</h3>
-<p><b>Section:</b> 20.8.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">Tentatively NAD Future</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Future">Tentatively NAD Future</a> status.</p>
+<h3><a name="1125"></a>1125. ostream_iterator does not work with movable types</h3>
+<p><b>Section:</b> 24.6.2.2 [ostream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28  <b>Last modified:</b> 2009-05-30</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
+<p>
+<tt>ostream_iterator</tt> has not been updated to support moveable types, in a
+similar manner to the insert iterators.
+Note that this is not a problem for <tt>ostreambuf_iterator</tt>, as the types it is
+restricted to dealing with do not support extra-efficient moving.
+</p>
 
-<p><b>Addresses US 78</b></p>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-There is presently no way to convert directly from a <tt>shared_ptr</tt> to a
-<tt>unique_ptr</tt>. Add an interface that performs the conversion. 
+Add second <tt>operator=</tt> overload to class <tt>template ostream_iterator</tt>
+in 24.6.2 [ostream.iterator], para 2:
 </p>
 
-<p><i>[
-Summit:
-]</i></p>
+<blockquote><pre>ostream_iterator&lt;T,charT,traits&gt;&amp; operator=(const T&amp; value);
+<ins>ostream_iterator&lt;T,charT,traits&gt;&amp; operator=(T&amp;&amp; value);</ins>
+</pre></blockquote>
 
+<p>
+Add a new paragraph: in 24.6.2.2 [ostream.iterator.ops]:
+</p>
 
 <blockquote>
-We look forward to a paper on this topic. We recommend no action until a
-paper is available. We believe that the shared pointer must use the default
-deleter for the conversion to succeed.
+<pre>ostream_iterator&amp; operator=(T&amp;&amp; value);
+</pre>
+<blockquote>
+<p>
+-2- <i>Effects:</i>
+</p>
+<blockquote><pre>*out_stream &lt;&lt; std::move(value);
+if(delim != 0)
+  *out_stream &lt;&lt; delim;
+return (*this);
+</pre></blockquote>
+</blockquote>
 </blockquote>
 
-<p><i>[
-Peter Dimov adds:
-]</i></p>
 
 
-<blockquote>
-This is basically a request for <tt>shared_ptr&lt;&gt;::release</tt> in
-disguise, with all the associated problems. Not a good idea.
-</blockquote>
 
-<p><i>[
-2009-07 post-Frankfurt:
-]</i></p>
 
 
-<blockquote>
+<hr>
+<h3><a name="1126"></a>1126. <tt>istreambuff_iterator::equal</tt> needs a const &amp; parameter</h3>
+<p><b>Section:</b> 24.6.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28  <b>Last modified:</b> 2009-11-02</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator::equal">issues</a> in [istreambuf.iterator::equal].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-The rationale for the omission of a release() member function from shared_ptr is given in:
-<a href="http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/shared_ptr.htm">http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/shared_ptr.htm</a>
+The <tt>equal</tt> member function of <tt>istreambuf_iterator</tt> is
+declared <tt>const</tt>, but takes its argument by non-const reference.
 </p>
 <p>
-The implementation of such a member is non-trivial (and maybe
-impossible), because it would need to account for the deleter.
+This is not compatible with the <tt>operator==</tt> free function overload, which is
+defined in terms of calling <tt>equal</tt> yet takes both arguments by reference to
+const.
 </p>
-</blockquote>
 
 <p><i>[
-2009-07-26 Howard sets to Tentatively NAD Future.
+The proposed wording is consistent with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a> with status TC1.
+]</i></p>
+
+
+<p><i>[
+2009-11-02 Howard adds:
 ]</i></p>
 
 
 <blockquote>
+Set to Tentatively Ready after 5 positive votes on c++std-lib.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-I took an online poll and got 3 votes for NAD and 3 for NAD Future.  Personally
-I prefer NAD Future as this does refer to an extension that could conceivably be
-considered beyond C++0X.
+Ammend in both:<br>
+24.6.3 [istreambuf.iterator]<br>
+24.6.3.5 [istreambuf.iterator::equal]<br>
 </p>
 
+<blockquote><pre>bool equal(<ins>const </ins>istreambuf_iterator&amp; b) const;
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1130"></a>1130. <tt>copy_exception</tt> name misleading</h3>
+<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-05-13  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-However such an extension would need to solve a couple of problems:
+The naming of <tt>std::copy_exception</tt> misleads almost everyone
+(experts included!) to think that it is the function that copies an
+<tt>exception_ptr</tt>:
 </p>
 
-<ol>
-<li>What is the interface for such a conversion when the <tt>shared_ptr</tt> does
-not have unique ownership?  Throw an exception?  Create a null <tt>unique_ptr</tt>?
-Undefined behavior?
-</li>
+<blockquote><pre>exception_ptr p1 = current_exception();
+exception_ptr p2 = copy_exception( p1 );
+</pre></blockquote>
 
-<li>
 <p>
-How does one handle custom deleters given to the <tt>shared_ptr</tt> constructor?
+But this is not at all what it does. The above actually creates an
+<tt>exception_ptr p2</tt> that contains a copy of <tt>p1</tt>, not of
+the exception to which <tt>p1</tt> refers!
 </p>
 <p>
-I do not believe it is possible to implement a general answer to this question.
-The <tt>shared_ptr</tt> deleter is a run time (or construction time) characteristic.
-The <tt>unique_ptr</tt> deleter is a compile time characteristic.  In general one
-can not know to what type of <tt>unqiue_ptr</tt> you are converting to.
+This is, of course, all my fault; in my defence, I used <tt>copy_exception</tt>
+because I was unable to think of a better name.
 </p>
 <p>
-One answer is for the user of the conversion to specify the deleter type and perhaps
-throw an exception if the specification turns out to be incorrect.
+But I believe that, based on what we've seen so far, <em>any</em> other name would be better.
 </p>
 <p>
-Another answer is for the conversion to only be valid when the underlying deleter
-is <tt>default_delete</tt>.  We would probalby need to specify that this is indeed the
-underlying deleter of a <tt>shared_ptr</tt> when a custom deleter is not given in
-the constructor.
+Therefore, I propose <tt>copy_exception</tt> to be renamed to
+<tt>create_exception</tt>:
 </p>
-</li>
-</ol>
+
+<blockquote><pre>template&lt;class E&gt; exception_ptr create_exception(E e);
+</pre></blockquote>
 
 <p>
-At any rate, there are non-trivial design issues which would need to be implemented
-and tested in the field for usability prior to standardization.
+with the following explanatory paragraph after it:
 </p>
-</blockquote>
-
 
+<blockquote>
+Creates an <tt>exception_ptr</tt> that refers to a copy of <tt>e</tt>.
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
+<p><i>[
+2009-05-13 Daniel adds:
+]</i></p>
 
 
+<blockquote>
+<p>
+What about
+</p>
+<blockquote><pre>make_exception_ptr
+</pre></blockquote>
+<p>
+in similarity to <tt>make_pair</tt> and <tt>make_tuple</tt>, <tt>make_error_code</tt> and
+<tt>make_error_condition</tt>, or <tt>make_shared</tt>? Or, if a stronger symmetry to
+<tt>current_exception</tt> is preferred:
+</p>
 
-
-
-<hr>
-<h3><a name="1033"></a>1033. <tt>thread::join()</tt> effects?</h3>
-<p><b>Section:</b> 30.3.1.5 [thread.thread.member] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.member">active issues</a> in [thread.thread.member].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.member">issues</a> in [thread.thread.member].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-While looking at <tt>thread::join()</tt> I think I spotted a couple of
-possible defects in the specifications. I could not find a previous
-issue or NB comment about that, but I might have missed it.
-</p>
-
-<p>
-The postconditions clause for <tt>thread::join()</tt> is:
-</p>
-
-<blockquote>
-<i>Postconditions:</i> If <tt>join()</tt> throws an exception, the value
-returned by <tt>get_id()</tt> is unchanged. Otherwise, <tt>get_id() == id()</tt>.
-</blockquote>
-
-<p>
-and the throws clause is:
-</p>
-
-<blockquote>
-<i>Throws:</i> <tt>std::system_error</tt> when the postconditions cannot be achieved.
-</blockquote>
-
-<p>
-Now... how could the postconditions <em>not</em> be achieved?
-It's just a matter of resetting the value of <tt>get_id()</tt> or leave it
-unchanged! I bet we can always do that. Moreover, it's a chicken-and-egg
-problem: in order to decide whether to throw or not I depend on the
-postconditions, but the postconditions are different in the two cases.
-</p>
-
+<blockquote><pre>make_exception
+</pre></blockquote>
 <p>
-I believe the throws clause should be:
+We have not a single <tt>create_*</tt> function in the library, it was always
+<tt>make_*</tt> used.
 </p>
-
-<blockquote>
-<i>Throws:</i> <tt>std::system_error</tt> when the effects or postconditions
-cannot be achieved.
 </blockquote>
 
-<p>
-as it is in <tt>detach()</tt>, or, even better, as the postcondition is
-trivially satisfiable and to remove the circular dependency:
-</p>
+<p><i>[
+2009-05-13 Peter adds:
+]</i></p>
 
 
 <blockquote>
-<i>Throws:</i> <tt>std::system_error</tt> if the effects cannot be achieved.
+<tt>make_exception_ptr</tt> works for me.
 </blockquote>
 
-<p>
-Problem is that... ehm... <tt>join()</tt> has no "Effects" clause. Is that intentional?
-</p>
-
 <p><i>[
-See the thread starting at c++std-lib-23204 for more discussion.
+2009-06-02 Thomas J. Gritzan adds:
 ]</i></p>
 
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
-
 <blockquote>
 <p>
-Pete believes there may be some more general language (in frontmatter)
-that can address this and related issues such as <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>.
+To avoid surprises and unwanted recursion, how about making a call to
+<tt>std::make_exception_ptr</tt> with an <tt>exception_ptr</tt> illegal?
 </p>
 <p>
-Move to Open.
+It might work like this:
 </p>
+<blockquote><pre>template&lt;class E&gt;
+exception_ptr make_exception_ptr(E e);
+template&lt;&gt;
+exception_ptr make_exception_ptr&lt;exception_ptr&gt;(exception_ptr e) = delete;
+</pre></blockquote>
 </blockquote>
 
-
-<p><b>Proposed resolution:</b></p>
-
-
+<p><i>[
+2009 Santa Cruz:
+]</i></p>
 
 
+<blockquote>
+Move to Review for the time being. The subgroup thinks this is a good
+idea, but doesn't want to break compatibility unnecessarily if someone
+is already shipping this. Let's talk to Benjamin and PJP tomorrow to
+make sure neither objects.
+</blockquote>
 
-<hr>
-<h3><a name="1034"></a>1034. Response to UK 222</h3>
-<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 
-<p><b>Addresses UK 222</b></p>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-It is not clear what purpose the Requirement tables serve in the
-Containers clause. Are they the definition of a library Container? Or
-simply a conventient shorthand to factor common semantics into a single
-place, simplifying the description of each subsequent container? This
-becomes an issue for 'containers' like <tt>array</tt>, which does not meet the
-default-construct-to-empty requirement, or <tt>forward_list</tt> which does not
-support the size operation. Are these components no longer containers?
-Does that mean the remaining requirements don't apply? Or are these
-contradictions that need fixing, despite being a clear design decision?
+Change 18.8.5 [propagation]:
 </p>
 
-<p>
-Recommend:
-</p>
+<blockquote>
+<pre>template&lt;class E&gt; exception_ptr <del>copy_exception</del><ins>make_exception_ptr</ins>(E e);
+</pre>
 
+<blockquote>
 <p>
-Clarify all the tables in 23.2 [container.requirements] are
-there as a convenience for documentation, rather than a strict set of
-requirements. Containers should be allowed to relax specific
-requirements if they call attention to them in their documentation. The
-introductory text for <tt>array</tt> should be expanded to mention a
-default constructed <tt>array</tt> is not empty, and
-<tt>forward_list</tt> introduction should mention it does not provide
-the required <tt>size</tt> operation as it cannot be implemented
-efficiently.
+-11- <i>Effects:</i> <ins>Creates an <tt>exception_ptr</tt> that refers
+to a copy of <tt>e</tt>,</ins> as if
 </p>
 
-<p><i>[
-Summit:
-]</i></p>
-
+<blockquote><pre>try {
+  throw e;
+} catch(...) {
+  return current_exception();
+}
+</pre></blockquote>
 
-<blockquote>
-Agree in principle.
+<p>...</p>
 </blockquote>
 
-<p><i>[
-2009-07 post-Frankfurt:
-]</i></p>
-
-
-<blockquote>
-We agree in principle, but we have a timetable. This group feels that
-the issue should be closed as NAD unless a proposed resolution is
-submitted prior to the March 2010 meeting.
 </blockquote>
 
 
 
-<p><b>Proposed resolution:</b></p>
-
-
 
 
 
 <hr>
-<h3><a name="1035"></a>1035. Response to UK 226</h3>
-<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-08-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1131"></a>1131. C++0x does not need <tt>alignment_of</tt></h3>
+<p><b>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2009-06-01  <b>Last modified:</b> 2009-06-02</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 226</b></p>
-
 <p>
-<tt>&lt;array&gt;</tt> must be added to this list. In particular it
-doesn't satisfy: - no <tt>swap()</tt> function invalidates any
-references, pointers, or iterators referring to the elements of the
-containers being swapped. and probably doesn't satisfy: - no
-<tt>swap()</tt> function throws an exception.
+The <tt>alignment_of</tt> template is no longer necessary, now that the
+core language will provide <tt>alignof</tt>. Scott Meyers raised this
+issue at comp.std.c++,
+<a href="http://groups.google.com/group/comp.std.c++/browse_thread/thread/9b020306e803f08a">C++0x: alignof vs. alignment_of</a>,
+May 21, 2009.  In a reply, Daniel Krügler pointed out that
+<tt>alignof</tt> was added to the working paper <i>after</i>
+<tt>alignment_of</tt>. So it appears that <tt>alignment_of</tt> is only
+part of the current Working Draft 
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>)
+because it is in TR1.
 </p>
 <p>
-If <tt>&lt;array&gt;</tt> remains a container, this will have to also
-reference <tt>array</tt>, which will then have to say which of these
-points it satisfies.
+Having both <tt>alignof</tt> and <tt>alignment_of</tt> would cause
+unwanted confusion. In general, I think TR1 functionality should not be
+brought into C++0x if it is entirely redundant with other C++0x language
+or library features.
 </p>
 
-<p><i>[
-Summit:
-]</i></p>
-
-
-<blockquote>
-Agree. The proposed resolution is incomplete. Further work required.
-</blockquote>
-
-<p><i>[
-2009-05-01 Daniel adds:
-]</i></p>
-
-
-<blockquote>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a> also suggests
-adding move constructor to this.
-</blockquote>
-
-<p><i>[
-2009-07 post-Frankfurt:
-]</i></p>
-
-
-<blockquote>
-Howard is to draft a note that explains what happens to references.
-</blockquote>
-
-
-
-<p><i>[
-2009-08-01 Howard provided wording.
-]</i></p>
-
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add a paragraph to 23.3.1.2 [array.special]:
+Remove from Header &lt;type_traits&gt; synopsis 20.6.2 [meta.type.synop]:
 </p>
+<blockquote><pre><del>template &lt;class T&gt; struct alignment_of;</del>
+</pre></blockquote>
 
-<blockquote><pre>template &lt;Swappable T, size_t N&gt; void swap(array&lt;T,N&gt;&amp; x, array&lt;T,N&gt;&amp; y);
-</pre>
-<blockquote>
 <p>
-<i>Effects:</i>
+Remove the first row of Table 34 ("Type property queries"), from
+Type properties 20.6.4.3 [meta.unary.prop]:
 </p>
-<blockquote><pre>swap_ranges(x.begin(), x.end(), y.begin());
-</pre></blockquote>
-
-<p><ins>
-[<i>Note:</i>
-Outstanding iterators, references and pointers may be invalidated.
-&#8212; <i>end note</i>]
-</ins></p>
+<blockquote>
+<table border="1">
+<caption>Table 34 -- Type property queries</caption>
+<tbody><tr>
+<td><del><tt>template &lt;class T&gt; struct alignment_of;</tt></del></td>
+<td><del><tt>alignof(T)</tt>.</del><br>
+<del><i>Precondition:</i> <tt>T</tt> shall be a complete type, a reference
+type, or an array of unknown bound, but shall not be a function type or
+(possibly cv-qualified) <tt>void</tt>.</del>
+</td>
+</tr>
+</tbody></table>
 </blockquote>
+
+<p>
+Change text in Table 41 ("Other transformations"), from Other
+transformations 20.6.7 [meta.trans.other], as follows:
+</p>
+<blockquote>
+<table border="1">
+<caption>Table 41 -- Other transformations</caption>
+<tbody><tr><td>...</td>
+<td>
+ Align shall be equal to <tt>
+ <del>alignment_of&lt;T&gt;::value</del>
+ <ins>alignof(T)</ins>
+ </tt> for some type <tt>T</tt> or to <i>default-alignment</i>.
+</td>
+<td>...</td>
+</tr></tbody></table>
 </blockquote>
 
 
@@ -23338,293 +19537,122 @@ Outstanding iterators, references and pointers may be invalidated.
 
 
 <hr>
-<h3><a name="1041"></a>1041. Response to UK 239</h3>
-<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1133"></a>1133. Does N2844 break current specification of list::splice?</h3>
+<p><b>Section:</b> 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-09  <b>Last modified:</b> 2009-10-27</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 239</b></p>
-
 <p>
-It is not possible to take a move-only key out of an unordered
-container, such as (<tt>multi</tt>)<tt>set</tt> or
-(<tt>multi</tt>)<tt>map</tt>, or the new unordered containers.
+IIUC,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
+means that lvalues will no longer bind to rvalue references.
+Therefore, the current specification of <tt>list::splice</tt> (list
+operations 23.3.4.4 [list.ops]) will be a breaking change of behaviour for existing
+programs.  That is because we changed the signature to swallow via an rvalue
+reference rather than the lvalue reference used in 03.
 </p>
-
 <p>
-Add below <tt>a.erase(q)</tt>, <tt>a.extract(q)</tt>, with the following notation:
+Retaining this form would be safer, requiring an explicit move when splicing
+from lvalues.  However, this will break existing programs.
+We have the same problem with <tt>forward_list</tt>, although without the risk of
+breaking programs so here it might be viewed as a positive feature.
 </p>
 <p>
-<tt>a.extract(q)&gt;</tt>, Return type <tt>pair&lt;key, iterator&gt;</tt>
-Extracts the element pointed to by <tt>q</tt> and erases it from the
-<tt>set</tt>. Returns a <tt>pair</tt> containing the value pointed to by
-<tt>q</tt> and an <tt>iterator</tt> pointing to the element immediately
-following <tt>q</tt> prior to the element being erased. If no such
-element exists,returns <tt>a.end()</tt>.
+The problem signatures:
 </p>
+<blockquote><pre>void splice_after(const_iterator position, forward_list&lt;T,Alloc&gt;&amp;&amp; x);
+void splice_after(const_iterator position, forward_list&lt;T,Alloc&gt;&amp;&amp; x,
+                  const_iterator i);
+void splice_after(const_iterator position, forward_list&lt;T,Alloc&gt;&amp;&amp; x,
+                  const_iterator first, const_iterator last);
 
-<p><i>[
-Summit:
-]</i></p>
-
-
-<blockquote>
-We look forward to a paper on this topic. We recommend no action until a
-paper is available. The paper would need to address exception safety.
-</blockquote>
-
-<p><i>[
-Post Summit Alisdair adds:
-]</i></p>
-
-
-<blockquote>
-Would <tt>value_type</tt> be a better return type than <tt>key_type</tt>?
-</blockquote>
-
-<p><i>[
-2009-07 post-Frankfurt:
-]</i></p>
-
-
-<blockquote>
-Leave Open. Alisdair to contact Chris Jefferson about this.
-</blockquote>
-
+void splice(const_iterator position, list&lt;T,Alloc&gt;&amp;&amp; x);
+void splice(const_iterator position, list&lt;T,Alloc&gt;&amp;&amp; x,
+            const_iterator i);
+void splice(const_iterator position, list&lt;T,Alloc&gt;&amp;&amp; x,
+            const_iterator first, const_iterator last);
+</pre></blockquote>
 
+<b>Possible resolutions:</b>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-In 23.2.4 [associative.reqmts] Table 85, add:
+Option A.   Add an additional (non-const) lvalue-reference
+overload in each case
 </p>
-
-<blockquote>
-<table border="1">
-<caption>Table 85 --  Associative container requirements (in addition to container)</caption>
-<tbody><tr>
-<th>Expression</th>
-<th>Return type</th>
-<th>Assertion/note<br>pre-/post-condition</th>
-<th>Complexity</th>
-</tr>
-<tr><td><tt>a.erase(q)</tt></td>
-<td>...</td>
-<td>...</td>
-<td>...</td>
-</tr><tr>
-<td><ins><tt>a.extract(q)</tt></ins></td>
-<td><ins><tt>pair&lt;key_type, iterator&gt;</tt></ins></td>
-<td><ins>Extracts the element pointed to by <tt>q</tt> and erases it from the <tt>set</tt>. 
-Returns a <tt>pair</tt> containing the value pointed to by <tt>q</tt> and an <tt>iterator</tt>
-pointing to the element immediately following <tt>q</tt> prior to the element being
-erased. If no such element 
-exists, returns <tt>a.end()</tt>.</ins></td>
-<td><ins>amortized constant</ins></td>
-</tr>
-</tbody></table>
-</blockquote>
-
 <p>
-In 23.2.5 [unord.req] Table 87, add:
+Option B.   Change rvalue reference back to (non-const)
+lvalue-reference overload in each case
 </p>
-
-<blockquote>
-<table border="1">
-<caption>Table 87 -- Unordered associative container requirements (in addition to container)</caption>
-<tbody><tr>
-<th>Expression</th>
-<th>Return type</th>
-<th>Assertion/note<br>pre-/post-condition</th>
-<th>Complexity</th>
-</tr>
-<tr><td><tt>a.erase(q)</tt></td>
-<td>...</td>
-<td>...</td>
-<td>...</td>
-</tr><tr>
-<td><ins><tt>a.extract(q)</tt></ins></td>
-<td><ins><tt>pair&lt;key_type, iterator&gt;</tt></ins></td>
-<td><ins>Extracts the element pointed to by <tt>q</tt> and erases it from the <tt>set</tt>. 
-Returns a <tt>pair</tt> containing the value pointed to by <tt>q</tt> and an <tt>iterator</tt>
-pointing to the element immediately following <tt>q</tt> prior to the element being
-erased. If no such element 
-exists, returns <tt>a.end()</tt>.</ins></td>
-<td><ins>amortized constant</ins></td>
-</tr>
-</tbody></table>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="1042"></a>1042. Response to UK 244</h3>
-<p><b>Section:</b> 23.3 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequences">issues</a> in [sequences].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 244</b></p>
-
 <p>
-The validity of the expression <tt>&amp;a[n] == &amp;a[0] + n</tt> is contingent on
-<tt>operator&amp;</tt> doing the "right thing" (as captured by the <tt>CopyConstructible</tt>
-requirements in table 30 in C++2003). However this constraint has been
-lost in the Concepts of C++0x. This applies to <tt>vector</tt> and <tt>array</tt> (it
-actually applies to <tt>string</tt> also, but that's a different chapter, so I'll
-file a separate comment there and cross-reference).
+Option C.   Add an additional (non-const) lvalue-reference
+overload in just the <tt>std::list</tt> cases
+</p>
+<p>
+I think (B) would be very unfortunate, I really like the <tt>forward_list</tt>
+behaviour in (C) but feel (A) is needed for consistency.
 </p>
-
 <p>
-Suggested solution:
+My actual preference would be NAD, ship with this as a breaking change as it
+is a more explicit interface.  I don't think that will fly though!
 </p>
 
 <p>
-Define a <tt>ContiguousStrorage</tt> and apply it to
-<tt>vector</tt>, <tt>array</tt> and <tt>string</tt>.
+See the thread starting with c++std-lib-23725 for more discussion.
 </p>
 
 <p><i>[
-Summit:
-]</i></p>
-
-
-<blockquote>
-Agree with the issue but not the details of the proposed solution. Walter to
-provide wording for the new concept.
-</blockquote>
-
-<p><i>[
-Post Summit Alisdair adds:
-]</i></p>
-
-
-<blockquote>
-Another LWG subgroup wondered if this concept
-should extend to <tt>complex&lt;T&gt;</tt>, and so not be built on the container concept at
-all?
-</blockquote>
-
-<p><i>[
-2009-07 post-Frankfurt:
+2009-10-27 Christopher Jefferson provides proposed wording for Option C.
 ]</i></p>
 
 
-<blockquote>
-Leave Open, pending a post-Concepts Working Draft.
-</blockquote>
-
-
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add to <tt>&lt;container_concepts&gt;</tt> synopsis in 23.2.6 [container.concepts]
-</p>
-
-<blockquote><pre><ins>concept&lt; typename C &gt; ContiguousStorageContainer <i>see below</i>;</ins>
-</pre></blockquote>
-
-<p>
-Add a new section to the end of 23.2.6 [container.concepts]
-</p>
-
-<blockquote>
-<p>
-23.1.6.x ContiguousStorageContainer concept [container.concepts.contiguous]
+In 23.3.4 [list]
 </p>
 
-<pre>concept ContiguousStorageContainer&lt; typename C &gt;
-  : Container&lt;C&gt;
-{
-  value_type* data(C&amp;);
-
-  axiom Contiguity(C&amp; c, size_type i) {
-    if( i &lt; size(c) ) {
-         addressof( * (data(c) + i) )
-      == addressof( * advance(data(c), i) );
-    }
-  }
-}
-</pre>
-
 <p>
-The <tt>ContiguousStorageContainer</tt> concept describes a container whose elements
-are allocated in a single region of memory, and are stored sequentially
-without intervening padding other than to meet alignment requirements.
-For example, the elements may be stored in a
-single array of suitable length.
+Add lvalue overloads before rvalue ones:
 </p>
 
-<pre>value_type * data( C&amp; );
-</pre>
-
-<blockquote>
-<i>Returns:</i> a pointer to the first element in the region of storage.
-Result is unspecified for an empty container.
-</blockquote>
-
-</blockquote>
+<blockquote><pre><ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x);</ins>
+void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x);
+<ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x, const_iterator i);</ins>
+void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
+<ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x,
+            const_iterator first, const_iterator last);</ins>
+void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x,
+            const_iterator first, const_iterator last);
+</pre></blockquote>
 
 <p>
-Change 23.3.1 [array] p1:
+In 23.3.4.4 [list.ops], similarly add lvalue overload before each rvalue one:
 </p>
-
-<blockquote>
--1- The header <tt>&lt;array&gt;</tt> defines a class template for
-storing fixed-size sequences of objects. An <tt>array</tt> supports
-random access iterators. An instance of <tt>array&lt;T, N&gt;</tt>
-stores <tt>N</tt> elements of type <tt>T</tt>, so that <tt>size() ==
-N</tt> is an invariant. The elements of an <tt>array</tt> are stored
-contiguously, meaning that <del>if <tt>a</tt> is</del> an
-<tt>array&lt;T, N&gt;</tt> <del>then it obeys the identity <tt>&amp;a[n]
-== &amp;a[0] + n</tt> for all <tt>0 &lt;= n &lt; N</tt></del>
-<ins>satisfies the concept <tt>ContiguousStorageContainer&lt; array&lt;T,
-N&gt;&gt;</tt></ins>.
-</blockquote>
-
 <p>
-Add to the synopsis in 23.3.1 [array]:
+(After paragraph 2)
 </p>
 
-<blockquote><pre>    ...
-    T * data(); 
-    const T * data() const; 
-  };
-
-  <ins>template&lt; typename T, size_t N &gt;</ins>
-    <ins>concept_map ContiguousStorageContainer&lt; array&lt;T, N&gt;&gt; {};</ins>
-} 
+<blockquote><pre><ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x);</ins>
+void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x);
 </pre></blockquote>
 
 <p>
-Change 23.3.6 [vector] p1:
+(After paragraph 6)
 </p>
 
-<blockquote>
-A <tt>vector</tt> is a sequence container that supports random access
-iterators. In addition, it supports (amortized) constant time insert and
-erase operations at the end; insert and erase in the middle take linear
-time. Storage management is handled automatically, though hints can be
-given to improve efficiency. The elements of a vector are stored
-contiguously, meaning that <del>if <tt>v</tt> is</del> a
-<tt>vector&lt;T, Alloc&gt;</tt> <ins>(</ins>where <tt>T</tt> is some
-type other than <tt>bool</tt><ins>)</ins><del>, then it obeys the
-identity <tt>&amp;v[n] == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt;
-v.size()</tt></del> <ins>satisfies the concept <tt>ContiguousStorageContainer&lt;
-vector&lt; T, Alloc&gt;&gt;</tt></ins>.
-</blockquote>
+<blockquote><pre><ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x, const_iterator i);</ins>
+void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
+</pre></blockquote>
 
 <p>
-Add at the end of the synopsis in 23.3.6 [vector] p2:
+(After paragraph 10)
 </p>
 
-<blockquote><pre><ins>template&lt; typename T, typename A &gt;
-  requires !SameType&lt; T, bool &gt;
-  concept_map ContiguousStorageContainer&lt; vector&lt;T, A&gt;&gt; {};</ins>
+<blockquote><pre><ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x,
+            const_iterator first, const_iterator last);</ins>
+void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x,
+            const_iterator first, const_iterator last);
 </pre></blockquote>
 
 
@@ -23633,951 +19661,749 @@ Add at the end of the synopsis in 23.3.6 [vector] p2:
 
 
 <hr>
-<h3><a name="1043"></a>1043. Response to US 91</h3>
-<p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types.operations">active issues</a> in [atomics.types.operations].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="1134"></a>1134. Redundant specification of stdint.h, fenv.h, tgmath.h, and maybe complex.h</h3>
+<p><b>Section:</b> 18.4.2 [stdinth], 26.3.2 [fenv], 26.8 [c.math], 26.4.11 [cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2009-05-26  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses US 91</b></p>
-
 <p>
-It is unclear whether or not a failed <tt>compare_exchange</tt> is a RMW operation
-(as used in 1.10 [intro.multithread]).
+This is probably editorial.
 </p>
-
 <p>
-Suggested solution:
+The following items should be removed from the draft, because they're
+redundant with Annex D, and they arguably make some *.h headers
+non-deprecated:
 </p>
-
 <p>
-Make failing <tt>compare_exchange</tt> operations <b>not</b> be RMW.
+18.4.2 [stdinth] (regarding <tt>&lt;stdint.h&gt;</tt>) 
+</p>
+<p>
+26.3.2 [fenv] (regarding <tt>&lt;fenv.h&gt;</tt>
+</p>
+<p>
+Line 3 of 26.8 [c.math] (regarding <tt>&lt;tgmath.h&gt;</tt>) 
+</p>
+<p>
+26.4.11 [cmplxh] (regarding <tt>&lt;complex.h&gt;</tt>, though the note in this subclause is not redundant) 
 </p>
 
 <p><i>[
-Anthony Williams adds:
-]</i></p>
-
-
-<blockquote>
-In 29.6 [atomics.types.operations] p18 it says that "These
-operations are atomic read-modify-write operations" (final sentence).
-This is overly restrictive on the implementations of
-<tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> on platforms without a
-native CAS instruction.
-</blockquote>
-
-
-<p><i>[
-Summit:
+2009-06-10 Ganesh adds:
 ]</i></p>
 
 
 <blockquote>
-Group agrees with the resolution as proposed by Anthony Williams in the attached note.
-</blockquote>
-
-<p><i>[
-Batavia (2009-05):
-]</i></p>
-
-<blockquote>
-We recommend the proposed resolution be reviewed
-by members of the Concurrency Subgroup.
+While searching for <tt>stdint</tt> in the CD, I found that <tt>&lt;stdint.h&gt;</tt> is also
+mentioned in 3.9.1 [basic.fundamental] /5. It guess it should refer to
+<tt>&lt;cstdint&gt;</tt> instead.
 </blockquote>
 
 <p><i>[
-2009-07 post-Frankfurt:
+2009 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-This is likely to be addressed by Lawrence's upcoming paper. He will
-adopt the proposed resolution.
+Real issue. Maybe just editorial, maybe not. Move to Ready.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change 29.6 [atomics.types.operations] p18:
+Remove the section 18.4.2 [stdinth].
+</p>
+<p>
+Remove the section 26.3.2 [fenv].
+</p>
+<p>
+Remove 26.8 [c.math], p3:
 </p>
 
 <blockquote>
--18- <i>Effects:</i> Atomically, compares the value pointed to by
-<tt>object</tt> or by <tt>this</tt> for equality with that in
-<tt>expected</tt>, and if true, replaces the value pointed to by
-<tt>object</tt> or by <tt>this</tt> with desired, and if false, updates
-the value in <tt>expected</tt> with the value pointed to by
-<tt>object</tt> or by <tt>this</tt>. Further, if the comparison is true,
-memory is affected according to the value of <tt>success</tt>, and if the
-comparison is false, memory is affected according to the value of
-<tt>failure</tt>. When only one <tt>memory_order</tt> argument is
-supplied, the value of <tt>success</tt> is <tt>order</tt>, and the value
-of <tt>failure</tt> is <tt>order</tt> except that a value of
-<tt>memory_order_acq_rel</tt> shall be replaced by the value
-<tt>memory_order_acquire</tt> and a value of
-<tt>memory_order_release</tt> shall be replaced by the value
-<tt>memory_order_relaxed</tt>. <ins>If the comparison is <tt>true</tt>, </ins>
-<del>T</del><ins>t</ins>hese operations are atomic
-read-modify-write operations (1.10). 
-<ins>If the comparison is <tt>false</tt>, these
-operations are atomic load operations.</ins>
+<del>-3- The header <tt>&lt;tgmath.h&gt;</tt> effectively includes the headers <tt>&lt;complex.h&gt;</tt>
+and <tt>&lt;math.h&gt;</tt>.</del>
 </blockquote>
-
+<p>
+Remove the section 26.4.11 [cmplxh].
+</p>
 
 
 
 
 
 <hr>
-<h3><a name="1046"></a>1046. Response to UK 329</h3>
-<p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-03-13</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1135"></a>1135. <tt>exception_ptr</tt> should support contextual conversion to <tt>bool</tt></h3>
+<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-06  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 329</b></p>
-
 <p>
-<tt>future</tt>, <tt>promise</tt> and <tt>packaged_task</tt> provide a
-framework for creating future values, but a simple function to tie all
-three components together is missing. Note that we only need a *simple*
-facility for C++0x. Advanced thread pools are to be left for TR2.
+As of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
+18.8.5 [propagation]/5, the implementation-defined type
+<tt>exception_ptr</tt> does provide the following ways to check whether
+it is a null value:
 </p>
-
+<blockquote><pre>void f(std::exception_ptr p) {
+  p == nullptr;
+  p == 0;
+  p == exception_ptr();
+}
+</pre></blockquote>
 <p>
-Simple Proposal:
+This is rather cumbersome way of checking for the null value
+and I suggest to require support for evaluation in a boolean
+context like so:
 </p>
 
-<p>
-Provide a simple function along the lines of: 
-</p>
-<blockquote><pre>template&lt; typename F, typename ... Args &gt;
-  requires Callable&lt; F, Args... &gt;
-    future&lt; Callable::result_type &gt; async( F&amp;&amp; f, Args &amp;&amp; ... ); 
+<blockquote><pre>void g(std::exception_ptr p) {
+  if (p) {}
+  !p;
+}
 </pre></blockquote>
 
-<p>
-Semantics are similar to creating a <tt>thread</tt> object with a <tt>packaged_task</tt>
-invoking <tt>f</tt> with <tt>forward&lt;Args&gt;(args...)</tt>
-but details are left unspecified to allow different scheduling and thread
-spawning implementations. 
-</p>
-<p>
-It is unspecified whether a task submitted to async is run on its own thread
-or a thread previously used for another async task. If a call to <tt>async</tt>
-succeeds, it shall be safe to wait for it from any thread. 
-</p>
-<p>
-The state of <tt>thread_local</tt> variables shall be preserved during <tt>async</tt> calls. 
-</p>
-<p>
-No two incomplete async tasks shall see the same value of
-<tt>this_thread::get_id()</tt>. 
-</p>
-<p>
-[<i>Note:</i> this effectively forces new tasks to be run on a new thread, or a
-fixed-size pool with no queue. If the 
-library is unable to spawn a new thread or there are no free worker threads
-then the <tt>async</tt> call should fail. <i>--end note</i>] 
-</p>
-
 <p><i>[
-Summit:
+2009 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-<p>
-The concurrency subgroup has revisited this issue and decided that it
-could be considered a defect according to the Kona compromise. A task
-group was formed lead by Lawrence Crowl and Bjarne Stroustrup to write a
-paper for Frankfort proposing a simple asynchronous launch facility
-returning a <tt>future</tt>. It was agreed that the callable must be run on a
-separate thread from the caller, but not necessarily a brand-new thread.
-The proposal might or might not allow for an implementation that uses
-fixed-size or unlimited thread pools.
-</p>
-<p>
-Bjarne in c++std-lib-23121: I think that what we agreed was that to
-avoid deadlock <tt>async()</tt> would almost certainly be specified to  launch in
-a different thread from the thread that executed <tt>async()</tt>, but I don't
-think it was a specific design constraint.
-</p>
+Move to Ready. Note to editor: considering putting in a cross-reference
+to 4 [conv], paragraph 3, which defines the phrase
+"contextually converted to <tt>bool</tt>".
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="1047"></a>1047. Response to UK 334</h3>
-<p><b>Section:</b> 30.6.5 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.unique_future">active issues</a> in [futures.unique_future].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 334</b></p>
-
 <p>
-Behaviour of <tt>get()</tt> is undefined if calling <tt>get()</tt> while
-not <tt>is_ready()</tt>. The intent is that <tt>get()</tt> is a blocking
-call, and will wait for the future to become ready.
+In section 18.8.5 [propagation] insert a new paragraph between p.5 and p.6:
 </p>
 
-<p><i>[
-Summit:
-]</i></p>
-
-
 <blockquote>
-<p>
-Agree, move to Review.
-</p>
+<ins>
+An object <tt>e</tt> of type <tt>exception_ptr</tt> can be contextually converted to <tt>bool</tt>.
+The effect shall be as if <tt>e != exception_ptr()</tt> had been evaluated in place
+of <tt>e</tt>. There shall be no implicit conversion to arithmetic type, to
+enumeration type or to pointer type.
+</ins>
 </blockquote>
 
-<p><i>[
-2009-04-03 Thomas J. Gritzan adds:
-]</i></p>
 
 
-<blockquote>
-<p>
-This issue also applies to <tt>shared_future::get()</tt>.
-</p>
 
-<p>
-Suggested wording:
-</p>
 
+<hr>
+<h3><a name="1136"></a>1136. Incomplete specification of <tt>nested_exception::rethrow_nested()</tt></h3>
+<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-06  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Add a paragraph to  [futures.shared_future]:
+It was recently mentioned in a newsgroup article
+<a href="http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d">http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d</a>
+that the specification of the member function <tt>rethrow_nested()</tt> of the
+class <tt>nested_exception</tt> is incomplete, specifically it remains unclear
+what happens, if member <tt>nested_ptr()</tt> returns a null value. In
+18.8.6 [except.nested] we find only the following paragraph related to that:
 </p>
-
-<blockquote><pre>void shared_future&lt;void&gt;::get() const;
+<blockquote><pre>void rethrow_nested() const; // [[noreturn]]
 </pre>
 <blockquote>
-<i>Effects:</i> If <tt>is_ready()</tt> would return <tt>false</tt>, block on the asynchronous 
-result associated with <tt>*this</tt>.
-</blockquote>
+-4- <i>Throws:</i> the stored exception captured by this <tt>nested_exception</tt> object.
 </blockquote>
 </blockquote>
+<p>
+This is a problem, because it is possible to create an object of
+<tt>nested_exception</tt> with exactly such a state, e.g.
+</p>
+<blockquote><pre>#include &lt;exception&gt;
+#include &lt;iostream&gt;
+
+int main() try {
+  std::nested_exception e; // OK, calls current_exception() and stores it's null value
+  e.rethrow_nested(); // ?
+  std::cout &lt;&lt; "A" &lt;&lt; std::endl;
+}
+catch(...) {
+  std::cout &lt;&lt; "B" &lt;&lt; std::endl;
+}
+</pre></blockquote>
+<p>
+I suggest to follow the proposal of the reporter, namely to invoke
+<tt>terminate()</tt> if <tt>nested_ptr()</tt> return a null value of <tt>exception_ptr</tt> instead
+of relying on the fallback position of undefined behavior. This would
+be consistent to the behavior of a <tt>throw;</tt> statement when no
+exception is being handled.
+</p>
 
 <p><i>[
-Batavia (2009-05):
+2009 Santa Cruz:
 ]</i></p>
 
+
 <blockquote>
-It is not clear to us that this is an issue,
-because the proposed resolution's Effects clause seems to duplicate
-information already present in the Synchronization clause.
-Keep in Review status.
+Move to Ready.
 </blockquote>
 
 
+
 <p><b>Proposed resolution:</b></p>
 <p>
-Add a paragraph to 30.6.5 [futures.unique_future]:
+Change around 18.8.6 [except.nested]/4 as indicated:
 </p>
-
-<blockquote><pre>R&amp;&amp; unique_future::get(); 
-R&amp; unique_future&lt;R&amp;&gt;::get(); 
-void unique_future&lt;void&gt;::get();
-</pre>
 <blockquote>
-<p><i>Note:</i>...</p>
 <p>
-<ins><i>Effects:</i> If <tt>is_ready()</tt> would return <tt>false</tt>,
-block on the asynchronous result associated with <tt>*this</tt>.</ins>
+-4- <i>Throws:</i> the stored exception captured by this <tt>nested_exception</tt>
+object<ins>, if <tt>nested_ptr() != nullptr</tt></ins>
 </p>
 <p>
-<i>Synchronization:</i> if <tt>*this</tt> is associated with a
-<tt>promise</tt> object, the completion of <tt>set_value()</tt> or
-<tt>set_exception()</tt> to that <tt>promise</tt> happens before (1.10)
-<tt>get()</tt> returns.
+<ins>- <i>Remarks:</i> If <tt>nested_ptr() == nullptr</tt>, <tt>terminate()</tt>
+shall be called.</ins>
 </p>
 </blockquote>
-</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="1048"></a>1048. Response to UK 335</h3>
-<p><b>Section:</b> 30.6.5 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-03-13</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.unique_future">active issues</a> in [futures.unique_future].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1137"></a>1137. Return type of <tt>conj</tt> and <tt>proj</tt></h3>
+<p><b>Section:</b> 26.4.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Marc Steinbach <b>Opened:</b> 2009-06-11  <b>Last modified:</b> 2009-06-27</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cmplx.over">issues</a> in [cmplx.over].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 335</b></p>
-
 <p>
-<tt>std::unique_future</tt> is <tt>MoveConstructible</tt>, so you can transfer the
-association with an asynchronous result from one instance to another.
-However, there is no way to determine whether or not an instance has
-been moved from, and therefore whether or not it is safe to wait for it.
+In clause 1, the Working Draft 
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>)
+specifies overloads of the
+functions
 </p>
-
-<blockquote><pre>std::promise&lt;int&gt; p;
-std::unique_future&lt;int&gt; uf(p.get_future());
-std::unique_future&lt;int&gt; uf2(std::move(uf));
-uf.wait(); <font color="#c80000">// oops, uf has no result to wait for. </font>
+<blockquote><pre>arg, conj, imag, norm, proj, real
 </pre></blockquote>
-
 <p>
-Suggest we add a <tt>waitable()</tt> function to <tt>unique_future</tt>
-(and <tt>shared_future</tt>) akin to <tt>std::thread::joinable()</tt>,
-which returns <tt>true</tt> if there is an associated result to wait for
-(whether or not it is ready).
+for non-complex arithmetic types (<tt>float</tt>, <tt>double</tt>,
+<tt>long double</tt>, and integers).
+The only requirement (clause 2) specifies effective type promotion of arguments.
 </p>
-
 <p>
-Then we can say:
+I strongly suggest to add the following requirement on the return types:
 </p>
-
-<blockquote><pre>if(uf.waitable()) uf.wait();
-</pre></blockquote>
-
-<p><i>[
-Summit:
-]</i></p>
-
-
 <blockquote>
-<p>
-Create an issue. Requires input from Howard. Probably NAD.
-</p>
+All the specified overloads must return real (i.e., non-complex) values,
+specifically, the nested <tt>value_type</tt> of effectively promoted arguments.
 </blockquote>
 
-<p><i>[
-Post Summit, Howard thows in his two cents:
-]</i></p>
-
-
-<blockquote>
 <p>
-Here is a copy/paste of my last prototype of <tt>unique_future</tt> which was
-several years ago.  At that time I was calling <tt>unique_future</tt> <tt>future</tt>:
+(This has no effect on <tt>arg</tt>, <tt>imag</tt>, <tt>norm</tt>, <tt>real</tt>:
+they are real-valued anyway.)
+</p>
+<p><b>Rationale:</b></p>
+<p>
+Mathematically, <tt>conj()</tt> and <tt>proj()</tt>, like the transcendental functions, are
+complex-valued in general but map the (extended) real line to itself.
+In fact, both functions act as identity on the reals.
+A typical user will expect <tt>conj()</tt> and <tt>proj()</tt> to preserve this essential
+mathematical property in the same way as <tt>exp()</tt>, <tt>sin()</tt>, etc.
+A typical use of <tt>conj()</tt>, e.g., is the generic scalar product of n-vectors:
 </p>
 
-<blockquote><pre>template &lt;class R&gt;
-class future
-{
-public:
-    typedef R result_type;
-private:
-    future(const future&amp;);// = delete;
-    future&amp; operator=(const future&amp;);// = delete;
-
-    template &lt;class R1, class F1&gt; friend class prommise;
-public:
-    future();
-    ~future();
-
-    future(future&amp;&amp; f);
-    future&amp; operator=(future&amp;&amp; f);
-
-    void swap(future&amp;&amp; f);
-
-    <b>bool joinable() const;</b>
-    bool is_normal() const;
-    bool is_exceptional() const;
-    bool is_ready() const;
-
-    R get();
-
-    void join();
-    template &lt;class ElapsedTime&gt;
-        bool timed_join(const ElapsedTime&amp;);
-};
+<blockquote><pre>template&lt;typename T&gt;
+inline T
+scalar_product(size_t n, T const* x, T const* y) {
+  T result = 0;
+  for (size_t i = 0; i &lt; n; ++i)
+    result += x[i] * std::conj(y[i]);
+  return result;
+}
 </pre></blockquote>
-
 <p>
-<tt>shared_future</tt> had a similar interface.  I intentionally reused
-the <tt>thread</tt> interface where possible to lessen the learning
-curve std::lib clients will be faced with.
+This will work equally well for real and complex floating-point types <tt>T</tt> if
+<tt>conj()</tt> returns <tt>T</tt>. It will not work with real types if <tt>conj()</tt>
+returns complex values.
+</p>
+<p>
+Instead, the implementation of <tt>scalar_product</tt> becomes either less efficient
+and less useful (if a complex result is always returned), or unnecessarily
+complicated (if overloaded versions with proper return types are defined).
+In the second case, the real-argument overload of <tt>conj()</tt> cannot be used.
+In fact, it must be avoided.
+</p>
+<p>
+Overloaded <tt>conj()</tt> and <tt>proj()</tt> are principally needed in generic programming.
+All such use cases will benefit from the proposed return type requirement,
+in a similar way as the <tt>scalar_product</tt> example.
+The requirement will not harm use cases where a complex return value
+is expected, because of implicit conversion to complex.
+Without the proposed return type guarantee, I find overloaded versions
+of <tt>conj()</tt> and <tt>proj()</tt> not only useless but actually troublesome.
 </p>
-</blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
+<p>
+Insert a new paragraph after 26.4.9 [cmplx.over]/2:
+</p>
+
+<blockquote>
+<ins>
+All of the specified overloads shall have a return type which is the nested <tt>value_type</tt> of
+the effectively promoted arguments.
+</ins>
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="1049"></a>1049. Response to UK 339</h3>
-<p><b>Section:</b> 30.6.4 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="1138"></a>1138. unusual return value for operator+</h3>
+<p><b>Section:</b> 21.4.8.1 [string::op+] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-06-12  <b>Last modified:</b> 2009-11-05</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
 <p><b>Discussion:</b></p>
+<p>
+Many of the <tt>basic_string operator+</tt> overloads return an rvalue-reference.  Is
+that really intended?
+</p>
+<p>
+I'm considering it might be a mild performance tweak to avoid making
+un-necessary copies of a cheaply movable type, but it opens risk to dangling
+references in code like:
+</p>
 
-<p><b>Addresses UK 339</b></p>
+<blockquote><pre>auto &amp;&amp; s = string{"x"} + string{y};
+</pre></blockquote>
 
 <p>
-Move assignment is goiing in the wrong direction, assigning from
-<tt>*this</tt> to the passed rvalue, and then returning a reference to
-an unusable <tt>*this</tt>.
+and I'm not sure about:
 </p>
 
+<blockquote><pre>auto s = string{"x"} + string{y};
+</pre></blockquote>
+
 <p><i>[
-Summit:
+2009-10-11 Howard updated <i>Returns:</i> clause for each of these.
 ]</i></p>
 
 
-<blockquote>
-<p>
-Agree, move to Review.
-</p>
-</blockquote>
-
 <p><i>[
-Batavia (2009-05):
+2009-11-05 Howard adds:
 ]</i></p>
 
+
 <blockquote>
-We recommend deferring this issue until after Detlef's paper (on futures)
-has been issued.
+Moved to Tentatively Ready after 5 positive votes on c++std-lib.
 </blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Strike 30.6.4 [futures.promise] p6 and change p7:
+Strike the <tt>&amp;&amp;</tt> from the return type in the following function
+signatures:
 </p>
 
-<blockquote><pre>promise&amp; operator=(promise&amp;&amp; rhs);
-</pre>
 <blockquote>
 <p>
-<del>-6- <i>Effects:</i> move assigns its associated state to <tt>rhs</tt>.</del>
-</p>
-<p>
--7- <i>Postcondition:</i> <del><tt>*this</tt> has no associated
-state.</del> <ins>associated state of <tt>*this</tt> is the same as the
-associated state of <tt>rhs</tt> before the call. <tt>rhs</tt> has no
-associated state.</ins>
+21.3 [string.classes] p2 Header Synopsis
 </p>
-</blockquote>
-</blockquote>
 
+<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
+  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
+    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
+              const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs);
+
+template&lt;class charT, class traits, class Allocator&gt;
+  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
+    operator+(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
+              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
 
+template&lt;class charT, class traits, class Allocator&gt;
+  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
+    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
+              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
 
 
+template&lt;class charT, class traits, class Allocator&gt;
+  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
+    operator+(const charT* lhs,
+              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
 
+template&lt;class charT, class traits, class Allocator&gt;
+  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
+    operator+(charT lhs, basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
 
-<hr>
-<h3><a name="1050"></a>1050. Response to UK 340</h3>
-<p><b>Section:</b> 30.6.4 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
+template&lt;class charT, class traits, class Allocator&gt;
+  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
+    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
+              const charT* rhs);
 
-<p><b>Addresses UK 340</b></p>
+template&lt;class charT, class traits, class Allocator&gt;
+  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
+    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs, charT rhs);
+</pre></blockquote>
 
 <p>
-There is an implied postcondition for <tt>get_future()</tt> that the state of the
-<tt>promise</tt> is transferred into the <tt>future</tt> leaving the <tt>promise</tt> with no
-associated state. It should be spelled out.
+21.4.8.1 [string::op+]
 </p>
 
-<p><i>[
-Summit:
-]</i></p>
-
-
+<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
+  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
+    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
+              const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs);
+</pre>
 <blockquote>
-<p>
-Agree, move to Review.
-</p>
+<i>Returns:</i> <tt><ins>std::move(</ins>lhs.append(rhs)<ins>)</ins></tt>
 </blockquote>
-
-<p><i>[
-2009-04-03 Thomas J. Gritzan adds:
-]</i></p>
-
-
+<pre>template&lt;class charT, class traits, class Allocator&gt;
+  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
+    operator+(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
+              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
+</pre>
 <blockquote>
-<p>
-<tt>promise::get_future()</tt> must not invalidate the state of the promise object. 
-</p>
-<p>
-A promise is used like this: 
-</p>
-<blockquote><pre>promise&lt;int&gt; p; 
-unique_future&lt;int&gt; f = p.get_future(); 
-<font color="#c80000">// post 'p' to a thread that calculates a value </font>
-<font color="#c80000">// use 'f' to retrieve the value. </font>
-</pre></blockquote>
-<p>
-So <tt>get_future()</tt> must return an object that shares the same associated 
-state with <tt>*this</tt>. 
-</p>
-<p>
-But still, this function should throw an <tt>future_already_retrieved</tt> error 
-when it is called twice. 
-</p>
-<p>
-<tt>packaged_task::get_future()</tt> throws <tt>std::bad_function_call</tt> if its <tt>future</tt>
-was already retrieved. It should throw 
-<tt>future_error(future_already_retrieved)</tt>, too. 
-</p>
-<p>
-Suggested resolution: 
-</p>
-<p>
-Replace p12/p13 30.6.4 [futures.promise]: 
-</p>
+<i>Returns:</i> <tt><ins>std::move(</ins>rhs.insert(0, lhs)<ins>)</ins></tt>
+</blockquote>
+<pre>template&lt;class charT, class traits, class Allocator&gt;
+  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
+    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
+              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
+</pre>
 <blockquote>
-<p>
--12- <i>Throws:</i> <tt>future_error</tt> if <del><tt>*this</tt> has no associated state</del>
-<ins>the <tt>future</tt> has already been retrieved</ins>.
-</p>
-<p>
--13- <i>Error conditions:</i> <tt>future_already_retrieved</tt> if <del><tt>*this</tt>
-has no associated state</del>
-<ins>the <tt>future</tt> associated with 
-the associated state has already been retrieved</ins>.
-</p>
-<p>
-<ins><i>Postcondition:</i> The returned object and <tt>*this</tt> share the associated state.</ins>
-</p>
+<i>Returns:</i> <tt><ins>std::move(</ins>lhs.append(rhs)<ins>)</ins></tt> [<i>Note:</i> Or equivalently
+<tt><ins>std::move(</ins>rhs.insert(0, lhs)<ins>)</ins></tt> &#8212; <i>end note</i>]
 </blockquote>
-<p>
-Replace p14 30.6.7 [futures.task]: 
-</p>
+<pre>template&lt;class charT, class traits, class Allocator&gt;
+  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
+    operator+(const charT* lhs,
+              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
+</pre>
 <blockquote>
-<p>
--14- <i>Throws:</i> <tt><del>std::bad_function_call</del> <ins>future_error</ins></tt> if the future <del>associated with
-the task</del> has already been retrieved.
-</p>
-
-<p><ins>
-<i>Error conditions:</i> <tt>future_already_retrieved</tt> if the <tt>future</tt> associated with 
-the task has already been retrieved. 
-</ins></p>
-<p>
-<ins><i>Postcondition:</i> The returned object and <tt>*this</tt> share the associated task.</ins>
-</p>
+<i>Returns:</i> <tt><ins>std::move(</ins>rhs.insert(0, lhs)<ins>)</ins></tt>.
 </blockquote>
+<pre>template&lt;class charT, class traits, class Allocator&gt;
+  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
+    operator+(charT lhs, basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
+</pre>
+<blockquote>
+<i>Returns:</i> <tt><ins>std::move(</ins>rhs.insert(0, 1, lhs)<ins>)</ins></tt>.
 </blockquote>
-
-<p><i>[
-Batavia (2009-05):
-]</i></p>
-
+<pre>template&lt;class charT, class traits, class Allocator&gt;
+  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
+    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
+              const charT* rhs);
+</pre>
 <blockquote>
-Keep in Review status
-pending Detlef's forthcoming paper on futures.
+<i>Returns:</i> <tt><ins>std::move(</ins>lhs.append(rhs)<ins>)</ins></tt>.
 </blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add after p13 30.6.4 [futures.promise]:
-</p>
-
-<blockquote><pre>unique_future&lt;R&gt; get_future();
+<pre>template&lt;class charT, class traits, class Allocator&gt;
+  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
+    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs, charT rhs);
 </pre>
 <blockquote>
-<p>
--13- ...
-</p>
-<p>
-<i>Postcondition:</i> <tt>*this</tt> has no associated state.
-</p>
+<i>Returns:</i> <tt><ins>std::move(</ins>lhs.append(1, rhs)<ins>)</ins></tt>.
 </blockquote>
 </blockquote>
 
+</blockquote>
+
 
 
 
 
 
 <hr>
-<h3><a name="1051"></a>1051. Response to UK 279</h3>
-<p><b>Section:</b> 24.5.1.2.12 [reverse.iter.opindex], 24.5.2.2.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-27</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1144"></a>1144. "thread safe" is undefined</h3>
+<p><b>Section:</b> 18.5 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-16  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.start.term">issues</a> in [support.start.term].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 
-<p><b>Addresses UK 279</b></p>
+<p><b>Addresses UK 187</b></p>
 
 <p>
-The reason the return type became unspecified is LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>. This
-reasoning no longer applies as there are at least two ways to get the right
-return type with the new language facilities added since the previous
-standard. 
+The term "thread safe" is not defined nor used in this context
+anywhere else in the standard.
 </p>
 
+<p><b>Suggested action:</b></p>
 <p>
-Proposal: Specify the return type using either decltype or the Iter concept_map.
+Clarify the meaning of "thread safe".
 </p>
 
 <p><i>[
-Summit:
+2009 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
 <p>
-Under discussion. This is a general question about all iterator
-adapters.
+The "thread safe" language has already been change in the WP. It was
+changed to "happen before", but the current WP text is still a little
+incomplete: "happen before" is binary, but the current WP text only
+mentions one thing.
+</p>
+<p>
+Move to Ready.
 </p>
 </blockquote>
 
-<p><i>[
-Howard adds post Summit:
-]</i></p>
-
-
-<blockquote>
-I am requesting test cases to demonstrate a position.
-</blockquote>
-
-<p><i>[
-2009-07-24 Daniel adds:
-]</i></p>
 
 
-<blockquote>
+<p><b>Proposed resolution:</b></p>
 <p>
-I recommend NAD. Without concepts we can no longer
-restrict this member in a trivial way. Using <tt>decltype</tt> the
-declaration would be along the lines of
+For the following functions in 18.5 [support.start.term].
 </p>
-<blockquote><pre>static const Iter&amp; __base(); // not defined
-auto operator[](difference_type n) const -&gt; decltype(__base()[-n-1]);
-</pre></blockquote>
+<blockquote><pre><code>
+extern "C" int at_quick_exit(void (*f)(void));
+extern "C++" int at_quick_exit(void (*f)(void));
+</code></pre></blockquote>
 
 <p>
-but once <tt>reverse_iterator</tt> is instantiated for some given type
-<tt>Iter</tt> which cannot form a well-formed expression <tt>__base()[-n-1]</tt>
-this would cause an ill-formed function declaration, diagnostic
-required, and no silent SFINAE elimination.
+Edit paragraph 10 as follows.
+The intent is
+to provide the other half of the happens before relation;
+to note indeterminate ordering;
+and to clean up some formatting.
 </p>
+<blockquote><p>
+<i>Effects:</i>
+The <code>at_quick_exit()</code> functions
+register the function pointed to by <code>f</code>
+to be called without arguments when <code>quick_exit</code> is called.
+It is unspecified whether a call to <code>at_quick_exit()</code>
+that does not <del>happen-before</del> <ins>happen before</ins> (1.10)
+<ins>all calls to <code>quick_exit</code></ins>
+will succeed.
+[<i>Note:</i>
+the <code>at_quick_exit()</code> functions
+shall not introduce a data race (17.6.4.7).
+<del>exitnote</del>
+<ins>&#8212;<i>end note</i>]</ins>
+<ins>
+[<i>Note:</i>
+The order of registration may be indeterminate
+if <code>at_quick_exit</code> was called from more than one thread.
+&#8212;<i>end note</i>]
+</ins>
+[<i>Note:</i> The <code>at_quick_exit</code> registrations
+are distinct from the <code>atexit</code> registrations,
+and applications may need to call both registration functions
+with the same argument.
+&#8212;<i>end note</i>]
+</p></blockquote>
 
-</blockquote>
-
-
+<p>
+For the following function.
+</p>
+<blockquote><pre><code>
+void quick_exit [[noreturn]] (int status)
+</code></pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
+<p>
+Edit paragraph 13 as follows.
+The intent is to note that thread-local variables may be different.
+</p>
+<blockquote><p>
+<i>Effects:</i>
+Functions registered by calls to <code>at_quick_exit</code>
+are called in the reverse order of their registration,
+except that a function shall be called
+after any previously registered functions
+that had already been called at the time it was registered.
+Objects shall not be destroyed as a result of calling <code>quick_exit</code>.
+If control leaves a registered function called by <code>quick_exit</code>
+because the function does not provide a handler for a thrown exception,
+<code>terminate()</code> shall be called.
+<ins>
+[<i>Note:</i>
+Functions registered by one thread may be called by any thread,
+and hence should not rely on the identity of thread-storage-duration objects.
+&#8212;<i>end note</i>]
+</ins>
+After calling registered functions,
+<code>quick_exit</code> shall call <code>_Exit(status)</code>.
+[<i>Note:</i>
+The standard file buffers are not flushed.
+See: ISO C 7.20.4.4.
+&#8212;<i>end note</i>]
+</p></blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="1052"></a>1052. Response to UK 281</h3>
-<p><b>Section:</b> 24.5.1.2.5 [reverse.iter.opref] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-08-01</p>
+<h3><a name="1151"></a>1151. Behavior of the library in the presence of threads is incompletely specified</h3>
+<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
+<p><b>Addresses US 63</b></p>
 
-<p><b>Addresses UK 281</b></p>
-
-<p>
-The current specification for return value for <tt>reverse_iterator::operator-&gt;</tt>
-will always be a true pointer type, but <tt>reverse_iterator</tt> supports proxy
-iterators where the pointer type may be some kind of 'smart pointer'.
+   <p><b>Description</b></p>
+        <p>The behavior of the library in the presence of threads
+        is incompletely specified.</p>
+        <p>For example, if thread 1 assigns to <tt>X</tt>, then writes data
+        to file <tt>f</tt>, which is read by thread 2, and then accesses
+        variable <tt>X</tt>, is thread 2 guaranteed to be able to see the
+        value assigned to <tt>X</tt> by thread 1? In other words, does the
+        write of the data "happen before" the read?</p>
+        <p>Another example: does simultaneous access using <tt>operator
+        at()</tt> to different characters in the same non-const string
+        really introduce a data race?</p>
+<p><b>Suggestion</b></p>
+<p><b>Notes</b></p><p>17 SG: should go to threads group; misclassified in document
 </p>
 
+    <p>Concurrency SG: Create an issue. Hans will look into it.</p>
+
 <p><i>[
-Summit:
+2009 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-<p>
-<tt>move_iterator</tt> avoids this problem by returning a value of the wrapped
-Iterator type.
-study group formed to come up with a suggested resolution.
-</p>
-<p>
-<tt>move_iterator</tt> solution shown in proposed wording.
-</p>
+Move to "Open". Hans and the rest of the concurrency working group will
+study this. We can't make progress without a thorough review and a
+paper.
 </blockquote>
 
-<p><i>[
-2009-07 post-Frankfurt:
-]</i></p>
-
 
-<blockquote>
-Howard to deconceptize. Move to Review after that happens.
-</blockquote>
 
-<p><i>[
-2009-08-01 Howard deconceptized:
-]</i></p>
+<p><b>Proposed resolution:</b></p>
 
 
-<blockquote>
-</blockquote>
 
 
 
-<p><b>Proposed resolution:</b></p>
+<hr>
+<h3><a name="1152"></a>1152. expressions parsed differently than intended</h3>
+<p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Seungbeom Kim <b>Opened:</b> 2009-06-27  <b>Last modified:</b> 2009-10-28</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.put.virtuals">active issues</a> in [facet.num.put.virtuals].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Change synopsis in 24.5.1.1 [reverse.iterator]:
+In Table 73 -- Floating-point conversions, 22.4.2.2.2 [facet.num.put.virtuals], 
+in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>,
+we have the following entries: 
 </p>
+<table border="1">
+<caption>Table 73 &#8212; Floating-point conversions</caption>
+<tbody><tr>
+<th>State</th> <th><tt>stdio</tt> equivalent</th>
+</tr>
+<tr>
+<td><tt>floatfield == ios_base::fixed | ios_base::scientific &amp;&amp; !uppercase</tt></td>
+<td align="center"><tt>%a</tt></td>
+</tr>
 
-<blockquote><pre>template &lt;class Iterator&gt; 
-class reverse_iterator { 
-  ...
-  typedef <del>typename iterator_traits&lt;</del>Iterator<del>&gt;::pointer</del> pointer;
-</pre></blockquote>
+<tr>
+<td><tt>floatfield == ios_base::fixed | ios_base::scientific</tt></td>
+<td align="center"><tt>%A</tt></td>
+</tr>
+</tbody></table>
 
 <p>
-Change 24.5.1.2.5 [reverse.iter.opref]:
+These expressions are supposed to mean: 
 </p>
 
-<blockquote><pre>pointer operator-&gt;() const;
-</pre>
-<blockquote>
-<i>Returns:</i>
-<blockquote><pre><del>&amp;(operator*());</del>
-<ins>this-&gt;tmp = current;</ins>
-<ins>--this-&gt;tmp;</ins>
-<ins>return this-&gt;tmp;</ins>
+<blockquote><pre>floatfield == (ios_base::fixed | ios_base::scientific) &amp;&amp; !uppercase 
+floatfield == (ios_base::fixed | ios_base::scientific) 
 </pre></blockquote>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="1053"></a>1053. Response to UK 295</h3>
-<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-03-13</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#algorithms">active issues</a> in [algorithms].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 295</b></p>
-
 <p>
-There is a level of redundancy in the library specification for many
-algorithms that can be eliminated with the combination of concepts and
-default parameters for function templates. Eliminating redundancy simplified
-specification and reduces the risk of introducing accidental
-inconsistencies.
+but technically parsed as: 
 </p>
+<blockquote><pre>((floatfield == ios_base::fixed) | ios_base::scientific) &amp;&amp; (!uppercase) 
+((floatfield == ios_base::fixed) | ios_base::scientific) 
+</pre></blockquote>
 <p>
-Proposed resolution: Adopt
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2743.pdf">N2743</a>.
+and should be corrected with additional parentheses, as shown above. 
 </p>
 
 <p><i>[
-Summit:
+2009-10-28 Howard:
 ]</i></p>
 
 
 <blockquote>
-<p>
-NAD, this change would break code that takes the address of an
-algorithm.
-</p>
+Moved to Tentatively Ready after 5 positive votes on c++std-lib.
 </blockquote>
 
-<p><i>[
-Post Summit Alisdair adds:
-]</i></p>
 
 
-<blockquote>
+<p><b>Proposed resolution:</b></p>
 <p>
-Request 'Open'.  The issues in the paper go beyond just reducing
-the number of signatures, but cover unifying the idea of the ordering
-operation used by algorithms, containers and other library components.  At
-least, it takes a first pass at the problem.
+Change Table 83 &#8212; Floating-point conversions in  22.4.2.2.2 [facet.num.put.virtuals]:
 </p>
 
-<p>
-For me (personally) that was the more important part of the paper, and not
-clearly addressed by the Summit resolution.
-</p>
-</blockquote>
+<table border="1">
+<caption>Table 83 &#8212; Floating-point conversions</caption>
+<tbody><tr>
+<th>State</th> <th><tt>stdio</tt> equivalent</th>
+</tr>
+<tr>
+<td><tt>floatfield == <ins>(</ins>ios_base::fixed | ios_base::scientific<ins>)</ins> &amp;&amp; !uppercase</tt></td>
+<td align="center"><tt>%a</tt></td>
+</tr>
 
-
-
-<p><b>Proposed resolution:</b></p>
+<tr>
+<td><tt>floatfield == <ins>(</ins>ios_base::fixed | ios_base::scientific<ins>)</ins></tt></td>
+<td align="center"><tt>%A</tt></td>
+</tr>
+</tbody></table>
 
 
 
 
 
 <hr>
-<h3><a name="1054"></a>1054. <tt>forward</tt> broken</h3>
-<p><b>Section:</b> 20.3.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-13  <b>Last modified:</b> 2009-08-02</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
+<h3><a name="1153"></a>1153. Standard library needs review for constructors to be
+explicit to avoid treatment as initializer-list constructor</h3>
+<p><b>Section:</b> 17 [library], 30 [thread], D [depr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 
-<p>
-This is a placeholder issue to track the fact that we (well I) put the standard
-into an inconsistent state by requesting that we accept
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
-except for the proposed changes to [forward].
-</p>
-
-<p>
-There will exist in the post meeting mailing
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2835.html">N2835</a>
-which in its current state reflects the state of affairs prior to the Summit
-meeting.  I hope to update it in time for the post Summit mailing, but as I write
-this issue I have not done so yet.
-</p>
+<p><b>Addresses DE 2</b></p>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<p><b>Description</b></p>
+        <p>Marking a constructor with <tt>explicit</tt> has semantics
+        even for a constructor with zero or several parameters:
+        Such a constructor cannot be used with list-initialization
+        in a copy-initialization context, see 13.3.1.7 [over.match.list]. The
+        standard library apparently has not been reviewed for
+        marking non-single-parameter constructors as <tt>explicit</tt>.</p>
+<p><b>Suggestion</b></p>
+        <p>Consider marking zero-parameter and multi-parameter
+        constructors <tt>explicit</tt> in classes that have at least one
+        constructor marked <tt>explicit</tt> and that do not have an
+        initializer-list constructor.</p>
 
-<blockquote>
-Move to Open, awaiting the promised paper.
-</blockquote>
+<p><b>Notes</b></p>
+        <p>Robert Klarer to address this one.</p>
 
 <p><i>[
-2009-08-02 Howard adds:
+2009 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-<p>
-My current preferred solution is:
-</p>
-
-<blockquote><pre>template &lt;class T&gt;
-struct __base_type
-{
-   typedef typename remove_cv&lt;typename remove_reference&lt;T&gt;::type&gt;::type type;
-};
-
-template &lt;class T, class U,
-   class = typename enable_if&lt;
-       !is_lvalue_reference&lt;T&gt;::value ||
-        is_lvalue_reference&lt;T&gt;::value &amp;&amp;
-        is_lvalue_reference&lt;U&gt;::value&gt;::type,
-   class = typename enable_if&lt;
-        is_same&lt;typename __base_type&lt;T&gt;::type,
-                typename __base_type&lt;U&gt;::type&gt;::value&gt;::type&gt;
-inline
-T&amp;&amp;
-forward(U&amp;&amp; t)
-{
-   return static_cast&lt;T&amp;&amp;&gt;(t);
-}
-</pre></blockquote>
-
-<p>
-This has been tested by Bill, Jason and myself.
-</p>
-
-<p>
-It allows the following lvalue/rvalue casts:
-</p>
-
-<ol>
-<li>
-Cast an lvalue <tt>t</tt> to an lvalue <tt>T</tt> (identity).
-</li>
-<li>
-Cast an lvalue <tt>t</tt> to an rvalue <tt>T</tt>.
-</li>
-<li>
-Cast an rvalue <tt>t</tt> to an rvalue <tt>T</tt> (identity).
-</li>
-</ol>
-
-<p>
-It disallows:
-</p>
-
-<ol type="a">
-<li>
-Cast an rvalue <tt>t</tt> to an lvalue <tt>T</tt>.
-</li>
-<li>
-Cast one type <tt>t</tt> to another type <tt>T</tt> (such as <tt>int</tt> to <tt>double</tt>).
-</li>
-</ol>
-
-<p>
-"a." is disallowed as it can easily lead to dangling references.
-"b." is disallowed as this function is meant to only change the lvalue/rvalue
-characteristic of an expression.
-</p>
-
-<p>
-Jason has expressed concern that "b." is not dangerous and is useful in contexts
-where you want to "forward" a derived type as a base type.  I find this use case
-neither dangerous, nor compelling.  I.e. I could live with or without the "b."
-constraint.  Without it, forward would look like:
-</p>
-
-<blockquote><pre>template &lt;class T, class U,
-   class = typename enable_if&lt;
-       !is_lvalue_reference&lt;T&gt;::value ||
-        is_lvalue_reference&lt;T&gt;::value &amp;&amp;
-        is_lvalue_reference&lt;U&gt;::value&gt;::type&gt;
-inline
-T&amp;&amp;
-forward(U&amp;&amp; t)
-{
-   return static_cast&lt;T&amp;&amp;&gt;(t);
-}
-</pre></blockquote>
-
-<p>
-Or possibly:
-</p>
-
-<blockquote><pre>template &lt;class T, class U,
-   class = typename enable_if&lt;
-       !is_lvalue_reference&lt;T&gt;::value ||
-        is_lvalue_reference&lt;T&gt;::value &amp;&amp;
-        is_lvalue_reference&lt;U&gt;::value&gt;::type,
-   class = typename enable_if&lt;
-        is_base_of&lt;typename __base_type&lt;U&gt;::type,
-                   typename __base_type&lt;T&gt;::type&gt;::value&gt;::type&gt;
-inline
-T&amp;&amp;
-forward(U&amp;&amp; t)
-{
-   return static_cast&lt;T&amp;&amp;&gt;(t);
-}
-</pre></blockquote>
-
-
-<p>
-The "promised paper" is not in the post-Frankfurt mailing only because I'm waiting
-for the non-concepts draft.  But I'm hoping that by adding this information here
-I can keep people up to date.
-</p>
+Move to "Open". Robert Klarer has promised to provide wording.
 </blockquote>
 
 
@@ -24589,160 +20415,74 @@ I can keep people up to date.
 
 
 <hr>
-<h3><a name="1055"></a>1055. Response to UK 98</h3>
-<p><b>Section:</b> 20.6.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1154"></a>1154. <tt>complex</tt> should accept integral types</h3>
+<p><b>Section:</b> 26.4 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 
-<p><b>Addresses UK 98</b></p>
-
-<p>
-It would be useful to be able to determine the underlying
-type of an arbitrary enumeration type. This would allow
-safe casting to an integral type (especially needed for
-scoped enums, which do not promote), and would allow
-use of <tt>numeric_limits</tt>. In general it makes generic
-programming with enumerations easier.
-</p>
-
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<p><b>Addresses FR 35</b></p>
 
-<blockquote>
-Pete observes (and Tom concurs)
-that the proposed resolution seems to require compiler support
-for its implementation,
-as it seems necessary to look at the range of values
-of the enumerated type.
-To a first approximation,
-a library solution could give an answer based on the size of the type.
-If the user has specialized <tt>numeric_limits</tt> for the enumerated type,
-then the library might be able to do better,
-but there is no such requirement.
-Keep status as Open
-and solicit input from CWG.
-</blockquote>
+<p><b>Description</b></p>
+        <p>Instantiations of the class
+        template <tt>complex&lt;&gt;</tt> have to be allowed for integral
+        types, to reflect existing practice and ISO standards
+        (LIA-III).</p>
+        
+<p><b>Suggestion</b></p>
 
 <p><i>[
-2009-05-23 Alisdair adds:
+2009-10-26 Proposed wording in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3002.pdf">N3002</a>.
 ]</i></p>
 
 
-<blockquote>
-Just to confirm that the BSI originator of this comment assumed it did
-indeed imply a compiler intrinsic.  Rather than request a Core extension, it
-seemed in keeping with that the type traits interface provides a library API
-to unspecified compiler features - where we require several other traits
-(e.g. <tt>has_trivial_*</tt>) to get the 'right' answer now, unlike in TR1.
-</blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>
-Add a new row to the table in 20.6.7 [meta.trans.other]:
-</p>
-
-<blockquote>
-<table border="1">
-<caption>Table 41 -- Other transformations</caption>
-<tbody><tr>
-<th>Template</th>
-<th>Condition</th>
-<th>Comments</th>
-</tr>
-<tr>
-<td>
-<tt>template&lt;&nbsp;class&nbsp;T&nbsp;&gt; struct enum_base;</tt>
-</td>
-<td>
-<tt>T</tt> shall be an enumeration type (7.2 [dcl.enum])
-</td>
-<td>
-The member typedef <tt>type</tt> shall name the underlying type
-of the enum <tt>T</tt>.
-</td>
-</tr>
-</tbody></table>
-</blockquote>
+Adopt
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3002.pdf">N3002</a>.
 
 
 
 
 
 <hr>
-<h3><a name="1056"></a>1056. Must all Engines and Distributions be Streamable?</h3>
-<p><b>Section:</b> 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-05-31</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
+<h3><a name="1156"></a>1156. Constraints on bitmask and enumeration types to be tightened</h3>
+<p><b>Section:</b> 17.5.2.1.2 [enumerated.types], 17.5.2.1.3 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-10-27</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 
-<p>
-Both the concepts <tt>RandomNumberEngine</tt> and <tt>RandomNumberDistribution</tt> have
-requirements to be <tt>InputStreamable</tt> and <tt>OutputStreamable</tt>.
-</p>
-<p>
-I have no problems leaving the WP in an inconsistent state on the best-faith
-assumption these concepts will be provided later, however disagree with the
-proposers that these constraints are not separable, orthogonal to the basic
-concepts of generating random number distributions.
-</p>
-<p>
-These constraints should be dropped, and applied to specific algorithms as
-needed.
-</p>
-<p>
-If a more refined concept (certainly deemed useful by the proposers) is
-proposed there is no objection, but the basic concept should not require
-persistence via streaming.
-</p>
-
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<p><b>Addresses UK 165</b></p>
 
-<blockquote>
-Move to Open.
-</blockquote>
+<p><b>Description</b></p>
+        <p>Constraints on
+        bitmask and enumeration types were supposed to be tightened
+        up as part of the motivation for the <tt>constexpr</tt> feature -
+        see paper
+        <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf">N2235</a>
+        for details</p>
+<p><b>Suggestion</b></p>
+        <p>Adopt wording in line with the motivation
+        described in
+        <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf">N2235</a></p>
+<p><b>Notes</b></p>
+        <p>Robert Klarer to review</p>
 
 <p><i>[
-2009-05-31 Alisdair adds:
+2009 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-<p>
-Working on constraining the stream iterators, I have a few more observations
-to make on the concepts proposed while constraining the random number
-facility.
-</p>
-<p>
-While I still believe the concerns are orthogonal, I don't believe the
-existing constraints go far enough either!  The goal we want to achieve is
-not that a <tt>RandomNumberEngine</tt> / <tt>RandomNumberDistribution</tt> supports the stream
-operators, but that it is <tt>Serializable</tt>.  I.e. there is a relationship
-between the insert and extract operations that guarantees to restore the
-state of the original object.  This implies a coupling of the concepts
-together in a broader concept (<tt>Serializable</tt>) with at least one axiom to
-assert the semantics.
-</p>
-<p>
-One problem is that <tt>istream</tt> and <tt>ostream</tt> may be fundamentally different
-types, although we can hook a relation if we are prepared to drop down to
-the <tt>char</tt> type and <tt>char_traits</tt> template parameters.  Doing so ties us to a
-form of serialization that demands implementation via the std iostreams
-framework, which seems overly prescriptive.  I believe the goal is generally
-to support serialization without regard to how it is expressed - although
-this is getting even more inventive in terms of concepts we do not have
-today.
-</p>
+Move to Open. Ping Robert Klarer to provide wording, using N2235 as
+guidance.
 </blockquote>
 
 
+
 <p><b>Proposed resolution:</b></p>
 
 
@@ -24750,137 +20490,192 @@ today.
 
 
 <hr>
-<h3><a name="1062"></a>1062. Missing insert_iterator for stacks/queues</h3>
-<p><b>Section:</b> 24.7 [insert.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">Tentatively NAD Future</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-13  <b>Last modified:</b> 2009-07-29</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#insert.iterators">active issues</a> in [insert.iterators].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#insert.iterators">issues</a> in [insert.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Future">Tentatively NAD Future</a> status.</p>
+<h3><a name="1157"></a>1157. Local types can now instantiate templates</h3>
+<p><b>Section:</b> 17.6.3.2.1 [namespace.std] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-10-21</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 
-<p>
-It is odd that we have an iterator to insert into a <tt>vector</tt>, but not an
-iterator to insert into a <tt>vector</tt> that is adapted as a <tt>stack</tt>. The standard
-container adapters all have a common interface to <tt>push</tt> and <tt>pop</tt> so it should
-be simple to create an iterator adapter to complete the library support.
-</p>
+<p><b>Addresses UK 175</b></p>
 
-<p>
-We should provide an <tt>AdaptedContainer</tt> concept supporting <tt>push</tt> and <tt>pop</tt>
-operations. Create a new insert iterator and factory function that inserts
-values into the container by calling <tt>push</tt>.
-</p>
+<p><b>Description</b></p>
+        <p>Local types can
+        now be used to instantiate templates, but don't have
+        external linkage.</p>
+<p><b>Suggestion</b></p>
+        <p>Remove the reference to external linkage.</p>
+
+<p><b>Notes</b></p>
+<p>We accept the proposed solution. Martin will draft an issue.</p>
 
 <p><i>[
-Batavia (2009-05):
+2009-07-28 Alisdair provided wording.
 ]</i></p>
 
-<blockquote>
-<p>
-Walter recommends NAD Future.
-</p>
-<p>
-Move to Open, and recommend deferring the issue until after the next
-Committee Draft is issued.
-</p>
-</blockquote>
 
 <p><i>[
-2009-07-29 Howard moves to Tentatively NAD Future.
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-A poll on the LWG reflector voted unanimously to move this issue to Tentatively NAD Future.
+Moved to Ready.
 </blockquote>
 
 
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="1064"></a>1064. Response to UK 152</h3>
-<p><b>Section:</b> 17.3.15 [defns.obj.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15  <b>Last modified:</b> 2009-03-15</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 152</b></p>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-Object state is using a definition of object (instance of a class) from
-outside the standard, rather than the 'region of storage' definiton in
-1.8 [intro.object]p1
+17.6.3.2.1 [namespace.std]
+</p>
+<p>
+Strike "of external linkage" in p1 and p2:
 </p>
 
-<p><i>[
-Summit:
-]</i></p>
-
 <blockquote>
-We think we're removing this; See X [func.referenceclosure.cons].
-</blockquote>
-
+<p>
+-1- The behavior of a C++ program is undefined if it adds declarations or
+definitions to namespace <tt>std</tt> or to a namespace within namespace <tt>std</tt>
+unless otherwise specified. A program may add a concept map for any
+standard library concept or a template specialization for any standard
+library template to namespace <tt>std</tt> only if the declaration depends on a
+user-defined type <del>of external linkage</del> and the specialization meets the
+standard library requirements for the original template and is not
+explicitly prohibited.<sup>179</sup>
+</p>
 
-<p><b>Proposed resolution:</b></p>
 <p>
+-2- The behavior of a C++ program is undefined if it declares
+</p>
+<ul>
+<li>
+an explicit specialization of any member function of a standard library
+class template, or
+</li>
+<li>
+an explicit specialization of any member function template of a standard
+library class or class template, or
+</li>
+<li>
+an explicit or partial specialization of any member class template of a
+standard library class or class template.
+</li>
+</ul>
+<p>
+A program may explicitly instantiate a template defined in the standard
+library only if the declaration depends on the name of a user-defined
+type <del>of external linkage</del> and the instantiation meets the standard
+library requirements for the original template.
 </p>
+</blockquote>
+
 
 
 
 
 
 <hr>
-<h3><a name="1068"></a>1068. class random_device should be movable</h3>
-<p><b>Section:</b> 26.5.6 [rand.device] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-18  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.device">issues</a> in [rand.device].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1158"></a>1158. Encouragement to use monotonic clock</h3>
+<p><b>Section:</b> 30.2.4 [thread.req.timing] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-10-31</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 
-<p>
-class <tt>random_device</tt> should be movable.
-</p>
+<p><b>Addresses UK 322, US 96</b></p>
+
+<p><b>Description</b></p>
+        <p>Not all systems
+        can provide a monotonic clock. How are they expected to
+        treat a _for function?</p>
+<p><b>Suggestion</b></p>
+        <p>Add at least a note explaining the intent
+        for systems that do not support a monotonic clock.</p>
+
+<p><b>Notes</b></p>
+<p>Create an issue, together with UK 96. Note that the specification as is 
+    already allows a non-monotonic clock due to the word &#8220;should&#8221; rather than 
+    &#8220;shall&#8221;. If this wording is kept, a footnote should be added to make the 
+    meaning clear.</p>
+
+<p><i>[ 2009-06-29 Beman provided a proposed resolution. ] </i></p>
 
 <p><i>[
-Batavia (2009-05):
+2009-10-31 Howard adds:
 ]</i></p>
 
+
 <blockquote>
-Move to Open, and recommend this issue be deferred until after the next
-Committee Draft is issued.
+Set to Tentatively Ready after 5 positive votes on c++std-lib.
 </blockquote>
 
 
+
 <p><b>Proposed resolution:</b></p>
 
+<p><i>Change Timing specifications 30.2.4 [thread.req.timing] as indicated:</i></p>
+
+<p>The member functions whose names end in <tt>_for</tt> take an argument that
+specifies a relative time. Implementations
+<del>should</del> <ins>are encouraged but not required to</ins> use a
+monotonic clock to measure time for these functions.</p>
+
+
 
 
 
 
 <hr>
-<h3><a name="1069"></a>1069. class seed_seq should support efficient move operations</h3>
-<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-18  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1159"></a>1159. Unclear spec for <tt>resource_deadlock_would_occur</tt></h3>
+<p><b>Section:</b> 30.4.3.2.2 [thread.lock.unique.locking] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-04</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.lock.unique.locking">active issues</a> in [thread.lock.unique.locking].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.lock.unique.locking">issues</a> in [thread.lock.unique.locking].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 
-<p>
-class <tt>seed_seq</tt> should support efficient move operations.
-</p>
+<p><b>Addresses UK 327, UK 328</b></p>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<p><b>UK 327 Description</b></p>
+        <p>Not clear what
+        the specification for error condition
+        <tt>resource_deadlock_would_occur</tt> means. It is perfectly
+        possible for this thread to own the mutex without setting
+        owns to true on this specific lock object. It is also
+        possible for lock operations to succeed even if the thread
+        does own the mutex, if the mutex is recursive. Likewise, if
+        the mutex is not recursive and the mutex has been locked
+        externally, it is not always possible to know that this
+        error condition should be raised, depending on the host
+        operating system facilities. It is possible that 'i.e.' was
+        supposed to be 'e.g.' and that suggests that recursive
+        locks are not allowed. That makes sense, as the
+        exposition-only member owns is boolean and not a integer to
+        count recursive locks.</p>
+        
+<p><b>UK 327 Suggestion</b></p>
+        <p>Add a precondition <tt>!owns</tt>. Change the 'i.e.'
+        in the error condition to be 'e.g.' to allow for this
+        condition to propogate deadlock detection by the host OS.</p>
+<p><b>UK 327 Notes</b></p>
+<p>Create an issue. Assigned to Lawrence Crowl. Note: not sure what try_lock 
+    means for recursive locks when you are the owner. POSIX has language on 
+    this, which should ideally be followed. Proposed fix is not quite right, for 
+    example, try_lock should have different wording from lock.</p>
 
-<blockquote>
-Move to Open, and recommend this issue be deferred until after the next
-Committee Draft is issued.
-</blockquote>
+<p><b>UK 328 Description</b></p>
+
+        <p>There is a missing precondition that <tt>owns</tt>
+        is true, or an <tt>if(owns)</tt> test is missing from the effect
+        clause</p>
+<p><b>UK 328 Suggestion</b></p>
+        <p>Add a
+        precondition that <tt>owns == true</tt>. Add an error condition to
+        detect a violation, rather than yield undefined behaviour.</p>
+<p><b>UK 328 Notes</b></p>
+<p>Handle in same issue as UK 327. Also uncertain that the proposed resolution 
+    is the correct one.</p>
+
+    
 
 
 <p><b>Proposed resolution:</b></p>
@@ -24890,791 +20685,335 @@ Committee Draft is issued.
 
 
 <hr>
-<h3><a name="1071"></a>1071. is_bind_expression should derive from integral_constant&lt;bool&gt;</h3>
-<p><b>Section:</b> 20.7.12.1.1 [func.bind.isbind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19  <b>Last modified:</b> 2009-05-31</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Cosmin Truta <b>Opened:</b> 2009-07-04  <b>Last modified:</b> 2009-07-07</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-
 <p>
-Class template is_bind_expression 20.7.12.1.1 [func.bind.isbind]:
+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>
-
-<blockquote><pre>namespace std {
-  template&lt;class T&gt; struct is_bind_expression {
-    static const bool value = see below;
-  };
-}
-</pre></blockquote>
 <p>
-<tt>is_bind_expression</tt> should derive from <tt>std::integral_constant&lt;bool&gt;</tt> like
-other similar trait types.
+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><i>[
-Daniel adds:
-]</i></p>
-
-<blockquote>
-We need the same thing for the trait <tt>is_placeholder</tt> as well.
-</blockquote>
-<p><i>[
-2009-03-22 Daniel provided wording.
-]</i></p>
-
-
-<p><i>[
-Batavia (2009-05):
-]</i></p>
-
-<blockquote>
 <p>
-We recommend this be deferred until after the next Committee Draft is issued.
+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>±HUGE_VALF</code>,
+<code>±HUGE_VAL</code> and <code>±HUGE_VALL</code>, respectively.
+On the other hand, the result of <code>num_get</code> conversion of such
+out-of-range floating-point values results in the most positive/negative
+representable value.
+Although many C library implementations do implement <code>HUGE_VAL</code>
+(etc.) as the highest representable (which is, usually, the infinity), 
+this
+isn't required by the C standard. The C library specification makes no
+statement regarding the value of <code>HUGE_VAL</code> and friends, which
+potentially raises the same compatibility issue as in the above case of
+unsigned integers.
+In addition, neither C nor C++ define symbolic constants for the maximum
+representable floating-point values (they only do so only for the maximum
+representable <i>finite</i> floating-point values), which raises a 
+usability
+issue (it would be hard for the programmer to check the result of
+<code>num_get</code> against overflow).
 </p>
 <p>
-Move to Open.
+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>
-</blockquote>
 
-<p><i>[
-2009-05-31 Peter adds:
-]</i></p>
 
+<p><b>Proposed resolution:</b></p>
 
-<blockquote>
 <p>
-I am opposed to the proposed resolution and to the premise of the issue
-in general. The traits's default definitions should NOT derive from
-<tt>integral_constant</tt>, because this is harmful, as it misleads people into
-thinking that <tt>is_bind_expression&lt;E&gt;</tt> always derives from
-<tt>integral_constant</tt>, whereas it may not.
+Change 22.4.2.1.2 [facet.num.get.virtuals] as follows:
 </p>
+<blockquote>
 <p>
-<tt>is_bind_expression</tt> and <tt>is_placeholder</tt> allow user
-specializations, and in fact, this is their primary purpose. Such user
-specializations may not derive from <tt>integral_constant</tt>, and the
-places where <tt>is_bind_expression</tt> and <tt>is_placeholder</tt> are
-used intentionally do not require such derivation.
+<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 long-term approach here is to switch to
-<tt>BindExpression&lt;E&gt;</tt> and <tt>Placeholder&lt;P&gt;</tt>
-explicit concepts, of course, but until that happens, I say leave them
-alone.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
-<p>
-In 20.7.12.1.1 [func.bind.isbind] change as indicated:
-</p>
-<blockquote><pre>namespace std {
- template&lt;class T&gt; struct is_bind_expression <ins>: integral_constant&lt;bool, <i>see below</i>&gt; { };</ins><del>{
-   static const bool value = <i>see below</i>;
- };</del>
-}
-</pre></blockquote>
-</li>
-<li>
-<p>
-In 20.7.12.1.1 [func.bind.isbind]/2 change as indicated:
-</p>
-<blockquote><pre><del>static const bool value;</del>
-</pre>
-<blockquote>
--2- <del><tt>true</tt> if <tt>T</tt> is a type returned from <tt>bind</tt>, <tt>false</tt> otherwise.</del>
-  <ins>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 it shall be
-publicly derived from
-          <tt>integral_constant&lt;bool, false&gt;</tt>.</ins>
-</blockquote>
-</blockquote>
-</li>
-<li>
-<p>
-In 20.7.12.1.2 [func.bind.isplace] change as indicated:
-</p>
-<blockquote><pre>namespace std {
- template&lt;class T&gt; struct is_placeholder <ins>: integral_constant&lt;int, <i>see below</i>&gt; { };</ins><del>{
-   static const int value = <i>see below</i>;
- };</del>
-}
-</pre></blockquote>
-</li>
-<li>
-<p>
-In 20.7.12.1.2 [func.bind.isplace]/2 change as indicated:
-</p>
-<blockquote><pre><del>static const int value;</del>
-</pre>
-<blockquote>
--2- <del>value is <tt>J</tt> if <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, 0 otherwise.</del>
-  <ins>If <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, <tt>is_placeholder&lt;T&gt;</tt>
-shall be publicly
-          derived from <tt>integral_constant&lt;int, J&gt;</tt> otherwise it shall
-be publicly derived
-          from <tt>integral_constant&lt;int, 0&gt;</tt>.</ins>
-</blockquote>
-</blockquote>
-</li>
-</ol>
-
-
-
-
-
-<hr>
-<h3><a name="1075"></a>1075. Response to US 65, US 74.1</h3>
-<p><b>Section:</b> 20 [utilities], 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alan Talbot <b>Opened:</b> 2009-03-20  <b>Last modified:</b> 2009-06-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utilities">issues</a> in [utilities].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p><b>Addresses US 65 and US 74.1</b></p>
-
-<p>US 65:</p>
-
-<blockquote>
-Scoped allocators and allocator propagation traits add a small amount of
-utility at the cost of a great deal of machinery. The machinery is user
-visible, and it extends to library components that don't have any
-obvious connection to allocators, including basic concepts and simple
-components like <tt>pair</tt> and <tt>tuple</tt>.
-
-<p>Suggested resolution:</p>
-
-<p>
-Sketch of proposed resolution: Eliminate scoped allocators, replace
-allocator propagation traits with a simple uniform rule (e.g. always
-propagate on copy and move), remove all mention of allocators from
-components that don't explicitly allocate memory (e.g. pair), and adjust
-container interfaces to reflect this simplification.
-</p>
-<p>
-Components that I propose eliminating include HasAllocatorType,
-is_scoped_allocator, allocator_propagation_map, scoped_allocator_adaptor,
-and ConstructibleAsElement.
-</p>
-</blockquote>
-
-<p>US 74.1:</p>
-
-<blockquote>
-<p>
-Scoped allocators represent a poor trade-off for standardization, since
-(1) scoped-allocator--aware containers can be implemented outside the
-C++ standard library but used with its algorithms, (2) scoped
-allocators only benefit a tiny proportion of the C++ community
-(since few C++ programmers even use today's allocators), and (3) all C++
-users, especially the vast majority of the C++ community that won't ever
-use scoped allocators are forced to cope with the interface complexity
-introduced by scoped allocators.
-</p>
-<p>
-In essence, the larger community will suffer to support a very small
-subset of the community who can already implement their own
-data structures outside of the standard library. Therefore, scoped
-allocators should be removed from the working paper.
-</p>
-<p>
-Some evidence of the complexity introduced by scoped allocators:
-</p>
-<blockquote>
-<p>
-20.3.3 [pairs], 20.5 [tuple]: Large increase in the
-number of pair and tuple constructors.
-</p>
-<p>
-23 [containers]: Confusing "AllocatableElement" requirements throughout.
-</p>
-</blockquote>
-<p>Suggested resolution:</p>
-
-<p>
-Remove support for scoped allocators from the working paper. This
-includes at least the following changes:
-</p>
-
-<blockquote>
-<p>
-Remove 20.8.3 [allocator.element.concepts]
-</p>
-<p>
-Remove 20.8.5 [allocator.adaptor]
-</p>
-<p>
-Remove  [construct.element]
-</p>
-<p>
-In Clause 23 [containers]: replace requirements naming the
-<tt>AllocatableElement</tt> concept with requirements naming <tt>CopyConstructible</tt>,
-<tt>MoveConstructible</tt>, <tt>DefaultConstructible</tt>, or <tt>Constructible</tt>, as
-appropriate.
-</p>
-</blockquote>
-
-</blockquote>
-
-<p><i>[
-Post Summit Alan moved from NAD to Open.
-]</i></p>
-
-
-<p><i>[
-2009-05-15 Ganesh adds:
-]</i></p>
-
-
-<blockquote>
-<p>
-The requirement <tt>AllocatableElement</tt> should not be replaced with
-<tt>Constructible</tt> on the <tt>emplace_xxx()</tt> functions as suggested. In the
-one-parameter case the <tt>Constructible</tt> requirement is not satisfied when
-the constructor is explicit (as per 14.10.2.1 [concept.map.fct], twelfth
-bullet) but we do want to allow explicit constructors in emplace, as the
-following example shows:
-</p>
-
-<blockquote><pre>vector&lt;shared_ptr&lt;int&gt;&gt; v;
-v.emplace_back(new int); <font color="#c80000">// should be allowed</font>
-</pre></blockquote>
-
-<p>
-If the issue is accepted and scoped allocators are removed, I suggest to
-add a new pair of concepts to 20.2.7 [concept.construct], namely:
-</p>
-
-<blockquote><pre>auto concept HasExplicitConstructor&lt;typename T, typename... Args&gt; {
- explicit T::T(Args...);
-}
-
-auto concept ExplicitConstructible&lt;typename T, typename... Args&gt;
- : HasExplicitConstructor&lt;T, Args...&gt;, NothrowDestructible&lt;T&gt;
-{ }
-</pre></blockquote>
-
-<p>
-We should then use <tt>ExplicitConstructible</tt> as the requirement for all
-<tt>emplace_xxx()</tt> member functions.
-</p>
-<p>
-For coherence and consistency with the similar concepts
-<tt>Convertible/ExplicitlyConvertible</tt>, we might also consider changing
-<tt>Constructible</tt> to:
-</p>
-
-<blockquote><pre>auto concept Constructible&lt;typename T, typename... Args&gt;
- : HasConstructor&lt;T, Args...&gt;, ExplicitConstructible&lt;T, Args...&gt;
-{ }
-</pre></blockquote>
-
-<p>
-Moreover, all emplace-related concepts in 23.2.6 [container.concepts]
-should also use <tt>ExplicitConstructible</tt> instead of <tt>Constructible</tt> in the
-definitions of their axioms. In fact the concepts in 23.2.6 [container.concepts] should be
-corrected even if the issue is not accepted.
-</p>
-<p>
-On the other hand, if the issue is not accepted, the scoped allocator
-adaptors should be fixed because the following code:
-</p>
-
-<blockquote><pre>template &lt;typename T&gt; using scoped_allocator = scoped_allocator_adaptor&lt;allocator&lt;T&gt;&gt;;
-
-vector&lt;shared_ptr&lt;int&gt;, scoped_allocator&lt;shared_ptr&lt;int&gt;&gt;&gt; v;
-v.emplace_back(new int); <font color="#c80000">// ops! doesn't compile</font>
-</pre></blockquote>
-
-<p>
-doesn't compile, as the member function <tt>construct()</tt> of the scoped
-allocator requires non-explicit constructors through concept
-<tt>ConstructibleWithAllocator</tt>. Fixing that is not difficult but probably
-more work than it's worth and is therefore, IMHO, one more reason in
-support of the complete removal of scoped allocators.
-</p>
-</blockquote>
-
-<p><i>[
-2009-06-09 Alan adds:
-]</i></p>
-
-
-<blockquote>
-<p>
-I reopened this issue because I did not think that these National Body
-comments were adequately addressed by marking them NAD. My understanding
-is that something can be marked NAD if it is clearly a misunderstanding
-or trivial, but a substantive issue that has any technical merit
-requires a disposition that addresses the concerns.
-</p>
-<p>
-The notes in the NB comment list (US 65 &amp; US 74.1) say that:
-</p>
-<ol type="a">
-<li>
-this issue has not introduced any new arguments not previously discussed,
-</li>
-<li>
-the vote (4-9-3) was not a consensus for removing scoped allocators,
-</li>
-<li>
-the issue is resolved by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>.
-</li>
-</ol>
-<p>
-My opinion is:
-</p>
-<ol type="a">
-<li>
-there are new arguments in both comments regarding concepts (which were
-not present in the library when the scoped allocator proposal was voted
-in),
-</li>
-<li>
-the vote was clearly not a consensus for removal, but just saying there
-was a vote does not provide a rationale,
-</li>
-<li>
-I do not believe that N2840 addresses these comments (although it does
-many other things and was voted in with strong approval).
-</li>
-</ol>
-
-<p>
-My motivation to open the issue was to ensure that the NB comments were
-adequately addressed in a way that would not risk a "no" vote on our
-FCD. If there are responses to the technical concerns raised, then
-perhaps they should be recorded. If the members of the NB who authored
-the comments are satisfied with N2840 and the other disposition remarks
-in the comment list, then I am sure they will say so. In either case,
-this issue can be closed very quickly in Frankfurt, and hopefully will
-have helped make us more confident of approval with little effort. If in
-fact there is controversy, my thought is that it is better to know now
-rather than later so there is more time to deal with it.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="1076"></a>1076. unary/binary_negate need constraining and move support</h3>
-<p><b>Section:</b> 20.7.11 [negators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-20  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The class templates <tt>unary/binary_negate</tt> need constraining and move support.
-</p>
-<p>
-Ideally these classes would be deprecated, allowing <tt>unary/binary_function</tt> to
-also be deprecated.  However, until a generic negate adaptor is introduced
-that can negate any <tt>Callable</tt> type, they must be supported so should be
-constrained.  Likewise, they should be movable, and support adopting a
-move-only predicate type.
-</p>
-<p>
-In order to preserve ABI compatibility, new rvalue overloads are supplied in
-preference to changing the existing pass-by-const-ref to pass-by-value.
-</p>
-<p>
-Do not consider the issue of forwarding mutable lvalues at this point,
-although remain open to another issue on the topic.
-</p>
-
-<p><i>[
-2009-05-01 Daniel adds:
-]</i></p>
-
-<blockquote>
-<p>
-IMO the currently proposed resolution needs some updates
-because it is ill-formed at several places:
-</p>
-
-<ol>
-<li>
-<p>
-In concept AdaptableUnaryFunction change
-</p>
-<blockquote><pre>typename X::result_type;
-typename X::argument_type;
-</pre></blockquote>
-<p>
-to
-</p>
-<blockquote><pre>Returnable result_type = typename X::result_type;
-typename argument_type = typename X::argument_type;
-</pre></blockquote>
-<p>
-[The replacement "Returnable result_type" instead of "typename
-result_type" is non-editorial, but maybe you prefer that as well]
-</p>
-</li>
-<li>
-<p>
-In concept AdaptableBinaryFunction change
-</p>
-<blockquote><pre>typename X::result_type;
-typename X::first_argument_type;
-typename X::second_argument_type;
-</pre></blockquote>
-<p>
-to
-</p>
-<blockquote><pre>Returnable result_type = typename X::result_type;
-typename first_argument_type = typename X::first_argument_type;
-typename second_argument_type = typename X::second_argument_type;
-</pre></blockquote>
-<p>
-[The replacement "Returnable result_type" instead of "typename
-result_type" is non-editorial, but maybe you prefer that as well.]
-</p>
-</li>
-
-<li>
-<p>
-In class unary/binary_function
-</p>
-<ol type="a">
-<li>
-I suggest to change "ReturnType" to "Returnable" in both cases.
-</li>
-<li>
-I think you want to replace the remaining occurrences of "Predicate" by "P"
-(in both classes in copy/move from a predicate)
-</li>
-</ol>
-</li>
-<li>
-<p>
-I think you need to change the proposed signatures of not1 and not2, because
-they would still remain unconstrained: To make them constrained at least a
-single requirement needs to be added to enable requirement implication. This
-could be done via a dummy ("requires True&lt;true&gt;") or just explicit as follows:
-</p>
-<ol type="a">
-<li>
-<blockquote><pre>template &lt;AdaptableUnaryFunction P&gt;
-requires Predicate&lt; P, P::argument_type&gt;
-unary_negate&lt;P&gt; not1(const P&amp;&amp; pred);
-template &lt;AdaptableUnaryFunction P&gt;
-requires Predicate&lt; P, P::argument_type &gt;
-unary_negate&lt;P&gt; not1(P&amp;&amp; pred);
-</pre>
-<blockquote>
--3- Returns: unary_negate&lt;P&gt;(pred).
-</blockquote>
-</blockquote>
-<p>
-[Don't we want a move call for the second overload as in
-</p>
-<blockquote><pre>unary_negate&lt;P&gt;(std::move(pred))
-</pre></blockquote>
-<p>
-in the Returns clause ?]
-</p>
-</li>
-<li>
-<pre>template &lt;AdaptableBinaryFunction P&gt;
-requires Predicate&lt; P, P::first_argument_type, P::second_argument_type &gt;
-binary_negate&lt;P&gt; not2(const P&amp; pred);
-template &lt;AdaptableBinaryFunction P&gt;
-requires Predicate&lt; P, P::first_argument_type, P::second_argument_type &gt;
-binary_negate&lt;P&gt; not2(P&amp;&amp; pred);
-</pre>
-<p>
--5- Returns: binary_negate&lt;P&gt;(pred).
-</p>
-<p>
-[Don't we want a move call for the second overload as in
-</p>
-<blockquote><pre>binary_negate&lt;P&gt;(std::move(pred))
-</pre></blockquote>
-<p>
-in the Returns clause ?]
-</p>
-</li>
-</ol>
-</li>
-</ol>
-</blockquote>
-
-<p><i>[
-Batavia (2009-05):
-]</i></p>
-
-<blockquote>
-<p>
-There is concern that complicating the solution
-to preserve the ABI seems unnecessary,
-since we're not in general preserving the ABI.
-</p>
-<p>
-We would prefer a separate paper consolidating all Clause 20
-issues that are for the purpose of providing constrained versions
-of the existing facilities.
+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>
-Move to Open.
+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>
 
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Add new concepts where appropriate::
-</p>
-
-<blockquote><pre>auto concept AdaptableUnaryFunction&lt; typename X &gt; {
-  typename X::result_type;
-  typename X::argument_type;
-}
-
-auto concept AdaptableBinaryFunction&lt; typename X &gt; {
-  typename X::result_type;
-  typename X::first_argument_type;
-  typename X::second_argument_type;
-}
-</pre></blockquote>
-
-<p>
-Revise as follows:
-</p>
-
-<p>
-Base 20.7.3 [base] (Only change is constrained Result)
-</p>
-
-<blockquote>
-<p>
--1-  The following classes are provided to simplify the typedefs of the
-argument and result types:
-</p>
-<pre>namespace std {
-  template &lt;class Arg, <del>class</del> <ins>ReturnType</ins> Result&gt;
-  struct unary_function {
-     typedef Arg    argument_type;
-     typedef Result result_type;
-  };
-
-  template &lt;class Arg1, class Arg2, <del>class</del> <ins>ReturnType</ins> Result&gt;
-  struct binary_function {
-     typedef Arg1   first_argument_type;
-     typedef Arg2   second_argument_type;
-     typedef Result result_type;
-  };
-}
-</pre></blockquote>
-
-<p>
-Negators 20.7.11 [negators]:
-</p>
-
-<blockquote>
-<p>
--1- Negators <tt>not1</tt> and <tt>not2</tt> take a unary and a binary predicate,
-respectively, and return their complements (5.3.1).
-</p>
-
-<pre>template &lt;<del>class</del> <ins>AdaptableUnaryFunction</ins> P<del>redicate</del>&gt;
-  <ins>requires Predicate&lt; P, P::argument_type &gt;</ins>
-  class unary_negate
-    : public unary_function&lt;<del>typename</del> P<del>redicate</del>::argument_type,bool&gt; {
-  public:
-    <ins>unary_negate(const unary_negate &amp; ) = default;</ins>
-    <ins>unary_negate(unary_negate &amp;&amp; );</ins>
-
-    <ins>requires CopyConstructible&lt; P &gt;</ins>
-       explicit unary_negate(const Predicate&amp; pred); 
-    <ins>requires MoveConstructible&lt; P &gt;
-       explicit unary_negate(Predicate &amp;&amp; pred);</ins>
 
-    bool operator()(const <del>typename</del> P<del>redicate</del>::argument_type&amp; x) const;
-  };
-</pre>
-<blockquote>
--2 <tt>operator()</tt> returns <tt>!pred(x)</tt>.
-</blockquote>
 
-<pre>template &lt;class Predicate&gt;
-  unary_negate&lt;Predicate&gt; not1(const Predicate&amp;amp; pred);
-<ins>template &lt;class Predicate&gt;
-  unary_negate&lt;Predicate&gt; not1(Predicate&amp;&amp; pred);</ins>
-</pre>
-<blockquote>
--3-  <i>Returns:</i> <tt>unary_negate&lt;Predicate&gt;(pred)</tt>.
-</blockquote>
 
-<pre>template &lt;<del>class</del> <ins>AdaptableBinaryFunction</ins> P<del>redicate</del> &gt;
-  <ins>requires Predicate&lt; P, P::first_argument_type, P::second_argument_type &gt;</ins>
-  class binary_negate
-    : public binary_function&lt;<del>typename</del> P<del>redicate</del>::first_argument_type,
-                              <del>typename</del> P<del>redicate</del>::second_argument_type, bool&gt; {
-  public:
-    <ins>biary_negate(const binary_negate &amp; ) = default;</ins>
-    <ins>binary_negate(binary_negate &amp;&amp; );</ins>
 
-    <ins>requires CopyConstructible&lt; P &gt;</ins>
-       explicit binary_negate(const Predicate&amp; pred);
-    <ins>requires MoveConstructible&lt; P &gt;
-       explicit binary_negate(const Predicate&amp; pred);</ins>
+<hr>
+<h3><a name="1170"></a>1170. String <i>char-like types</i> no longer PODs</h3>
+<p><b>Section:</b> 21.1 [strings.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-06-22  <b>Last modified:</b> 2009-11-04</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 
-    bool operator()(const <del>typename</del> P<del>redicate</del>::first_argument_type&amp; x,
-                    const <del>typename</del> P<del>redicate</del>::second_argument_type&amp; y) const;
-  };
-</pre>
+<p><b>Addresses UK 218</b></p>
+
+<p>Prior to the introduction of constant expressions into the library, 
+<tt>basic_string</tt> elements had to be POD types, and thus had to be both trivially 
+copyable and standard-layout. This ensured that they could be memcpy'ed and 
+would be compatible with other libraries and languages, particularly the C 
+language and its library.</p>
+<p>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>,
+Constant Expressions in the Standard Library Revision 2, changed the 
+requirement in 21/1 from "POD type" to "literal type". That change had the 
+effect of removing the trivially copyable and standard-layout requirements from 
+<tt>basic_string</tt> elements.</p>
+<p>This means that <tt>basic_string</tt> elements no longer are guaranteed to be 
+memcpy'able, and are no longer guaranteed to be standard-layout types:</p>
 <blockquote>
--4- <tt>operator()</tt> returns <tt>!pred(x,y)</tt>.
+  <p>3.9/p2 and 3.9/p3 both make it clear that a "trivially copyable type" is 
+  required for memcpy to be guaranteed to work.</p>
+  <p>Literal types (3.9p12) may have a non-trivial copy assignment operator, and 
+  that violates the trivially copyable requirements given in 9/p 6, bullet item 
+  2. </p>
+  <p>Literal types (3.9p12) have no standard-layout requirement, either.</p>
 </blockquote>
+<p>This situation probably arose because the wording for "Constant Expressions 
+in the Standard Library" was in process at the same time the C++ POD 
+deconstruction wording was in process. </p>
+<p>Since trivially copyable types meet the C++0x requirements for literal types, 
+and thus work with constant expressions, it seems an easy fix to revert the 
+<tt>basic_string</tt> element wording to its original state.</p>
 
-<pre>template &lt;class Predicate&gt;
-  binary_negate&lt;Predicate&gt; not2(const Predicate&amp; pred);
-<ins>template &lt;class Predicate&gt;
-  binary_negate&lt;Predicate&gt; not2(Predicate&amp;&amp; pred);</ins>
-</pre>
+ <p><i>[
+ 2009-07-28 Alisdair adds:
+ ]</i></p>
 
+ 
 <blockquote>
--5- <i>Returns:</i> <tt>binary_negate&lt;Predicate&gt;(pred)</tt>.
-</blockquote>
+When looking for any resolution for this issue, consider the definition of
+"character container type" in 17.3.4 [defns.character.container].  This
+does require the character type to be a POD, and this term is used in a
+number of places through clause 21 and 28. This suggests the PODness
+constraint remains, but is much more subtle than before.  Meanwhile, I
+suspect the change from POD type to literal type was intentional with
+the assumption that trivially copyable types with
+non-trivial-but-constexpr constructors should serve as well.  I don't
+believe the current wording offers the right guarantees for either of
+the above designs.
 </blockquote>
 
+<p><i>[
+2009-11-04 Howard modifies proposed wording to disallow array types as
+char-like types.
+]</i></p>
 
 
 
 
-
-<hr>
-<h3><a name="1079"></a>1079. UK-265: <code>RandomAccessIterator</code>'s <code>operator-</code> has nonsensical effects clause</h3>
-<p><b>Section:</b> 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2009-03-20  <b>Last modified:</b> 2009-03-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#random.access.iterators">active issues</a> in [random.access.iterators].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p><b>Addresses UK 265</b></p>
-
-<p>UK-265:</p>
-<p>
-This effects clause is nonesense. It looks more like an axiom stating
-equivalence, and certainly an effects clause cannot change the state of
-two arguments passed by const reference
-</p>
-
-
-
 <p><b>Proposed resolution:</b></p>
 
-<p>Modify 24.2.6 [random.access.iterators]p7-9 as follows:</p>
-
-<blockquote><pre>difference_type operator-(const X&amp; a, const X&amp; b);
-</pre>
-<ol start="7">
-  <li><i>Precondition</i>: there exists a value <code>n</code> of
-  <code>difference_type</code> such that <code>a == b + n</code>.</li>
-  <li><del><i>Effects</i>: <code>b == a + (b - a)</code></del></li>
-  <li><i>Returns</i>: <del><code>(a &lt; b) ? distance(a,b) :
-  -distance(b,a)</code></del><ins><code>n</code></ins></li>
-</ol>
+<p><i>Change General 21.1 [strings.general] as indicated:</i></p>
+<blockquote>
+<p>This Clause describes components for manipulating sequences of any
+<del>literal</del> <ins>non-array POD</ins> (3.9) type. In this Clause
+such types are called <i>char-like types</i>, and objects of char-like
+types are called <i>char-like objects</i> or simply
+<i>characters</i>.</p>
 </blockquote>
 
 
 
 
 
+
 <hr>
-<h3><a name="1088"></a>1088. Response to UK 342</h3>
-<p><b>Section:</b> 30.6.4 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-03-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
+<h3><a name="1171"></a>1171. duration types should be literal</h3>
+<p><b>Section:</b> 20.9.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-06  <b>Last modified:</b> 2009-10-31</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.duration">active issues</a> in [time.duration].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration">issues</a> in [time.duration].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
-<p><b>Addresses UK 342</b></p>
-
-<p>
-<tt>std::promise</tt> is missing a non-member overload of <tt>swap</tt>. This is
-inconsistent with other types that provide a <tt>swap</tt> member function.
-</p>
-
 <p>
-Add a non-member overload <tt>void swap(promise&amp;&amp; x,promise&amp;&amp; y){ x.swap(y); }</tt>
+The <tt>duration</tt> types in 20.9.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>[
-Summit:
+2009-09-21 Daniel adds:
 ]</i></p>
 
+
 <blockquote>
-Create an issue. Move to review, attention: Howard. Detlef will also
-look into it.
+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>[
-Post Summit Daniel provided wording.
+2009-10-30 Alisdair adds:
 ]</i></p>
 
 
-
-<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
+<blockquote>
 <p>
-In 30.6.4 [futures.promise], before p.1, immediately after class template
-promise add:
+I suggest this issue moves from New to Open.
 </p>
-<blockquote><pre><ins>
-template &lt;class R&gt;
-void swap(promise&lt;R&gt;&amp; x, promise&lt;R&gt;&amp; y);
-</ins>
-</pre></blockquote>
-</li>
-<li>
+
 <p>
-Change 30.6.4 [futures.promise]/10 as indicated (to fix a circular definition):
+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>
-<blockquote>
+
 <p>
--10- <i>Effects:</i> <del>swap(*this, other)</del><ins>Swaps the associated state
-of <tt>*this</tt> and <tt>other</tt></ins>
+The other half (duration arithmetic) is on hold pending Core support for
+<tt>const &amp;</tt> in <tt>constexpr</tt> functions.
 </p>
+
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-<ins><i>Throws:</i> Nothing.</ins>
+Add <tt>constexpr</tt> to declaration of following functions and constructors:
 </p>
-</blockquote>
-</li>
-<li>
 <p>
-After the last paragraph in 30.6.4 [futures.promise] add the following
-prototype description:
+p1 20.9 [time]
 </p>
-<blockquote><pre><ins>
-template &lt;class R&gt;
-void swap(promise&lt;R&gt;&amp; x, promise&lt;R&gt;&amp; y);
-</ins></pre>
+
 <blockquote>
 <p>
-<ins><i>Effects:</i> <tt>x.swap(y)</tt></ins>
+<b>Header <tt>&lt;chrono&gt;</tt> synopsis</b>
 </p>
+
+<p><i>[Draughting note - observe switch to pass-by-value to support constexpr]</i></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+(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> 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-(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> 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*(<del>const</del> duration&lt;Rep1, Period&gt;<del>&amp;</del> d, <del>const</del> Rep2<del>&amp;</del> 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*(<del>const</del> Rep1<del>&amp;</del> s, <del>const</del> duration&lt;Rep2, Period&gt;<del>&amp;</del> 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/(<del>const</del> duration&lt;Rep1, Period&gt;<del>&amp;</del> d, <del>const</del> Rep2<del>&amp;</del> s);
+template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
+   typename common_type&lt;Rep1, Rep2&gt;::type
+   <ins>constexpr</ins> operator/(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
+
+<i>// duration comparisons</i>
+template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
+   <ins>constexpr</ins> bool operator==(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
+template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
+   <ins>constexpr</ins> bool operator!=(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
+template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
+   <ins>constexpr</ins> bool operator&lt; (<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
+template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
+   <ins>constexpr</ins> bool operator&lt;=(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
+template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
+   <ins>constexpr</ins> bool operator&gt; (<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
+template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
+   <ins>constexpr</ins> bool operator&gt;=(<del>const</del>  duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
+
+<i>// duration_cast</i>
+template &lt;class ToDuration, class Rep, class Period&gt;
+   <ins>constexpr</ins> ToDuration duration_cast(<del>const</del> duration&lt;Rep, Period&gt;<del>&amp;</del> d);
+</pre>
+
 <p>
-<ins><i>Throws:</i> Nothing.</ins>
+<b>20.9.3 [time.duration]</b>
 </p>
-</blockquote>
-</blockquote>
-</li>
 
-</ol>
+<pre>template &lt;class Rep, class Period = ratio&lt;1&gt;&gt;
+class duration {
+  ....
+public:
+  <i>// 20.9.3.1, construct/copy/destroy:</i>
+ <ins>constexpr</ins> duration() = default;
+
+ template &lt;class Rep2&gt;
+   <ins>constexpr</ins> explicit duration(const Rep2&amp; r);
+ template &lt;class Rep2, class Period2&gt;
+   <ins>constexpr</ins> duration(const duration&lt;Rep2, Period2&gt;&amp; d);
+
+  <ins>constexpr</ins> duration(const duration&amp;) = default;
+
+  <i>// 20.9.3.2, observer:</i>
+  <ins>constexpr</ins> rep count() const;
+
+  <i>// 20.9.3.3, arithmetic:</i>
+  <ins>constexpr</ins> duration operator+() const;
+  <ins>constexpr</ins> duration operator-() const;
+  ...
+
+};
+</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>
 
 
 
@@ -25682,419 +21021,319 @@ void swap(promise&lt;R&gt;&amp; x, promise&lt;R&gt;&amp; y);
 
 
 <hr>
-<h3><a name="1089"></a>1089. Response to JP 76</h3>
-<p><b>Section:</b> 30 [thread] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-08-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread">issues</a> in [thread].</p>
+<h3><a name="1173"></a>1173. "Equivalence" wishy-washiness</h3>
+<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-07-14  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p><b>Addresses JP 76</b></p>
-
+<p><b>Discussion:</b></p>
 <p>
-A description for "Throws: Nothing." are not unified.
+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>
-At the part without throw, "Throws: Nothing." should be described.
+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>
-Add "Throws: Nothing." to the following.
+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>
-
-<ul>
-<li>
-30.3.1.6 [thread.thread.static] p1
-</li>
-<li>
-30.4.3.1 [thread.lock.guard] p4
-</li>
-<li>
-30.4.3.2.1 [thread.lock.unique.cons] p6
-</li>
-<li>
-30.5.1 [thread.condition.condvar] p7 and p8
-</li>
-<li>
-30.5.2 [thread.condition.condvarany] p6, p7, p19, p21 and p25
-</li>
-</ul>
 
 <p><i>[
-Summit:
+2009 Santa Cruz:
 ]</i></p>
 
+
 <blockquote>
-Pass on to editor.
+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>[
-Post Summit:  Editor declares this non-editorial.
-]</i></p>
 
 
-<p><i>[
-2009-08-01 Howard provided wording:
-]</i></p>
+<p><b>Proposed resolution:</b></p>
+
+
 
 
-<blockquote>
 
+<hr>
+<h3><a name="1175"></a>1175. <tt>unordered</tt> complexity</h3>
+<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-07-17  <b>Last modified:</b> 2009-07-19</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-The definition of "<i>Throws:</i> Nothing." that I added is probably going to
-be controversial, but I beg you to consider it seriously.
+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>
 
-<blockquote>
 <p>
-In C++ there are three "flow control" options for a function:
+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>
 
-<ol>
-<li>
-It can return, either with a value, or with <tt>void</tt>.
-</li>
-<li>
-It can call a function which never returns, such as <tt>std::exit</tt> or
-<tt>std::terminate</tt>.
-</li>
-<li>
-It can throw an exception.
-</li>
-</ol>
-
-The above list can be abbreviated with:
-
-<ol>
-<li><b>R</b>eturns.</li>
-<li><b>E</b>nds program.</li>
-<li><b>T</b>hrows exception.</li>
-</ol>
-
 <p>
-In general a function can have the behavior of any of these 3, or any combination
-of any of these three, depending upon run time data.
+For the iterator-based constructor the complexity should be:
 </p>
 
-<ol>
-<li><b>R</b></li>
-<li><b>E</b></li>
-<li><b>T</b></li>
-<li><b>RE</b></li>
-<li><b>RT</b></li>
-<li><b>ET</b></li>
-<li><b>RET</b></li>
-</ol>
+<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>
-A function with no throw spec, and no documentation, is in general a <b>RET</b>
-function.  It may return, it may end the program, or it may throw.  When we
-specify a function with an empty throw spec:
-</p>
 
-<blockquote><pre>void f() throw();
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-We are saying that <tt>f()</tt> is an <b>RE</b> function:  It may return or end
-the program, but it will not throw.
 </p>
 
-<p>
-I posit that there are very few places in the library half of the standard
-where we intend for functions to be able to end the program (call <tt>terminate</tt>).
-And none of those places where we do say <tt>terminate</tt> could be called,
-do we currently say "<i>Throws:</i> Nothing.".
-</p>
 
-<p>
-I believe that if we define "<i>Throws:</i> Nothing." to mean <b>R</b>,
-we will both clarify many, many places in the standard, <em>and</em> give us a
-good rationale for choosing between "<i>Throws:</i> Nothing." (<b>R</b>)
-and <tt>throw()</tt> (<b>RE</b>) in the future.  Indeed, this may give us motivation
-to change several <tt>throw()</tt>s to "<i>Throws:</i> Nothing.".
-</p>
-</blockquote>
 
-<p>
-I did not add the following changes as JP 76 requested as I believe we want to
-allow these functions to throw:
-</p>
 
-<blockquote>
+
+<hr>
+<h3><a name="1176"></a>1176. Make <tt>thread</tt> constructor non-variadic</h3>
+<p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-07-18  <b>Last modified:</b> 2009-07-18</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Add a paragraph under 30.4.3.1 [thread.lock.guard] p4:
+The variadic <tt>thread</tt> constructor is causing controversy, e.g.
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2901.pdf">N2901</a>.
+This issue has been created as a placeholder for this course of action.
 </p>
 
-<blockquote><pre>explicit lock_guard(mutex_type&amp; m);
-</pre>
-
-<p><ins>
-<i>Throws:</i> Nothing.
-</ins></p>
-</blockquote>
+<blockquote><pre>template &lt;class F<del>, class ...Args</del>&gt; thread(F&amp;&amp; f<del>, Args&amp;&amp;... args</del>);
+</pre></blockquote>
 
 <p>
-Add a paragraph under 30.4.3.2.1 [thread.lock.unique.cons] p6:
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a> for wording which specifies an rvalue-ref signature but
+with "decay behavior", but using variadics.
 </p>
 
-<blockquote><pre>explicit unique_lock(mutex_type&amp; m);
-</pre>
-
-<p><ins>
-<i>Throws:</i> Nothing.
-</ins></p>
-</blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-Add a paragraph under 30.5.2 [thread.condition.condvarany] p19, p21 and p25:
 </p>
 
-<blockquote><pre>template &lt;class Lock, class Rep, class Period&gt; 
-  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
-</pre>
 
-<p><ins>
-<i>Throws:</i> Nothing.
-</ins></p>
-</blockquote>
 
-<blockquote><pre>template &lt;class Lock, class Duration, class Predicate&gt; 
-  bool wait_until(Lock&amp; lock, const chrono::time_point&lt;Clock, Duration&gt;&amp; rel_time, Predicate pred);
-</pre>
 
-<p><ins>
-<i>Throws:</i> Nothing.
-</ins></p>
-</blockquote>
 
-<blockquote><pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt; 
-  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);
-</pre>
+<hr>
+<h3><a name="1177"></a>1177. Improve "diagnostic required" wording</h3>
+<p><b>Section:</b> 20.9.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-07-18  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.duration">active issues</a> in [time.duration].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration">issues</a> in [time.duration].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+"diagnostic required" has been used (by me) for code words meaning "use
+<tt>enable_if</tt> to constrain templated functions.  This needs to be
+improved by referring to the function signature as not participating in
+the overload set, and moving this wording to a <i>Remarks</i> paragraph.
+</p>
 
-<p><ins>
-<i>Throws:</i> Nothing.
-</ins></p>
-</blockquote>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
-</blockquote>
 
+<blockquote>
+Moved to Ready.
 </blockquote>
 
 
 
-
-
 <p><b>Proposed resolution:</b></p>
-<p>
-Add a paragraph after 17.5.1.4 [structure.specifications] p4:
-</p>
-
-<blockquote>
-<p>
--3- Descriptions of function semantics contain the following elements
-(as appropriate):<sup>158</sup>
-</p>
-<ul>
-<li>...</li>
-<li>
-<i>Throws:</i> any exceptions thrown by the function, and the conditions
-that would cause the exception
-</li>
-<li>...</li>
-</ul>
-
-<p>
--4- For non-reserved replacement and handler functions, ...
-</p>
+<p><i>[
+This proposed resolution addresses <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#947">947</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>. 
+]</i></p>
 
-<p><ins>
-A "<i>Throws:</i> Nothing." element indicates that the function shall
-return ordinarily, and not via an exception.  This element also
-indicates that the function <em>shall</em> return. [<i>Note:</i> This
-differs from an empty throw specification which may cause a function to
-call <tt>unexpected</tt> and subsequently <tt>terminate</tt>. &#8212;
-<i>end note</i>]
-</ins></p>
-</blockquote>
 
+<ol>
+<li>
 <p>
-Add a paragraph under 30.3.1.6 [thread.thread.static] p1:
+Change 20.9.3.1 [time.duration.cons]:
 </p>
 
-<blockquote><pre>unsigned hardware_concurrency();
+<blockquote>
+<pre>template &lt;class Rep2&gt; 
+  explicit duration(const Rep2&amp; r);
 </pre>
-
+<blockquote>
+<p>
+<i><del>Requires:</del> <ins>Remarks:</ins></i>
+<tt>Rep2</tt> shall be implicitly convertible to <tt>rep</tt> and
+</p>
+<ul>
+<li>
+<tt>treat_as_floating_point&lt;rep&gt;::value</tt> shall be <tt>true</tt> or
+</li>
+<li>
+<tt>treat_as_floating_point&lt;Rep2&gt;::value</tt> shall be <tt>false</tt>.
+</li>
+</ul>
 <p>
--1- <i>Returns:</i> ...
+<del>Diagnostic required</del> <ins>If these constraints are not met, this
+constructor shall not participate in overload resolution</ins>. [<i>Example:</i>
 </p>
-
-<p><ins>
-<i>Throws:</i> Nothing.
-</ins></p>
-</blockquote>
+<blockquote><pre>duration&lt;int, milli&gt; d(3); // OK 
+duration&lt;int, milli&gt; d(3.5); // error 
+</pre></blockquote>
 
 <p>
-Add a paragraph under 30.5.1 [thread.condition.condvar] p7 and p8:
+&#8212; <i>end example</i>]
 </p>
 
-<blockquote>
 <p>
-<i>[Informational, not to be incluced in the WP: The POSIX spec allows only:</i>
+<i>Effects:</i> Constructs an object of type <tt>duration</tt>.
 </p>
-<dl>
-<dt><i>[EINVAL]</i></dt>
-<dd><i>The value <tt>cond</tt> does not refer to an initialized condition variable. &#8212; end informational]</i></dd>
-</dl>
-
-<pre>void notify_one();
-</pre>
 
 <p>
--7- <i>Effects:</i> ...
+<i>Postcondition:</i> <tt>count() == static_cast&lt;rep&gt;(r)</tt>.
 </p>
 
-<p><ins>
-<i>Throws:</i> Nothing.
-</ins></p>
 </blockquote>
 
-<blockquote><pre>void notify_all();
+<pre>template &lt;class Rep2, class Period2&gt;
+  duration(const duration&lt;Rep2, Period2&gt;&amp; d);
 </pre>
-
+<blockquote>
 <p>
--8- <i>Effects:</i> ...
+<i><del>Requires:</del> <ins>Remarks:</ins></i> <tt>treat_as_floating_point&lt;rep&gt;::value</tt> shall be <tt>true</tt> or
+<tt>ratio_divide&lt;Period2, period&gt;::type::den</tt> shall be 1<del>. Diagnostic
+required</del><ins>, else this constructor shall not participate in overload
+resolution</ins>. [<i>Note:</i> This requirement prevents implicit truncation error
+when converting between integral-based duration types. Such a
+construction could easily lead to confusion about the value of the
+duration. &#8212; <i>end note</i>] [<i>Example:</i>
 </p>
 
-<p><ins>
-<i>Throws:</i> Nothing.
-</ins></p>
-</blockquote>
-
+<blockquote><pre>duration&lt;int, milli&gt; ms(3); 
+duration&lt;int, micro&gt; us = ms; // OK 
+duration&lt;int, milli&gt; ms2 = us; // error 
+</pre></blockquote>
 
 <p>
-Add a paragraph under 30.5.2 [thread.condition.condvarany] p6 and p7:
+&#8212; <i>end example</i>]
 </p>
 
-<blockquote>
-<pre>void notify_one();
-</pre>
-
 <p>
--6- <i>Effects:</i> ...
+<i>Effects:</i> Constructs an object of type <tt>duration</tt>, constructing
+<tt>rep_</tt> from
+<tt>duration_cast&lt;duration&gt;(d).count()</tt>.
 </p>
 
-<p><ins>
-<i>Throws:</i> Nothing.
-</ins></p>
 </blockquote>
 
-<blockquote><pre>void notify_all();
-</pre>
-
-<p>
--7- <i>Effects:</i> ...
-</p>
 
-<p><ins>
-<i>Throws:</i> Nothing.
-</ins></p>
 </blockquote>
+</li>
 
-
-
-
-
-
-
-<hr>
-<h3><a name="1090"></a>1090. Missing description of <tt>packaged_task</tt> member <tt>swap</tt>,  missing non-member <tt>swap</tt></h3>
-<p><b>Section:</b> 30.6.7 [futures.task] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-05-24</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<li>
 <p>
-Class template <tt>packaged_task</tt> in 30.6.7 [futures.task] shows a member <tt>swap</tt>
-declaration, but misses to
-document it's effects (No prototype provided). Further on this class
-misses to provide a non-member
-swap.
+Change the following paragraphs in 20.9.3.5 [time.duration.nonmember]:
 </p>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
-
 <blockquote>
-<p>
-Alisdair notes that paragraph 2 of the proposed resolution has already been
-applied in the current Working Draft.
-</p>
-<p>
-We note a pending <tt>future</tt>-related paper by Detlef;
-we would like to wait for this paper before proceeding.
-</p>
-<p>
-Move to Open.
-</p>
+<pre>template &lt;class Rep1, class Period, class Rep2&gt; 
+  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt; 
+  operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
+</pre>
+<blockquote>
+<i><del>Requires</del> <ins>Remarks</ins>:</i> <tt>Rep2</tt> shall be implicitly convertible to
+<tt>CR(Rep1, Rep2)</tt><ins>, else this signature shall not participate in
+overload resolution</ins>. <del>Diagnostic required.</del>
 </blockquote>
 
-<p><i>[
-2009-05-24 Daniel removed part 2 of the proposed resolution.
-]</i></p>
+<pre>template &lt;class Rep1, class Period, class Rep2&gt; 
+  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt; 
+  operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
+</pre>
+<blockquote>
+<i><del>Requires</del> <ins>Remarks</ins>:</i> <tt>Rep1</tt> shall be implicitly convertible to
+<tt>CR(Rep1, Rep2)</tt><ins>, else this signature shall not participate in
+overload resolution</ins>. <del>Diagnostic required.</del>
+</blockquote>
 
+<pre>template &lt;class Rep1, class Period, class Rep2&gt; 
+  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt; 
+  operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
+</pre>
+<blockquote>
+<i><del>Requires</del> <ins>Remarks</ins>:</i> <tt>Rep2</tt> shall be implicitly convertible to
+<tt>CR(Rep1, Rep2)</tt> and <tt>Rep2</tt> shall not be an instantiation of
+<tt>duration</tt><ins>, else this signature shall not participate in
+overload resolution</ins>. <del>Diagnostic required.</del>
+</blockquote>
 
+<pre>template &lt;class Rep1, class Period, class Rep2&gt; 
+  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt; 
+  operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
+</pre>
+<blockquote>
+<i><del>Requires</del> <ins>Remarks</ins>:</i> <tt>Rep2</tt> shall be implicitly convertible to
+<tt>CR(Rep1, Rep2)</tt> and <tt>Rep2</tt> shall not be an instantiation of
+<tt>duration</tt><ins>, else this signature shall not participate in
+overload resolution</ins>. <del>Diagnostic required.</del>
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
-<p>
-In 30.6.7 [futures.task], immediately after the definition of class
-template packaged_task add:
-</p>
-<blockquote><pre><ins>
-template&lt;class R, class... Argtypes&gt;
-void swap(packaged_task&lt;R(ArgTypes...)&gt;&amp;, packaged_task&lt;R(ArgTypes...)&gt;&amp;);
-</ins>
-</pre></blockquote>
+</blockquote>
 </li>
-</ol>
 
-<ol start="3">
 <li>
 <p>
-In 30.6.7 [futures.task], immediately after <tt>operator=</tt> prototype
-description (After p. 8) add:
+Change the following paragraphs in 20.9.3.7 [time.duration.cast]:
 </p>
-<blockquote><pre><ins>void swap(packaged_task&amp; other);</ins>
+
+<blockquote><pre>template &lt;class ToDuration, class Rep, class Period&gt; 
+  ToDuration duration_cast(const duration&lt;Rep, Period&gt;&amp; d);
 </pre>
+
 <blockquote>
-<p><ins>
-<i>Effects:</i> Swaps the associated state of <tt>*this</tt> and <tt>other</tt>.
-</ins></p>
-<p><ins>
-<i>Throws:</i> Nothing.
-</ins></p>
+<i><del>Requires</del> <ins>Remarks</ins>:</i> <tt>ToDuration</tt> shall be an instantiation of
+<tt>duration</tt><ins>, else this signature shall not participate in
+overload resolution</ins>. <del>Diagnostic required.</del>
 </blockquote>
 </blockquote>
 </li>
+
 <li>
 <p>
-At the end of 30.6.7 [futures.task] (after p. 20), add add the following
-prototype description:
+Change the following paragraphs in 20.9.4.7 [time.point.cast]:
 </p>
 
-<blockquote><pre><ins>
-template&lt;class R, class... Argtypes&gt;
-void swap(packaged_task&lt;R(ArgTypes...)&gt;&amp; x, packaged_task&lt;R(ArgTypes...)&gt;&amp; y);
-</ins></pre>
+<blockquote><pre>template &lt;class ToDuration, class Clock, class Duration&gt; 
+  time_point&lt;Clock, ToDuration&gt; time_point_cast(const time_point&lt;Clock, Duration&gt;&amp; t);
+</pre>
+
 <blockquote>
-<p><ins>
-<i>Effects:</i> <tt>x.swap(y)</tt>
-</ins></p>
-<p><ins>
-<i>Throws:</i> Nothing.
-</ins></p>
+<i><del>Requires</del> <ins>Remarks</ins>:</i> <tt>ToDuration</tt> shall be an instantiation of
+<tt>duration</tt><ins>, else this signature shall not participate in
+overload resolution</ins>. <del>Diagnostic required.</del>
 </blockquote>
 </blockquote>
 </li>
@@ -26104,2009 +21343,2483 @@ void swap(packaged_task&lt;R(ArgTypes...)&gt;&amp; x, packaged_task&lt;R(ArgType
 
 
 
+
 <hr>
-<h3><a name="1091"></a>1091. Multimap description confusing</h3>
-<p><b>Section:</b> 23.4.2.2 [multimap.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-07-04</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="1180"></a>1180. Missing string_type member typedef in class <tt>sub_match</tt></h3>
+<p><b>Section:</b> 28.9.1 [re.submatch.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-07-25  <b>Last modified:</b> 2009-07-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 246</b></p>
 <p>
-The content of this sub-clause is purely trying to describe in words the
-effect of the requires clauses on these operations, now that we have
-Concepts. As such, the description is more confusing than the signature
-itself. The semantic for these functions is adequately covered in the
-requirements tables in 23.2.4 [associative.reqmts].
+The definition of class template <tt>sub_match</tt> is strongly dependent
+on the type <tt>basic_string&lt;value_type&gt;</tt>, both in interface and effects,
+but does not provide a corresponding typedef <tt>string_type</tt>, as e.g.
+class <tt>match_results</tt> does, which looks like an oversight to me that
+should be fixed.
 </p>
 
-<p><i>[
-Beman adds:
-]</i></p>
 
+<p><b>Proposed resolution:</b></p>
 
-<blockquote>
-Pete is clearly right that
-this one is technical rather than editorial.
-</blockquote>
+<ol>
+<li>
+<p>
+In the class template <tt>sub_match</tt> synopsis 28.9 [re.submatch]/1
+change as indicated:
+</p>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<blockquote><pre>template &lt;class BidirectionalIterator&gt;
+class sub_match : public std::pair&lt;BidirectionalIterator, BidirectionalIterator&gt; {
+public:
+  typedef typename iterator_traits&lt;BidirectionalIterator&gt;::value_type value_type;
+  typedef typename iterator_traits&lt;BidirectionalIterator&gt;::difference_type difference_type;
+  typedef BidirectionalIterator iterator;
+  <ins>typedef basic_string&lt;value_type&gt; string_type;</ins>
 
-<blockquote>
+  bool matched;
+
+  difference_type length() const;
+  operator <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>() const;
+  <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins> str() const;
+  int compare(const sub_match&amp; s) const;
+  int compare(const <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>&amp; s) const;
+  int compare(const value_type* s) const;
+};
+</pre></blockquote>
+</li>
+
+<li>
 <p>
-We agree with the proposed resolution.
+In 28.9.1 [re.submatch.members]/2 change as indicated:
 </p>
+
+<blockquote><pre>operator <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>() const;
+</pre>
+
+<blockquote>
+<i>Returns:</i> <tt>matched ? <del>basic_string&lt;value_type&gt;</del>
+<ins>string_type</ins>(first, second) : <del>basic_string&lt;value_type&gt;</del>
+<ins>string_type</ins>()</tt>.
+</blockquote>
+</blockquote>
+</li>
+
+<li>
 <p>
-Move to Review.
+In 28.9.1 [re.submatch.members]/3 change as indicated:
 </p>
-</blockquote>
 
+<blockquote><pre><del>basic_string&lt;value_type&gt;</del><ins>string_type</ins> str() const;
+</pre>
+
+<blockquote>
+<i>Returns:</i> <tt>matched ? <del>basic_string&lt;value_type&gt;</del>
+<ins>string_type</ins>(first, second) : <del>basic_string&lt;value_type&gt;</del>
+<ins>string_type</ins>()</tt>.
+</blockquote>
+</blockquote>
+</li>
+</ol>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Strike 23.4.2.2 [multimap.modifiers] entirely
-(but do NOT strike these signatures from the class template definition!).
-</p>
 
 
 
 
 
 <hr>
-<h3><a name="1093"></a>1093. Multiple definitions for random_shuffle algorithm</h3>
-<p><b>Section:</b> 25.4.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-07-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.random.shuffle">issues</a> in [alg.random.shuffle].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-07-25  <b>Last modified:</b> 2009-07-28</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.submatch.op">issues</a> in [re.submatch.op].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-
 <p>
-There are a couple of issues with the declaration of the <tt>random_shuffle</tt>
-algorithm accepting a random number engine.
+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>
 
-<ol type="i">
-<li>
-The Iterators must be shuffle iterators, yet this requirement is missing.
-</li>
-<li>
-The <tt>RandomNumberEngine</tt> concept is now provided by the random number
-library
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">n2836</a>)
-and the placeholder should be removed.
-</li>
-</ol>
-
-<p><i>[
-2009-05-02 Daniel adds:
-]</i></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>
-this issue completes adding necessary requirement to the
-third new <tt>random_shuffle</tt> overload. The current suggestion is:
+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>template&lt;RandomAccessIterator Iter, UniformRandomNumberGenerator Rand&gt;
-requires ShuffleIterator&lt;Iter&gt;
-void random_shuffle(Iter first, Iter last, Rand&amp;&amp; g);
+<blockquote><pre>std::char_traits&lt;iterator_traits&lt;BiIter&gt;::value_type&gt;
 </pre></blockquote>
 
 <p>
-IMO this is still insufficient and I suggest to add the requirement
+which is essentially identical to
 </p>
-<blockquote><pre>Convertible&lt;Rand::result_type, Iter::difference_type&gt;
+
+<blockquote><pre>std::char_traits&lt;sub_match&lt;BiIter&gt;::value_type&gt;
 </pre></blockquote>
-<p>
-to the list (as the two other overloads already have).
-</p>
 
 <p>
-Rationale:
+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>
 
-<blockquote>
-<p>
-Its true that this third overload is somewhat different from the remaining
-two. Nevertheless we know from <tt>UniformRandomNumberGenerator</tt>, that
-it's <tt>result_type</tt> is an integral type and that it satisfies
-<tt>UnsignedIntegralLike&lt;result_type&gt;</tt>.
-</p>
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
 <p>
-To realize it's designated task, the algorithm has to invoke the
-<tt>Callable</tt> aspect of <tt>g</tt> and needs to perform some algebra involving
-it's <tt>min()/max()</tt> limits to compute another index value that
-at this point is converted into <tt>Iter::difference_type</tt>. This is so,
-because 24.2.6 [random.access.iterators] uses this type as argument
-of it's algebraic operators. Alternatively consider the equivalent
-iterator algorithms in 24.4 [iterator.operations] with the same result.
+In 28.9.2 [re.submatch.op] change as indicated:
 </p>
+
+<ol type="a">
+<li>
+
 <p>
-This argument leads us to the conclusion that we also need
-<tt>Convertible&lt;Rand::result_type, Iter::difference_type&gt;</tt> here.
+If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1180">1180</a> is accepted:
 </p>
-</blockquote>
 
+<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>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<pre>template &lt;class BiIter, class ST, class SA&gt;
+  bool operator!=(
+    const basic_string&lt;
+      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
+    const sub_match&lt;BiIter&gt;&amp; rhs);
+</pre>
 
 <blockquote>
-<p>
-Alisdair notes that point (ii) has already been addressed.
-</p>
-<p>
-We agree with the proposed resolution to point (i)
-with Daniel's added requirement.
-</p>
-<p>
-Move to Review.
-</p>
+8 <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>
 
-<p><i>[
-2009-06-05 Daniel updated proposed wording as recommended in Batavia.
-]</i></p>
-
+<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>
 
-<p><i>[
-2009-07-28 Alisdair adds:
-]</i></p>
+<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>
-Revert to Open, with a note there is consensus on direction but the
-wording needs updating to reflect removal of concepts.
+10 <i>Returns:</i> <tt><del>lhs</del><ins>typename
+sub_match&lt;BiIter&gt;::string_type(lhs.begin(), lhs.end())</ins> &gt;
+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>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Change in 25.2 [algorithms.syn] and 25.4.12 [alg.random.shuffle]:
-</p>
-
-<blockquote><pre><del>concept UniformRandomNumberGenerator&lt;typename Rand&gt; { }</del>
-template&lt;RandomAccessIterator Iter, UniformRandomNumberGenerator Rand&gt;
-  <ins>requires ShuffleIterator&lt;Iter&gt; &amp;&amp;
-  Convertible&lt;Rand::result_type, Iter::difference_type&gt;</ins>
-  void random_shuffle(Iter first, Iter last, Rand&amp;&amp; g);
-</pre></blockquote>
+<blockquote>
+11 <i>Returns:</i> <tt><del>lhs</del><ins>typename
+sub_match&lt;BiIter&gt;::string_type(lhs.begin(), lhs.end())</ins> &gt;=
+rhs.str()</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><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==(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>
 
-<hr>
-<h3><a name="1094"></a>1094. Response to JP 65 and JP 66</h3>
-<p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-24  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p><b>Addresses JP 65 and JP 66</b></p>
+<blockquote>
+14 <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>
 
-<p>
-Switch from "unspecified-bool-type" to "explicit operator bool() const". 
-</p>
+<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>
 
-<p>
-Replace <tt>operator unspecified-bool-type() const;</tt>" with <tt>explicit operator bool() const;</tt>
-</p>
+<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>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<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>
-We agree with the proposed resolution.
-Move to Review.
+16 <i>Returns:</i> <tt>lhs.str() &gt; <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>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopis in 27.5.4 [ios]:
-</p>
-
-<blockquote><pre><ins>explicit</ins> operator <del><i>unspecified-bool-type</i></del> <ins>bool</ins>() const;
-</pre></blockquote>
-
-<p>
-Change 27.5.4.3 [iostate.flags]:
-</p>
+<blockquote>
+17 <i>Returns:</i> <tt>lhs.str() &gt;= <del>rhs</del><ins>typename
+sub_match&lt;BiIter&gt;::string_type(rhs.begin(), rhs.end())</ins></tt>.
+</blockquote>
 
-<blockquote><pre><ins>explicit</ins> operator <del><i>unspecified-bool-type</i></del> <ins>bool</ins>() const;
+<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>
-<p>
--1- <i>Returns:</i> <ins><tt>!fail()</tt></ins> <del>If <tt>fail()</tt> then a value that will evaluate
-false in a boolean context; otherwise a value that will evaluate true in
-a boolean context. The value type returned shall not be convertible to
-int.</del>
-</p>
-<p>
-<del>[<i>Note:</i> This conversion can be used in contexts where a bool is expected
-(e.g., an <tt>if</tt> condition); however, implicit conversions (e.g.,
-to <tt>int</tt>) that can occur with <tt>bool</tt> are not allowed,
-eliminating some sources of user error. One possible implementation
-choice for this type is pointer-to-member. <i>-- end note</i>]</del>
-</p>
+18 <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>
 </blockquote>
 
+</li>
 
+<li>
 
-
-
-
-
-<hr>
-<h3><a name="1095"></a>1095. <i>Shared objects and the library</i> wording unclear</h3>
-<p><b>Section:</b> 17.6.3.10 [res.on.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-03-27  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2775.htm">N2775</a>,
-<i>Small library thread-safety revisions</i>, among other changes, removed a note from
-17.6.3.10 [res.on.objects] that read:
+If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1180">1180</a> is <em>not</em> accepted:
 </p>
 
 <blockquote>
-[<i>Note:</i> This prohibition against concurrent non-const access means that
-modifying an object of a standard library type shared between threads
-without using a locking mechanism may result in a data race. <i>--end note</i>.]
+<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>basic_string&lt;typename
+sub_match&lt;BiIter&gt;::value_type&gt;(lhs.begin(), lhs.end())</ins> ==
+rhs.str()</tt>.
 </blockquote>
 
-<p>
-That resulted in wording which is technically correct but can only be
-understood by reading the lengthy and complex 17.6.4.7 [res.on.data.races]
-Data race avoidance. This has the effect of making
-17.6.3.10 [res.on.objects] unclear, and has already resulted in a query
-to the LWG reflector. See c++std-lib-23194.
-</p>
-
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<pre>template &lt;class BiIter, class ST, class SA&gt;
+  bool operator!=(
+    const basic_string&lt;
+      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
+    const sub_match&lt;BiIter&gt;&amp; rhs);
+</pre>
 
 <blockquote>
-<p>
-The proposed wording seems to need a bit of tweaking
-("really bad idea" isn't quite up to standardese).
-We would like feedback
-as to whether the original Note's removal was intentional.
-</p>
-<p>
-Change the phrase "is a really bad idea"
-to "risks undefined behavior" and
-move to Review status.
-</p>
+8 <i>Returns:</i> <tt><del>lhs</del><ins>basic_string&lt;typename
+sub_match&lt;BiIter&gt;::value_type&gt;(lhs.begin(), lhs.end())</ins> !=
+rhs.str()</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>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 17.6.3.10 [res.on.objects] as indicated:
-</p>
+<blockquote>
+9 <i>Returns:</i> <tt><del>lhs</del><ins>basic_string&lt;typename
+sub_match&lt;BiIter&gt;::value_type&gt;(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>
-<p>
-The behavior of a program is undefined if calls to standard library
-functions from different threads may introduce a data race. The
-conditions under which this may occur are specified in 17.6.4.7.
-</p>
-<p><ins>
-[<i>Note:</i> Thus modifying an object of a standard library type shared between
-threads risks undefined behavior unless objects of the type are explicitly
-specified as being sharable without data races or the user supplies a
-locking mechanism. <i>--end note</i>]
-</ins></p>
+10 <i>Returns:</i> <tt><del>lhs</del><ins>basic_string&lt;typename
+sub_match&lt;BiIter&gt;::value_type&gt;(lhs.begin(), lhs.end())</ins> &gt;
+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>
+11 <i>Returns:</i> <tt><del>lhs</del><ins>basic_string&lt;typename
+sub_match&lt;BiIter&gt;::value_type&gt;(lhs.begin(), lhs.end())</ins> &gt;=
+rhs.str()</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><del>lhs</del><ins>basic_string&lt;typename
+sub_match&lt;BiIter&gt;::value_type&gt;(lhs.begin(), lhs.end())</ins> &lt;=
+rhs.str()</tt>.
+</blockquote>
 
-<hr>
-<h3><a name="1097"></a>1097. #define __STDCPP_THREADS</h3>
-<p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-04-03  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p><b>Addresses DE 18</b></p>
+<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>
 
-<p>
-Freestanding implementations do not (necessarily) have
-  support for multiple threads (see 1.10 [intro.multithread]).
-  Applications and libraries may want to optimize for the
-  absence of threads.  I therefore propose a preprocessor
-  macro to indicate whether multiple threads can occur.
-</p>
+<blockquote>
+13 <i>Returns:</i> <tt>lhs.str() == <del>rhs</del><ins>basic_string&lt;typename
+sub_match&lt;BiIter&gt;::value_type&gt;(rhs.begin(), rhs.end())</ins></tt>.
+</blockquote>
 
-<p>
-There is ample prior implementation experience for this
-  feature with various spellings of the macro name.  For
-  example, gcc implicitly defines <tt>_REENTRANT</tt>
-  if multi-threading support is selected on the compiler
-  command-line.
-</p>
+<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>
 
-<p>
-While this is submitted as a library issue, it may be more
-  appropriate to add the macro in 16.8 cpp.predefined in the
-  core language.
-</p>
+<blockquote>
+14 <i>Returns:</i> <tt>lhs.str() != <del>rhs</del><ins>basic_string&lt;typename
+sub_match&lt;BiIter&gt;::value_type&gt;(rhs.begin(), rhs.end())</ins></tt>.
+</blockquote>
 
-<p>
-See also
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html">N2693</a>.
-</p>
+<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>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<blockquote>
+15 <i>Returns:</i> <tt>lhs.str() &lt; <del>rhs</del><ins>basic_string&lt;typename
+sub_match&lt;BiIter&gt;::value_type&gt;(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>
-<p>
-We agree with the issue, and believe it is properly a library issue.
-</p>
-<p>
-We prefer that the macro be conditionally defined
-as part of the <tt>&lt;thread&gt;</tt> header.
-</p>
-<p>
-Move to Review.
-</p>
+16 <i>Returns:</i> <tt>lhs.str() &gt; <del>rhs</del><ins>basic_string&lt;typename
+sub_match&lt;BiIter&gt;::value_type&gt;(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>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Insert a new subsection before 18.2 [support.types], entitled
-"Feature Macros" (support.macros):
-</p>
 <blockquote>
-<p>
-The standard library defines the following macros; no explicit
-prior inclusion of any header file is necessary.
-</p>
+17 <i>Returns:</i> <tt>lhs.str() &gt;= <del>rhs</del><ins>basic_string&lt;typename
+sub_match&lt;BiIter&gt;::value_type&gt;(rhs.begin(), rhs.end())</ins></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>
-<dl>
-<dt><tt>__STDCPP_THREADS</tt></dt>
-<dd>
-The macro <tt>__STDCPP_THREADS</tt> shall be defined if and only if a
-    program can have more than one thread of execution (1.10 [intro.multithread]).
-If the macro is defined, it shall have the same
-    value as the predefined macro <tt>__cplusplus</tt> (16.8 [cpp.predefined]).
-</dd>
-</dl>
+18 <i>Returns:</i> <tt>lhs.str() &lt;= <del>rhs</del><ins>basic_string&lt;typename
+sub_match&lt;BiIter&gt;::value_type&gt;(rhs.begin(), rhs.end())</ins></tt>.
 </blockquote>
 </blockquote>
 
+</li>
+
+</ol>
+
+</li>
+</ol>
 
 
 
 
 
 <hr>
-<h3><a name="1098"></a>1098. definition of get_pointer_safety()</h3>
-<p><b>Section:</b> 20.8.10.7 [util.dynamic.safety] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-04-03  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.dynamic.safety">issues</a> in [util.dynamic.safety].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1182"></a>1182. Unfortunate hash dependencies</h3>
+<p><b>Section:</b> 20.7.16 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-28  <b>Last modified:</b> 2009-09-21</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-<p><b>Addresses DE 18</b></p>
-
 <p>
- In 20.8.10.7 [util.dynamic.safety], <tt>get_pointer_safety()</tt> purports
-to define behavior for
- non-safely derived pointers (3.7.4.3 [basic.stc.dynamic.safety]).  However,
- the cited core-language section in paragraph 4 specifies undefined behavior
- for the use of such pointer values.  This seems an unfortunate near-contradiction.
- I suggest to specify the term <i>relaxed pointer safety</i> in
- the core language section and refer to it from the library description.
- This issue deals with the library part, the corresponding core issue (c++std-core-13940)
- deals with the core modifications.
+The implied library dependencies created by spelling out all the <tt>hash</tt>
+template specializations in the <tt>&lt;functional&gt;</tt> synopsis are unfortunate. 
+The potential coupling is greatly reduced if the <tt>hash</tt> specialization is
+declared in the appropriate header for each library type, as it is much
+simpler to forward declare the primary template and provide a single
+specialization than it is to implement a <tt>hash</tt> function for a <tt>string</tt> or
+<tt>vector</tt> without providing a definition for the whole <tt>string/vector</tt>
+template in order to access the necessary bits.
 </p>
 
 <p>
-See also
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html">N2693</a>.
+Note that the proposed resolution purely involves moving the
+declarations of a few specializations, it specifically does not make any
+changes to 20.7.16 [unord.hash].
 </p>
 
 <p><i>[
-Batavia (2009-05):
+2009-09-15 Daniel adds:
 ]</i></p>
 
+
 <blockquote>
+</blockquote>
 <p>
-We recommend if this issue is to be moved,
-the issue be moved concurrently with the cited Core issue.
-</p>
-<p>
-We agree with the intent of the proposed resolution.
-We would like input from garbage collection specialists.
+I suggest to add to the current existing
+proposed resolution the following items.
 </p>
+
+<ul>
+<li>
 <p>
-Move to Open.
+Add to the very first strike-list of the currently suggested resolution
+the following lines:
 </p>
-</blockquote>
-
 
+<blockquote><pre><del>template &lt;&gt; struct hash&lt;std::error_code&gt;;</del>
+<del>template &lt;&gt; struct hash&lt;std::thread::id&gt;;</del>
+</pre></blockquote>
+</li>
 
-<p><b>Proposed resolution:</b></p>
+<li>
 <p>
-In 20.8.10.7 [util.dynamic.safety] p16, replace the description of
-<tt>get_pointer_safety()</tt> with:
+Add the following declarations to 19.5 [syserr], header
+<tt>&lt;system_error&gt;</tt> synopsis after // 19.5.4:
 </p>
 
-<blockquote>
-<p>
-<tt>pointer_safety get_pointer_safety();</tt>
-</p>
-<blockquote>
+<blockquote><pre><ins>
+// 19.5.x hash support
+template &lt;class T&gt; struct hash;
+template &lt;&gt; struct hash&lt;error_code&gt;;
+</ins>
+</pre></blockquote>
+</li>
+
+<li>
 <p>
-<del><i>Returns:</i> an enumeration value indicating the implementation's treatment
-of pointers that are not safely derived (3.7.4.3). Returns
-<tt>pointer_safety::relaxed</tt> if pointers that are not safely derived will be
-treated the same as pointers that are safely derived for the duration of
-the program. Returns <tt>pointer_safety::preferred</tt> if pointers that are not
-safely derived will be treated the same as pointers that are safely
-derived for the duration of the program but allows the implementation to
-hint that it could be desirable to avoid dereferencing pointers that are
-not safely derived as described. [<i>Example:</i> <tt>pointer_safety::preferred</tt>
-might be returned to detect if a leak detector is running to avoid
-spurious leak reports. -- <i>end note</i>] Returns <tt>pointer_safety::strict</tt> if
-pointers that are not safely derived might be treated differently than
-pointers that are safely derived.</del>
+Add a new clause 19.5.X (probably after 19.5.4):
 </p>
-<p><ins>
-<i>Returns:</i> Returns <tt>pointer_safety::strict</tt> if the implementation has
-   strict pointer safety (3.7.4.3 [basic.stc.dynamic.safety]). It is
-   implementation-defined whether <tt>get_pointer_safety</tt> returns
-   <tt>pointer_safety::relaxed</tt> or <tt>pointer_safety::preferred</tt> if the
-   implementation has relaxed pointer safety
-   (3.7.4.3 [basic.stc.dynamic.safety]).<sup>Footnote</sup>
-</ins></p>
 
+<blockquote>
 <p><ins>
-<i>Throws:</i> nothing
+19.5.X Hash support [syserr.hash]
 </ins></p>
 
-<p><ins>
-Footnote) <tt>pointer_safety::preferred</tt> might be returned to indicate to the
-   program that a leak detector is running so that the program can avoid
-   spurious leak reports.
-</ins>
-</p>
+<pre><ins>
+template &lt;&gt; struct hash&lt;error_code&gt;;
+</ins></pre>
 
+<blockquote><ins>
+An explicit specialization of the class template hash (20.7.16 [unord.hash])
+shall be provided
+for the type <tt>error_code</tt> suitable for using this type as key in
+unordered associative
+containers (23.5 [unord]).
+</ins></blockquote>
 </blockquote>
-</blockquote>
-
-
-
-
+</li>
 
-<hr>
-<h3><a name="1099"></a>1099. Various issues</h3>
-<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-21  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Notes
-</p>
-<blockquote>
+<li>
 <p>
-[2009-03-21 Sat] p. 535 at the top we need MoveConstructible V1,
-MoveConstructible V2 (where V1,V2 are defined on 539).  Also make_tuple
-on 550
+Add the following declarations to 30.3.1.1 [thread.thread.id] just after the
+declaration of
+the comparison operators:
 </p>
+
+<blockquote><pre><ins>
+template &lt;class T&gt; struct hash;
+template &lt;&gt; struct hash&lt;thread::id&gt;;
+</ins></pre></blockquote>
+</li>
+
+<li>
 <p>
-[2009-03-21 Sat] p1183 thread ctor, and in general, we need a way to
-talk about "copiable from generalized rvalue ref argument" for cases
-where we're going to forward and copy.  
+Add a new paragraph at the end of 30.3.1.1 [thread.thread.id]:
 </p>
+
 <blockquote>
-<p>
-   This issue may well be quite large.  Language in para 4 about "if
-   an lvalue" is wrong because types aren't expressions.
-</p>
-<p>
-   p1199, call_once has all the same issues.
-</p>
-</blockquote>
-<p>
-[2009-03-21 Sat] p869 InputIterator pointer type should not be required
-to be convertible to const value_type*, rather it needs to have a
-operator-&gt; of its own that can be used for the value type.
-</p>
-<p>
-[2009-03-21 Sat] p818 stack has the same problem with default ctor.
-</p>
-<p>
-[2009-03-21 Sat] p816 priority_queue has the same sorts of problems as queue, only more so
-</p>
-<blockquote><pre>   requires MoveConstructible&lt;Cont&gt; 
-     explicit priority_queue(const Compare&amp; x = Compare(), Cont&amp;&amp; = Cont()); 
-</pre>
-<p>
-   Don't require MoveConstructible when default constructing Cont.
-   Also missing semantics for move ctor.
-</p>
+<pre><ins>
+template &lt;&gt; struct hash&lt;thread::id&gt;;
+</ins></pre>
+
+<blockquote><ins>
+An explicit specialization of the class template hash (20.7.16 [unord.hash])
+shall be provided
+for the type <tt>thread::id</tt> suitable for using this type as key in
+unordered associative
+containers (23.5 [unord]).
+</ins></blockquote>
 </blockquote>
-<p>
- [2009-03-21 Sat] Why are Allocators required to be CopyConstructible as
- opposed to MoveConstructible?
-</p>
-<p>
- [2009-03-21 Sat] p813 queue needs a separate default ctor (Cont needn't
- be MoveConstructible).  No documented semantics for move c'tor.  Or
- *any* of its 7 ctors!
-</p>
-<p>
- [2009-03-21 Sat] std::array should have constructors for C++0x,
- consequently must consider move construction.
-</p>
+</li>
 
-<p><i>[
-2009-05-01 Daniel adds:
-]</i></p>
+<li>
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#889">889</a> independently suggests moving the specialization
+<tt>std::hash&lt;std::thread::id&gt;</tt> to header <tt>&lt;thread&gt;</tt>.
+</li>
+</ul>
 
 
-<blockquote>
-This could be done as part of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1035">1035</a>, which already handles
-deviation of <tt>std::array</tt> from container tables.
-</blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
- [2009-03-21 Sat] p622 all messed up.
-</p>
-<blockquote>
-<p>
-   para 8 "implementation-defined" is the wrong term; should be "see
-   below" or something.  
-</p>
-<p>
-   para 12 "will be selected" doesn't make any sense because we're not
-   talking about actual arg types.
-</p>
-<p>
-   paras 9-13 need to be totally rewritten for concepts.
+Strike the following specializations declared in the <tt>&lt;functional&gt;</tt>
+synopsis p2 20.7 [function.objects]
 </p>
-</blockquote>
+
+<blockquote><pre><del>template &lt;&gt; struct hash&lt;std::string&gt;;</del>
+<del>template &lt;&gt; struct hash&lt;std::u16string&gt;;</del>
+<del>template &lt;&gt; struct hash&lt;std::u32string&gt;;</del>
+<del>template &lt;&gt; struct hash&lt;std::wstring&gt;;</del>
+
+<del>template &lt;class Allocator&gt; struct hash&lt;std::vector&lt;bool, Allocator&gt; &gt;;</del>
+<del>template &lt;std::size_t N&gt; struct hash&lt;std::bitset&lt;N&gt; &gt;;</del>
+</pre></blockquote>
 
 <p>
- [2009-03-21 Sat] Null pointer comparisons (p587) have all become
- unconstrained.  Need to fix that
-</p>
-<p>
- [2009-03-21 Sat] mem_fun_t etc. definition doesn't match declaration.
-  We think CopyConstructible is the right reqt.
-</p>
-<p>
- make_pair needs Constructible&lt;V1, T1&amp;&amp;&gt; requirements!
-</p>
-<p>
- make_tuple needs something similar
-</p>
-<p>
- tuple bug in synopsis:
+Add the following declarations to the synopsis of <tt>&lt;string&gt;</tt> in
+21.3 [string.classes]
 </p>
-<blockquote><pre>   template &lt;class... UTypes&gt;
-   requires Constructible&lt;Types, const UTypes&amp;&gt;...
-   template &lt;class... UTypes&gt;
-   requires Constructible&lt;Types, RvalueOf&lt;UTypes&gt;::type&gt;...
-</pre>
+
+<blockquote><pre><ins>// 21.4.x hash support
+template &lt;class T&gt; struct hash;
+template &lt;&gt; struct hash&lt;string&gt;;
+template &lt;&gt; struct hash&lt;u16string&gt;;
+template &lt;&gt; struct hash&lt;u32string&gt;;
+template &lt;&gt; struct hash&lt;wstring&gt;;</ins>
+</pre></blockquote>
+
 <p>
-   Note: removal of MoveConstructible requirements in std::function makes
-   these routines unconstrained!
+Add a new clause 21.4.X
 </p>
-</blockquote>
 
-<p><i>[
-2009-05-02 Daniel adds:
-]</i></p>
+<blockquote>
+<p>
+21.4.X Hash support [basic.string.hash]
+</p>
 
+<pre>template &lt;&gt; struct hash&lt;string&gt;;
+template &lt;&gt; struct hash&lt;u16string&gt;;
+template &lt;&gt; struct hash&lt;u32string&gt;;
+template &lt;&gt; struct hash&lt;wstring&gt;;
+</pre>
 
 <blockquote>
-This part of the issue is already covered by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>.
+Explicit specializations of the class template hash (20.7.16 [unord.hash])
+shall be provided for the types <tt>string</tt>, <tt>u16string</tt>,
+<tt>u32string</tt> and <tt>wstring</tt> suitable for using these types as keys in
+unordered associative containers (23.5 [unord]).
+</blockquote>
 </blockquote>
 
 <p>
- these unique_ptr constructors are broken [ I think this is covered in "p622 all messed up" ]
+Add the following declarations to the synopsis of <tt>&lt;vector&gt;</tt> in 
+23.3 [sequences]
 </p>
-<blockquote><pre> unique_ptr(pointer p, implementation-defined d);
- unique_ptr(pointer p, implementation-defined d);
-</pre></blockquote>
+
+<blockquote><pre><ins>
+// 21.4.x hash support
+template &lt;class T&gt; struct hash;
+template &lt;class Allocator&gt; struct hash&lt;vector&lt;bool, Allocator&gt;&gt;;
+</ins></pre></blockquote>
+
 <p>
- multimap range constructor should not have MoveConstructible&lt;value_type&gt; requirement.
+Add a new paragraph to the end of 23.3.7 [vector.bool]
 </p>
+
+<blockquote><pre>template &lt;class Allocator&gt; struct hash&lt;vector&lt;bool, Allocator&gt;&gt;;
+</pre>
 <blockquote>
-   same with insert(..., P&amp;&amp;); multiset has the same issue, as do
-   unordered_multiset and unordered_multimap. Review these!
+A partial specialization of the class template hash (20.7.16 [unord.hash])
+shall be provided for vectors of boolean values suitable for use as a key
+in unordered associative containers (23.5 [unord]).
 </blockquote>
-
 </blockquote>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
+<p>
+Add the following declarations to the synopsis of <tt>&lt;bitset&gt;</tt>
+in 20.3.7 [template.bitset]
+</p>
 
-<blockquote>
-Move to Open, pending proposed wording from Dave for further review.
-</blockquote>
+<blockquote><pre><ins>
+// 20.3.6.X hash support
+template &lt;class T&gt; struct hash;
+template &lt;size_t N&gt; struct hash&lt;bitset&lt;N&gt; &gt;;
+</ins></pre></blockquote>
 
+<p>
+Add a new subclause 20.3.6.X [bitset.hash]
+</p>
 
-<p><b>Proposed resolution:</b></p>
+<blockquote>
 <p>
+20.3.6.X bitset hash support [bitset.hash]
 </p>
 
+<pre>template &lt;size_t N&gt; struct hash&lt;bitset&lt;N&gt; &gt;;
+</pre>
+
+<blockquote>
+A partial specialization of the class template hash
+(20.7.16 [unord.hash]) shall be provided for bitsets suitable for use as a key in
+unordered associative containers (23.5 [unord]).
+</blockquote>
+</blockquote>
+
+
 
 
 
 
 <hr>
-<h3><a name="1100"></a>1100. <tt>auto_ptr</tt> to <tt>unique_ptr</tt> conversion</h3>
-<p><b>Section:</b> 20.8.9.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25  <b>Last modified:</b> 2009-08-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.ctor">active issues</a> in [unique.ptr.single.ctor].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-07-28  <b>Last modified:</b> 2009-10-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Message c++std-lib-23182 led to a discussion in which several people
-expressed interest in being able to convert an <tt>auto_ptr</tt> to a
-<tt>unique_ptr</tt> without the need to call <tt>release</tt>.  Below is
-wording to accomplish this.
+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>
 
-<p><i>[
-Batavia (2009-05):
-]</i></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>
-Pete believes it not a good idea to separate parts of a class's definition.
-Therefore, if we do this,
-it should be part of <tt>unique-ptr</tt>'s specification.
+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>
-Alisdair believes the lvalue overload may be not necessary.
+or by calling
 </p>
+
+<blockquote><pre>basic_streambuf&lt;charT,traits&gt;* rdbuf(basic_streambuf&lt;charT,traits&gt;* sb);
+</pre></blockquote>
+
 <p>
-Marc believes it is more than just sugar,
-as it does ease the transition to <tt>unique-ptr</tt>.
+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>
-We agree with the resolution as presented.
-Move to Tentatively Ready.
+I therefore suggest that a requirement is added for callers of <tt>set_rdbuf</tt> to
+set a non-0 value.
 </p>
-</blockquote>
 
 <p><i>[
-2009-07 Frankfurt
+2009-10 Santa Cruz:
 ]</i></p>
 
 
 <blockquote>
-Moved from Tentatively Ready to Open only because the wording needs to be
-tweaked for concepts removal.
+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-08-01 Howard deconceptifies wording:
+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>
-I also moved the change from D.9 [depr.auto.ptr]
-to 20.8.9.2 [unique.ptr.single] per the Editor's request
-in Batavia (as long as I was making changes anyway).  Set back
-to Review.
-</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><b>Proposed resolution:</b></p>
 <p>
-Add to 20.8.9.2 [unique.ptr.single]:
+<i>Throws:</i> Nothing.
 </p>
 
-<blockquote><pre>template &lt;class T, class D&gt;
-class unique_ptr
-{
-public:
-<ins>    template &lt;class U&gt;
-      unique_ptr(auto_ptr&lt;U&gt;&amp; u);
-    template &lt;class U&gt;
-      unique_ptr(auto_ptr&lt;U&gt;&amp;&amp; u);</ins>
-};
-</pre></blockquote>
+</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="1185"></a>1185. iterator categories and output iterators</h3>
+<p><b>Section:</b> 24.2 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-31  <b>Last modified:</b> 2009-07-31</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Add to 20.8.9.2.1 [unique.ptr.single.ctor]:
+(wording relative to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
+pending new working paper)
 </p>
 
-<blockquote><pre>template &lt;class U&gt;
-  unique_ptr(auto_ptr&lt;U&gt;&amp; u);
-template &lt;class U&gt;
-  unique_ptr(auto_ptr&lt;U&gt;&amp;&amp; u);
-</pre>
-<blockquote>
 <p>
-<i>Effects:</i> Constructs a <tt>unique_ptr</tt> with <tt>u.release()</tt>.
+According to p3 24.2 [iterator.requirements], Forward iterators,
+Bidirectional iterators and Random Access iterators all satisfy the
+requirements for an Output iterator:
 </p>
 
+<blockquote>
+XXX iterators satisfy all the requirements of the input and output iterators
+and can be used whenever either kind is specified ...
+</blockquote>
+
 <p>
-<i>Postconditions:</i> <tt>get() == </tt> the value <tt>u.get()</tt> had before
-the construciton, modulo any required offset adjustments resulting from the cast from
-<tt>U*</tt> to <tt>T*</tt>.  <tt>u.get() == nullptr</tt>.
+Meanwhile, p4 goes on to contradict this:
 </p>
 
+<blockquote>
+Besides its category, a forward, bidirectional, or random access
+iterator can also be mutable or constant...
+</blockquote>
+
+<blockquote>
+... Constant iterators do not satisfy the requirements for output iterators
+</blockquote>
+
 <p>
-<i>Throws:</i> nothing.
+The latter seems to be the overriding concern, as the iterator tag
+hierarchy does not define <tt>forward_iterator_tag</tt> as multiply derived from
+both <tt>input_iterator_tag</tt> and <tt>output_iterator_tag</tt>.
 </p>
 
 <p>
-<i>Remarks:</i> <tt>U*</tt> shall be implicitly convertible to <tt>T*</tt> and
-<tt>D</tt> shall be the same type as <tt>default_delete&lt;T&gt;</tt>, else these
-constructors shall not participate in overload resolution.
+The work on concepts for iterators showed us that output iterator really
+is fundamentally a second dimension to the iterator categories, rather
+than part of the linear input -&gt; forward -&gt; bidirectional -&gt;
+random-access sequence.  It would be good to clear up these words to
+reflect that, and separately list output iterator requirements in the
+requires clauses for the appropriate algorithms and operations.
 </p>
-</blockquote>
-</blockquote>
 
 
+<p><b>Proposed resolution:</b></p>
+
 
 
 
 
 <hr>
-<h3><a name="1102"></a>1102. <tt>std::vector</tt>'s reallocation policy still unclear</h3>
-<p><b>Section:</b> 23.3.6.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-04-20  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="1186"></a>1186. Forward list could model a stack</h3>
+<p><b>Section:</b> 23.3.5.3 [stack] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">Tentatively NAD Concepts</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-31  <b>Last modified:</b> 2009-11-02</p>
 <p><b>Discussion:</b></p>
 <p>
-I have the impression that even the wording of current draft
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
-does insufficiently express the intent of <tt>vector</tt>'s
-reallocation strategy. This has produced not too old library
-implementations which release memory in the <tt>clear()</tt> function
-and even modern articles about C++ programming cultivate
-the belief that <tt>clear</tt> is allowed to do exactly this. A typical
-example is something like this:
-</p>
-
-<blockquote><pre>const int buf_size = ...;
-std::vector&lt;T&gt; buf(buf_size);
-for (int i = 0; i &lt; some_condition; ++i) {
-  buf.resize(buf_size);
-  write_or_read_data(buf.data());
-  buf.clear(); // Ensure that the next round get's 'zeroed' elements
-}
-</pre></blockquote>
-<p>
-where still the myth is ubiquitous that <tt>buf</tt> might be
-allowed to reallocate it's memory *inside* the <tt>for</tt> loop.
-</p>
-<p>
-IMO the problem is due to the fact, that
+The library template <tt>forward_list</tt> could easily model the idea of a
+<tt>stack</tt>, where the operations work on the front of the list rather than
+the back.  However, the standard library <tt>stack</tt> adaptor cannot support
+this.
 </p>
 
-<ol type="a">
-<li>
-the actual memory-reallocation stability of <tt>std::vector</tt>
-is explained in 23.3.6.2 [vector.capacity]/3 and /6 which
-are describing just the effects of the <tt>reserve</tt>
-function, but in many examples (like above) there
-is no explicit call to <tt>reserve</tt> involved. Further-more
-23.3.6.2 [vector.capacity]/6 does only mention <em>insertions</em>
-and never mentions the consequences of erasing
-elements.
-</li>
-<li>
 <p>
-the effects clause of <tt>std::vector</tt>'s <tt>erase</tt> overloads in
-23.3.6.4 [vector.modifiers]/4 is silent about capacity changes. This
-easily causes a misunderstanding, because the counter
-parting insert functions described in 23.3.6.4 [vector.modifiers]/2
-explicitly say, that
+It would be relatively easy to write a partial specialization for <tt>stack</tt>
+to support <tt>forward_list</tt>, but that opens the question of which header to
+place it in.  A much better solution would be to add a <tt>concept_map</tt> for
+the <tt>StackLikeContainer</tt> concept to the <tt>&lt;forward_list&gt;</tt> header and then
+everything just works, including a user's own further uses in a
+stack-like context.
 </p>
-<blockquote>
-Causes reallocation if the new size is greater than the
-old capacity. If no reallocation happens, all the iterators
-and references before the insertion point remain valid.
-</blockquote>
+
 <p>
-It requires a complex argumentation chain about four
-different places in the standard to provide the - possibly
-weak - proof that calling <tt>clear()</tt> also does <em>never</em> change
-the capacity of the <tt>std::vector</tt> container. Since <tt>std::vector</tt>
-is the de-facto replacement of C99's dynamic arrays this
-type is near to a built-in type and it's specification should
-be clear enough that usual programmers can trust their
-own reading.
+Therefore while I am submitting the issue now so that it is on record, I
+<em>strongly recommend</em> we resolve as "NAD Concepts" as any non-concepts
+based solution will be inferior to the final goal, and the feature is
+not so compelling it must be supported ahead of the concepts-based
+library.
 </p>
-</li>
-</ol>
 
 <p><i>[
-Batavia (2009-05):
+2009-11-02 Howard adds:
 ]</i></p>
 
+
 <blockquote>
-<p>
-Bill believes paragraph 1 of the proposed resolution is unnecessary
-because it is already implied (even if tortuously) by the current wording.
-</p>
-<p>
-Move to Review.
-</p>
+Moved to Tentatively NAD Concepts after 5 positive votes on c++std-lib.
 </blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
-<p><i>[
-This is a minimum version. I also
-suggest that the wording explaining the allocation strategy
-of <tt>std::vector</tt> in 23.3.6.2 [vector.capacity]/3 and /6 is moved into
-a separate sub paragraph of 23.3.6.2 [vector.capacity] <em>before</em>
-any of the prototype's are discussed, but I cannot provide
-reasonable wording changes now
-]</i></p>
 
 
-<ol>
-<li>
+
+
+
+<hr>
+<h3><a name="1187"></a>1187. std::decay</h3>
+<p><b>Section:</b> 20.6.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Jason Merrill <b>Opened:</b> 2009-08-07  <b>Last modified:</b> 2009-08-22</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Change 23.3.6.2 [vector.capacity]/6 as follows:
+I notice that <tt>std::decay</tt> is specified to strip the cv-quals from
+anything but an array or pointer.  This seems incorrect for values of
+class type, since class rvalues can have cv-qualified type (3.10 [basic.lval]/9).
 </p>
+
+<p><i>[
+2009-08-09 Howard adds:
+]</i></p>
+
+
 <blockquote>
-It is guaranteed that no reallocation takes place during
-insertions <ins>or erasures</ins> that happen after a call
-to <tt>reserve()</tt> until the time when an insertion would make
-the size of the vector greater than the value of <tt>capacity()</tt>.
+See the thread starting with c++std-lib-24568 for further discussion.  And
+here is a convenience link to the
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2069.html">original proposal</a>.
+Also see the closely related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>.
 </blockquote>
-</li>
-<li>
+
+
+<p><b>Proposed resolution:</b></p>
+
 <p>
-Change 23.3.6.4 [vector.modifiers]/4 as follows:
+Add a note to <tt>decay</tt> in 20.6.7 [meta.trans.other]:
 </p>
+
 <blockquote>
-<i>Effects:</i> <ins>The capacity shall remain unchanged and no reallocation shall
-happen.</ins>
-Invalidates iterators and references at or after the point
-of the erase.
+[<i>Note:</i> This behavior is similar to the lvalue-to-rvalue (4.1),
+array-to-pointer (4.2), and function-to-pointer (4.3) conversions
+applied when an lvalue expression is used as an rvalue, but also strips
+cv-qualifiers from class types in order to more closely model by-value
+argument passing. &#8212; <i>end note</i>]
 </blockquote>
-</li>
-</ol>
+
+
+
 
 
 
 
 
 <hr>
-<h3><a name="1104"></a>1104. <tt>basic_ios::move</tt> should accept lvalues</h3>
-<p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2009-08-10  <b>Last modified:</b> 2009-08-11</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-With the rvalue reference changes in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
-<tt>basic_ios::move</tt> no longer has the most convenient signature:
+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>
 
-<blockquote><pre>void move(basic_ios&amp;&amp; rhs);
-</pre></blockquote>
-
 <p>
-This signature should be changed to accept lvalues.  It does not need to be
-overloaded to accept rvalues.  This is a special case that only derived clients
-will see.  The generic <tt>move</tt> still needs to accept rvalues.
+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><i>[
-Batavia (2009-05):
-]</i></p>
-
-<blockquote>
 <p>
-Tom prefers, on general principles, to provide both overloads.
-Alisdair agrees.
+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>
-Howard points out that there is no backward compatibility issue
-as this is new to C++0X.
+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>
-We agree that both overloads should be provided,
-and Howard will provide the additional wording.
-Move to Open.
+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>
-</blockquote>
-
-<p><i>[
-2009-05-23 Howard adds:
-]</i></p>
-
-
-<blockquote>
-Added overload, moved to Review.
-</blockquote>
-
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add a signature to the existing prototype in the synopsis of 27.5.4 [ios]
-and in 27.5.4.2 [basic.ios.members]:
+Add two new rows, and change rehash's postcondition in the unordered
+associative container requirements table in 23.2.5 [unord.req]:
 </p>
 
-<blockquote><pre><ins>void move(basic_ios&amp; rhs);</ins>
-void move(basic_ios&amp;&amp; rhs);
-</pre></blockquote>
-
-
+<blockquote>
+<table border="1">
+<caption>Table 87 &#8212; Unordered associative container requirements
+(in addition to container)</caption>
 
+<tbody><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>
+</tbody></table>
+</blockquote>
 
-<hr>
-<h3><a name="1106"></a>1106. Multiple exceptions from connected <tt>shared_future::get()</tt>?</h3>
-<p><b>Section:</b> 30.6.6 [future.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Thomas J. Gritzan <b>Opened:</b> 2009-04-03  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#future.shared_future">active issues</a> in [future.shared_future].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#future.shared_future">issues</a> in [future.shared_future].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-It is not clear, if multiple threads are waiting in a 
-<tt>shared_future::get()</tt> call, if each will rethrow the stored exception.
-</p>
-<p>
-Paragraph 9 reads: 
+Add a footnote to 23.2.5 [unord.req] p12:
 </p>
+
 <blockquote>
-<i>Throws:</i> the stored exception, if an exception was stored and not 
-retrieved before.
-</blockquote>
-<p>
-The "not retrieved before" suggests that only one exception is thrown, 
-but one exception for each call to <tt>get()</tt> is needed, and multiple calls 
-to <tt>get()</tt> even on the same <tt>shared_future</tt> object seem to be allowed. 
-</p>
 <p>
-I suggest removing "and not retrieved before" from the Throws paragraph. 
-I recommend adding a note that explains that multiple calls on <tt>get()</tt> are 
-allowed, and each call would result in an exception if an exception was 
-stored. 
+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>
 
-<p><i>[
-Batavia (2009-05):
-]</i></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>
 
-<blockquote>
-<p>
-We note there is a pending paper by Detlef
-on such <tt>future</tt>-related issues;
-we would like to wait for his paper before proceeding.
-</p>
 <p>
-Alisdair suggests we may want language to clarify that this
-<tt>get()</tt> function can be called from several threads
-with no need for explicit locking.
+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>
-Move to Open.
+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>
 
+<blockquote><pre><ins>
+float min_load_factor() const;
+void min_load_factor(float z);
+</ins></pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 30.6.6 [future.shared_future]:
+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><pre>const R&amp; shared_future::get() const; 
-R&amp; shared_future&lt;R&amp;&gt;::get() const; 
-void shared_future&lt;void&gt;::get() const;
-</pre>
 <blockquote>
-<p>...</p>
-<p>
--9- <i>Throws:</i> the stored exception, if an exception was stored<del> and not retrieved before</del>.
-<ins>
-[<i>Note:</i> Multiple calls on <tt>get()</tt> are 
-allowed, and each call would result in an exception if an exception was 
-stored. &#8212; <i>end note</i>]
-</ins>
-</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="1108"></a>1108. thread.req.exception overly constrains implementations</h3>
-<p><b>Section:</b> 30.2.2 [thread.req.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Christopher Kohlhoff <b>Opened:</b> 2009-04-25  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1189"></a>1189. Awkward interface for changing the number of buckets in an unordered associative container</h3>
+<p><b>Section:</b> 23.2.5 [unord.req], 23.5 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2009-08-10  <b>Last modified:</b> 2009-10-28</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The current formulation of 30.2.2 [thread.req.exception]/2 reads:
+Consider a typical use case: I create an <tt>unordered_map</tt> and then start
+adding elements to it one at a time. I know that it will eventually need
+to store a few million elements, so, for performance reasons, I would
+like to reserve enough capacity that none of the calls to <tt>insert</tt> will
+trigger a rehash.
 </p>
-<blockquote>
-The error_category of the <tt>error_code</tt> reported by such an
-exception's <tt>code()</tt> member function is as specified in the error
-condition Clause.
-</blockquote>
+
 <p>
-This constraint on the code's associated <tt>error_categor</tt> means an
-implementation must perform a mapping from the system-generated
-error to a <tt>generic_category()</tt> error code. The problems with this
-include:
+Unfortunately, the existing interface makes this awkward. The user
+naturally sees the problem in terms of the number of elements, but the
+interface presents it as buckets. If <tt>m</tt> is the map and <tt>n</tt> is the expected
+number of elements, this operation is written <tt>m.rehash(n /
+m.max_load_factor())</tt> &#8212; not very novice friendly.
 </p>
 
-<ul>
-<li>
-The mapping is always performed, even if the resultant value is
- never used.
-</li>
+<p><i>[
+2009-09-30 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+I recommend to replace "<tt>resize</tt>" by a different name like
+"<tt>reserve</tt>", because that would better match the intended
+use-case. Rational: Any existing resize function has the on-success
+post-condition that the provided size is equal to <tt>size()</tt>, which
+is not satisfied for the proposal. Reserve seems to fit the purpose of
+the actual renaming suggestion.
+</blockquote>
+
+<p><i>[
+2009-10-28 Ganesh summarizes alternative resolutions and expresses a
+strong preference for the second (and opposition to the first):
+]</i></p>
+
+
+<blockquote>
+<ol>
 <li>
 <p>
-The original error produced by the operating system is lost.
+In the unordered associative container requirements (23.2.5 [unord.req]),
+remove the row for
+rehash and replace it with:
 </p>
-</li>
-</ul>
+
+<blockquote>
+<table border="1">
+<caption>Table 87 &#8212; Unordered associative container requirements
+(in addition to container)</caption>
+
+<tbody><tr>
+<th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
+<th>Complexity</th>
+</tr>
+<tr>
+<td><tt>a.<del>rehash</del><ins>reserve</ins>(n)</tt></td>
+<td><tt>void</tt></td>
+<td>
+Post: <tt>a.bucket_count &gt; <ins>max(</ins>a.size()<ins>, n)</ins>
+/ a.max_load_factor()</tt><del> and <tt>a.bucket_count()
+&gt;= n</tt></del>.
+</td>
+<td>
+Average case linear in <tt>a.size()</tt>, worst case quadratic.
+</td>
+</tr>
+</tbody></table>
+</blockquote>
+
 <p>
-The latter was one of Peter Dimov's main objections (in a private
-email discussion) to the original <tt>error_code</tt>-only design, and led to
-the creation of <tt>error_condition</tt> in the first place. Specifically,
-<tt>error_code</tt> and <tt>error_condition</tt> are intended to perform the following
-roles:
+Make the corresponding change 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>
-<ul>
-<li>
-<tt>error_code</tt> holds the original error produced by the operating
- system.
 </li>
 <li>
-<tt>error_condition</tt> and the generic category provide a set of well
- known error constants that error codes may be tested against.
-</li>
-</ul>
+
 <p>
-Any mapping determining correspondence of the returned error code to
-the conditions listed in the error condition clause falls under the
-"latitude" granted to implementors in 19.5.1.5 [syserr.errcat.objects].
-(Although obviously their latitude is restricted a little by the
-need to match the right error condition when returning an error code
-from a library function.)
+In 23.2.5 [unord.req]/9, table 98, append a new row after the last one:
 </p>
+
+<blockquote>
+<table border="1">
+<caption>Table 87 &#8212; Unordered associative container requirements
+(in addition to container)</caption>
+
+<tbody><tr>
+<th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
+<th>Complexity</th>
+</tr>
+<tr>
+<td><tt>a.rehash(n)</tt></td>
+<td><tt>void</tt></td>
+<td>
+Post: <tt>a.bucket_count &gt; a.size()
+/ a.max_load_factor()</tt> and <tt>a.bucket_count()
+&gt;= n</tt>.
+</td>
+<td>
+Average case linear in <tt>a.size()</tt>, worst case quadratic.
+</td>
+</tr>
+<tr>
+<td><ins>
+<tt>a.reserve(n)</tt>
+</ins></td>
+<td><ins>
+<tt>void</tt>
+</ins></td>
+<td><ins>
+Same as <tt>a.rehash(ceil(n / a.max_load_factor()))</tt>
+</ins></td>
+<td><ins>
+Average case linear in <tt>a.size()</tt>, worst case quadratic.
+</ins></td>
+</tr>
+</tbody></table>
+</blockquote>
+
 <p>
-It is important that this <tt>error_code/error_condition</tt> usage is done
-correctly for the thread library since it is likely to set the
-pattern for future TR libraries that interact with the operating
-system.
+In 23.5.1 [unord.map]/3 in the definition of class template <tt>unordered_map</tt>, in
+23.5.2 [unord.multimap]/3 in the definition of class template <tt>unordered_multimap</tt>, in
+23.5.3 [unord.set]/3 in the definition of class template <tt>unordered_set</tt> and in
+23.5.4 [unord.multiset]/3 in the definition of class template <tt>unordered_multiset</tt>, add the
+following line after member function <tt>rehash()</tt>:
 </p>
 
+<blockquote><pre>void reserve(size_type n);
+</pre></blockquote>
+
+</li>
+</ol>
+</blockquote>
+
 <p><i>[
-Batavia (2009-05):
+2009-10-28 Howard:
 ]</i></p>
 
+
 <blockquote>
-Move to Open, and recommend the issue be deferred until after the next
-Committee Draft is issued.
-</blockquote>
+<p>
+Moved to Tentatively Ready after 5 votes in favor of Ganesh's option 2 above.
+The original proposed wording now appears here:
+</p>
 
+<blockquote>
+<p>
+Informally: instead of providing <tt>rehash(n)</tt> provide <tt>resize(n)</tt>, with the
+semantics "make the container a good size for <tt>n</tt> elements".
+</p>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 30.2.2 [thread.req.exception]/2:
+In the unordered associative container requirements (23.2.5 [unord.req]),
+remove the row for
+rehash and replace it with:
 </p>
 
 <blockquote>
+<table border="1">
+<caption>Table 87 &#8212; Unordered associative container requirements
+(in addition to container)</caption>
+
+<tbody><tr>
+<th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
+<th>Complexity</th>
+</tr>
+<tr>
+<td><tt>a.<del>rehash</del><ins>resize</ins>(n)</tt></td>
+<td><tt>void</tt></td>
+<td>
+Post: <tt>a.bucket_count &gt; <ins>max(</ins>a.size()<ins>, n)</ins>
+/ a.max_load_factor()</tt><del> and <tt>a.bucket_count()
+&gt;= n</tt></del>.
+</td>
+<td>
+Average case linear in <tt>a.size()</tt>, worst case quadratic.
+</td>
+</tr>
+</tbody></table>
+</blockquote>
+
+<p>Make the corresponding change 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>
+
+</blockquote>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
--2- <del>The <tt>error_category</tt> (19.5.1.1) of the <tt>error_code</tt> reported by
-such an exception's <tt>code()</tt> member function 
-is as specified in the error condition Clause.</del>
-<ins>
-The <tt>error_code</tt> reported by such an exception's <tt>code()</tt> member
-function shall compare equal to one of the conditions specified in
-the function's error condition Clause. [<i>Example:</i> When the thread
-constructor fails:
-</ins>
+In 23.2.5 [unord.req]/9, table 98, append a new row after the last one:
 </p>
-<blockquote><pre><ins>
-ec.category() == implementation-defined // probably system_category
-ec == errc::resource_unavailable_try_again // holds true
-</ins></pre></blockquote>
 
-<p><ins>
-&#8212; <i>end example</i>]
-</ins></p>
+<blockquote>
+<table border="1">
+<caption>Table 87 &#8212; Unordered associative container requirements
+(in addition to container)</caption>
 
+<tbody><tr>
+<th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
+<th>Complexity</th>
+</tr>
+<tr>
+<td><tt>a.rehash(n)</tt></td>
+<td><tt>void</tt></td>
+<td>
+Post: <tt>a.bucket_count &gt; a.size()
+/ a.max_load_factor()</tt> and <tt>a.bucket_count()
+&gt;= n</tt>.
+</td>
+<td>
+Average case linear in <tt>a.size()</tt>, worst case quadratic.
+</td>
+</tr>
+<tr>
+<td><ins>
+<tt>a.reserve(n)</tt>
+</ins></td>
+<td><ins>
+<tt>void</tt>
+</ins></td>
+<td><ins>
+Same as <tt>a.rehash(ceil(n / a.max_load_factor()))</tt>
+</ins></td>
+<td><ins>
+Average case linear in <tt>a.size()</tt>, worst case quadratic.
+</ins></td>
+</tr>
+</tbody></table>
 </blockquote>
 
+<p>
+In 23.5.1 [unord.map]/3 in the definition of class template <tt>unordered_map</tt>, in
+23.5.2 [unord.multimap]/3 in the definition of class template <tt>unordered_multimap</tt>, in
+23.5.3 [unord.set]/3 in the definition of class template <tt>unordered_set</tt> and in
+23.5.4 [unord.multiset]/3 in the definition of class template <tt>unordered_multiset</tt>, add the
+following line after member function <tt>rehash()</tt>:
+</p>
+
+<blockquote><pre>void reserve(size_type n);
+</pre></blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="1110"></a>1110. Is <tt>for_each</tt> overconstrained?</h3>
-<p><b>Section:</b> 25.3.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-29  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2009-08-10  <b>Last modified:</b> 2009-08-11</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Quoting working paper for reference (25.3.4 [alg.foreach]):
+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>
 
-<blockquote>
-<pre>template&lt;InputIterator Iter, Callable&lt;auto, Iter::reference&gt; Function&gt;
-  requires CopyConstructible&lt;Function&gt;
-  Function for_each(Iter first, Iter last, Function f);
-</pre>
-<blockquote>
+
+<p><b>Proposed resolution:</b></p>
 <p>
-1 Effects: Applies f to the result of dereferencing every iterator in the
- range [first,last), starting from first and proceeding to last - 1.
+In the unordered associative container requirements table, change:
 </p>
+
+<blockquote>
+<table border="1">
+<caption>Table 87 &#8212; Unordered associative container requirements
+(in addition to container)</caption>
+
+<tbody><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>
+</tbody></table>
+</blockquote>
+
 <p>
-2 Returns: f.
+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>
-3 Complexity: Applies f exactly last - first times.
+If issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1188">1188</a> is also accepted, make the same changes for
+<tt>min_load_factor</tt>.
 </p>
-</blockquote>
-</blockquote>
 
+
+
+
+
+<hr>
+<h3><a name="1191"></a>1191. <tt>tuple get</tt> API should respect rvalues</h3>
+<p><b>Section:</b> 20.5.2.6 [tuple.elem] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-08-18  <b>Last modified:</b> 2009-10-31</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-P2 implies the passed object <tt>f</tt> should be invoked at each stage, rather than
-some copy of <tt>f</tt>.  This is important if the return value is to usefully
-accumulate changes.  So the requirements are an object of type <tt>Function</tt> can
-be passed-by-value, invoked multiple times, and then return by value.  In
-this case, <tt>MoveConstructible</tt> is sufficient. This would open support for
-move-only functors, which might become important in concurrent code as you
-can assume there are no other references (copies) of a move-only type and so
-freely use them concurrently without additional locks.
+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>[
-See further discussion starting with c++std-lib-23686.
+2009-10-30 Alisdair adds:
 ]</i></p>
 
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
-
 <blockquote>
 <p>
-Pete suggests we may want to look at this in a broader context
-involving other algorithms.
-We should also consider the implications of parallelism.
+The issue of rvalue overloads of get for tuple-like types was briefly
+discussed in Santa Cruz.
 </p>
+
 <p>
-Move to Open, and recommend the issue be deferred until after the next
-Committee Draft is issued.
+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><b>Proposed resolution:</b></p>
 <p>
-Change 25.2 [algorithms.syn] and 25.3.4 [alg.foreach]:
+Add the following signature to p2 20.5.1 [tuple.general]
 </p>
 
-<blockquote><pre>template&lt;InputIterator Iter, Callable&lt;auto, Iter::reference&gt; Function&gt;
-  requires <del>CopyConstructible</del> <ins>MoveConstructible</ins>&lt;Function&gt;
-  Function for_each(Iter first, Iter last, Function f);
-</pre></blockquote>
+<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.5.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>
 
 
-<hr>
-<h3><a name="1112"></a>1112. bitsets and new style for loop</h3>
-<p><b>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-06  <b>Last modified:</b> 2009-07-25</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>Std::bitset</tt> is a homogeneous container-like sequence of bits, yet it does
-not model the Range concept so cannot be used with the new for-loop syntax.
-It is the only such type in the library that does NOT support the new for
-loop.
-</p>
-<p>
-The obvious reason is that bitset does not support iterators.
-</p>
-<p>
-At least two reasonable solutions are available:
-</p>
-<ol type="i">
-<li>
-Add an iterator interface to <tt>bitset</tt>, bringing its interface close to that
-of <tt>std::array</tt>
-</li>
-<li>
-Provide an unspecified concept_map for <tt>Range&lt;bitset&gt;</tt>.
-</li>
-</ol>
+<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>. &#8212; <i>end note</i>]
+</ins></p>
+
+</blockquote>
+</blockquote>
+
 <p>
-The latter will still need some kind of iterator-like adapter for <tt>bitset</tt>,
-but gives implementers greater freedom on the details. E.g. begin/end return
-some type that simply invokes <tt>operator[]</tt> on the object it wraps, and
-increments its index on <tt>operator++</tt>.  A vendor can settle for <tt>InputIterator</tt>
-support, rather than wrapping up a full <tt>RandomAccessIterator</tt>.
+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>
-I have a mild preference for option (ii) as I think it is less work to
-specify at this stage of the process, although (i) is probably more useful
-in the long run.
+And to p5 20.3.5 [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>
-Hmm, my wording looks a little woolly, as it does not say what the element
-type of the range is.  Do I get a range of <tt>bool</tt>, <tt>bitset&lt;N&gt;::reference</tt>, or
-something else entirely?
+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>
-I guess most users will assume the behaviour of reference, but expect to
-work with <tt>bool</tt>.  <tt>Bool</tt> is OK for read-only traversal, but you really need to
-take a reference to a <tt>bitset::reference</tt> if you want to write back.
+And after p8 23.3.1.7 [array.tuple]
 </p>
 
-<p><i>[
-Batavia (2009-05):
-]</i></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>
-Move to Open.
-We further recommend this be deferred until after the next Committee Draft.
+<blockquote><ins>
+<i>Effects:</i> Equivalent to <tt>return std::move(get&lt;I&gt;(a));</tt>
+</ins></blockquote>
 </blockquote>
 
-<p><i>[
-2009-05-25 Alisdair adds:
-]</i></p>
 
 
-<blockquote>
+
+
+
+<hr>
+<h3><a name="1192"></a>1192. <tt>basic_string</tt> missing definitions for <tt>cbegin</tt> / <tt>cend</tt> / <tt>crbegin</tt> / <tt>crend</tt></h3>
+<p><b>Section:</b> 21.4.3 [string.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-08-14  <b>Last modified:</b> 2009-10-29</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-I just stumbled over the <tt>Range concept_map</tt> for <tt>valarray</tt> and this should
-probably set the precedent on how to write the wording.
+Unlike the containers in clause 23, <tt>basic_string</tt> has definitions for
+<tt>begin()</tt> and <tt>end()</tt>, but these have not been updated to include <tt>cbegin</tt>,
+<tt>cend</tt>, <tt>crbegin</tt> and <tt>crend</tt>.
 </p>
 
 <p><i>[
-Howard: I've replaced the proposed wording with Alisdair's suggestion.
+2009-10-28 Howard:
 ]</i></p>
 
 
+<blockquote>
+Moved to Tentatively NAD after 5 positive votes on c++std-lib.  Added
+rationale.
 </blockquote>
 
 <p><i>[
-2009-07-24 Daniel modifies the proposed wording for non-concepts.
+2009-10-28 Alisdair disagrees:
 ]</i></p>
 
 
+<blockquote>
+<p>
+I'm going to have to speak up as the dissenting voice.
+</p>
 
-
-<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
 <p>
-Modify the section 20.3.6 [template.bitset] <tt>&lt;bitset&gt;</tt> synopsis by adding
-the following at the end of the synopsis:
+I agree the issue could be handled editorially, and that would be my
+preference if Pete feels this is appropriate. Failing that, I really
+think this issue should be accepted and moved to ready.  The other
+begin/end functions all have a semantic definition for this template,
+and it is confusing if a small few are missing.
 </p>
-<blockquote><pre><ins>
-// XX.X.X bitset range access [bitset.range]
-template&lt;size_t N&gt; <i>unspecified-1</i> begin(bitset&lt;N&gt;&amp;);
-template&lt;size_t N&gt; <i>unspecified-2</i> begin(const bitset&lt;N&gt;&amp;);
-template&lt;size_t N&gt; <i>unspecified-1</i> end(bitset&lt;N&gt;&amp;);
-template&lt;size_t N&gt; <i>unspecified-2</i> end(const bitset&lt;N&gt;&amp;);
-</ins>
-</pre></blockquote>
-</li>
-<li>
+
 <p>
-Add a new section <ins>"bitset range access" [bitset.range]</ins>
-after the current section 20.3.6.3 [bitset.operators] with the following series of
-paragraphs:
+I agree that an alternative would be to strike <em>all</em> the definitions for
+<tt>begin/end/rbegin/rend</tt> and defer completely to the requirements tables in
+clause 23.  I think that might be confusing without a forward reference
+though, as those tables are defined in a *later* clause than the
+basic_string template itself.  If someone wants to pursue this I would
+support it, but recommend it as a separate issue.
 </p>
-<blockquote>
+
 <p>
-<ins>
-1.  In the <tt>begin</tt> and <tt>end</tt> function templates that follow, <i>unspecified-1</i>
-is a type that meets the requirements of a mutable random access
-iterator (24.2.6 [random.access.iterators]) whose <tt>value_type</tt> is <tt>bool</tt> and
-whose reference type is <tt>bitset&lt;N&gt;::reference</tt>.
-<i>unspecified-2</i> is a type that meets the requirements of a constant
-random access iterator (24.2.6 [random.access.iterators]) whose <tt>value_type</tt>
-is <tt>bool</tt> and whose reference type is <tt>bool</tt>.
-</ins>
+So my preference is strongly to move Ready over NAD, and a stronger
+preference for NAD Editorial if Pete is happy to make these changes.
 </p>
-<pre><ins>
-template&lt;size_t N&gt; <i>unspecified-1</i> begin(bitset&lt;N&gt;&amp;);
-template&lt;size_t N&gt; <i>unspecified-2</i> begin(const bitset&lt;N&gt;&amp;);
-</ins>
-</pre>
-<blockquote>
-<ins>2.  Returns: an iterator referencing the first bit in the bitset.</ins>
+
 </blockquote>
 
-<pre><ins>
-template&lt;size_t N&gt; <i>unspecified-1</i> end(bitset&lt;N&gt;&amp;);
-template&lt;size_t N&gt; <i>unspecified-2</i> end(const bitset&lt;N&gt;&amp;);
-</ins></pre>
+<p><i>[
+2009-10-29 Howard:
+]</i></p>
+
 
 <blockquote>
-<ins>3.  Returns: an iterator referencing one past the last bit in the
-bitset.</ins>
+Moved to Tentatively Ready after 5 positive votes on c++std-lib.  Removed
+rationale to mark it NAD.  :-)
 </blockquote>
-</blockquote>
-</li>
-</ol>
 
 
 
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to 21.4.3 [string.iterators]
+</p>
+
+<blockquote><pre>iterator       begin();
+const_iterator begin() const;
+<ins>const_iterator cbegin() const;</ins>
+</pre>
+
+<p>...</p>
+
+<pre>iterator       end();
+const_iterator end() const;
+<ins>const_iterator cend() const;</ins>
+</pre>
+
+<p>...</p>
 
+<pre>reverse_iterator       rbegin();
+const_reverse_iterator rbegin() const;
+<ins>const_reverse_iterator crbegin() const;</ins>
+</pre>
 
+<p>...</p>
 
+<pre>reverse_iterator       rend();
+const_reverse_iterator rend() const;
+<ins>const_reverse_iterator crend() const;</ins>
+</pre>
 
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="1113"></a>1113. <tt>bitset::to_string</tt> could be simplified</h3>
-<p><b>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-09  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1193"></a>1193. <tt>default_delete</tt> cannot be instantiated with  incomplete types</h3>
+<p><b>Section:</b> 20.8.14.1 [unique.ptr.dltr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-08-18  <b>Last modified:</b> 2009-08-22</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/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/lwg-defects.html#853">853</a> our resolution is changing the signature by adding two
-defaulting arguments to 3 calls.  In principle, this means that ABI breakage
-is not an issue, while API is preserved.
+According to the general rules of 17.6.3.8 [res.on.functions]/2 b 5 the effects
+are undefined, if an incomplete type is used to instantiate a library template. But neither in
+20.8.14.1 [unique.ptr.dltr] nor
+in any other place of the standard such explicit allowance is given.
+Since this template is intended to be instantiated with incomplete
+types, this must
+be fixed.
 </p>
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-With that observation, it would be very nice to use the new ability to
-supply default template parameters to function templates to collapse all 3
-signatures into 1.  In that spirit, this issue offers an alternative resolution
-than that of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>.
+Add two new paragraphs directly to 20.8.14.1 [unique.ptr.dltr] (before
+20.8.14.1.1 [unique.ptr.dltr.dflt]) with the following
+content:
 </p>
 
-<p><i>[
-Batavia (2009-05):
-]</i></p>
-
 <blockquote>
-Move to Open,
-and look at the issue again after <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a> has been accepted.
-We further recommend this be deferred until after the next Committee Draft.
+<p><ins>
+The class template <tt>default_delete</tt> serves as the default deleter (destruction policy) for
+the class template <tt>unique_ptr</tt>.
+</ins></p>
+
+<p><ins>
+The template parameter <tt>T</tt> of <tt>default_delete</tt> may be an incomplete type.
+</ins></p>
 </blockquote>
 
 
-<p><b>Proposed resolution:</b></p>
 
-<ol type="A">
-<li>
+
+
+<hr>
+<h3><a name="1194"></a>1194. Unintended <tt>queue</tt> constructor</h3>
+<p><b>Section:</b> 23.3.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-08-20  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.adaptors">active issues</a> in [container.adaptors].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.adaptors">issues</a> in [container.adaptors].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-In 20.3.6 [template.bitset]/1 (class bitset) ammend:
+23.3.5.1.1 [queue.defn] has the following <tt>queue</tt> constructor:
 </p>
-<blockquote><pre>template &lt;class charT <ins>= char</ins>,
-            class traits <ins>= char_traits&lt;charT&gt;</ins>,
-            class Allocator <ins>= allocator&lt;charT&gt;</ins>&gt; 
-  basic_string&lt;charT, traits, Allocator&gt;
-  to_string(charT zero = charT('0'), charT one = charT('1')) const;
-<del>template &lt;class charT, class traits&gt; 
-  basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt; to_string() const; 
-template &lt;class charT&gt; 
-  basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt; to_string() const; 
-basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt; to_string() const;</del>
+
+<blockquote><pre>template &lt;class Alloc&gt; explicit queue(const Alloc&amp;);
 </pre></blockquote>
-</li>
-<li>
+
 <p>
-In 20.3.6.2 [bitset.members] prior to p35 ammend:
+This will be implemented like so:
 </p>
-<blockquote><pre>template &lt;class charT <ins>= char</ins>,
-            class traits <ins>= char_traits&lt;charT&gt;</ins>,
-            class Allocator <ins>= allocator&lt;charT&gt;</ins>&gt; 
-  basic_string&lt;charT, traits, Allocator&gt;
-  to_string(charT zero = charT('0'), charT one = charT('1')) const;
-</pre></blockquote>
-</li>
-<li>
-Strike 20.3.6.2 [bitset.members] paragraphs 37 -&gt; 39 (including signature
-above 37)
-</li>
-</ol>
-
-
-
 
+<blockquote><pre>template &lt;class Alloc&gt; explicit queue(const Alloc&amp; a) : c(a) {}
+</pre></blockquote>
 
+<p>
+The issue is that <tt>Alloc</tt> can be anything that a container will construct
+from, for example an <tt>int</tt>.  Is this intended to compile?
+</p>
 
-<hr>
-<h3><a name="1114"></a>1114. Type traits underspecified</h3>
-<p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-05-12  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<blockquote><pre>queue&lt;int&gt; q(5);
+</pre></blockquote>
 
 <p>
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>.
+Before the addition of this constructor, <tt>queue&lt;int&gt;(5)</tt> would not compile.
+I ask, not because this crashes, but because it is new and appears to be
+unintended.  We do not want to be in a position of accidently introducing this
+"feature" in C++0X and later attempting to remove it.
 </p>
 
 <p>
-The current wording in 20.6.1 [meta.rqmts] is still unclear concerning
-it's requirements on the type traits classes regarding ambiguities.
-Specifically it's unclear
+I've picked on <tt>queue</tt>.  <tt>priority_queue</tt> and <tt>stack</tt> have
+the same issue.  Is it useful to create a <tt>priority_queue</tt> of 5
+identical elements?
 </p>
 
-<ul>
-<li>
-if a predicate trait (20.6.4 [meta.unary], 20.6.5 [meta.rel]) could derive from both
-<tt>true_type</tt>/<tt>false_type</tt>.
-</li>
-<li>
-if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could ambiguously derive
-from the same specified result type.
-</li>
-<li>
-if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could derive from other
-<tt>integral_constant</tt> types making the contained names ambiguous
-</li>
-<li>
-if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could have other base
-classes that contain members hiding the name of the result type members
-or make the contained member names ambiguous.
-</li>
-</ul>
+<p><i>[
+Daniel, Howard and Pablo collaborated on the proposed wording.
+]</i></p>
+
 
 <p><i>[
-Batavia (2009-05):
+2009-10 Santa Cruz:
 ]</i></p>
 
+
 <blockquote>
-<p>
-Alisdair would prefer to factor some of the repeated text,
-but modulo a corner case or two,
-he believes the proposed wording is otherwise substantially correct.
-</p>
-<p>
-Move to Open.
-</p>
+Move to Ready.
 </blockquote>
 
 
+
 <p><b>Proposed resolution:</b></p>
+
 <p><i>[
-The usage of the notion of a <i>BaseCharacteristic</i> below
-might be
-useful in other places - e.g. to define the base class relation in
-20.7.5 [refwrap], 20.7.15 [func.memfn], or 20.7.16.2 [func.wrap.func].
-In this case it's definition should probably
-be moved to Clause 17
+This resolution includes a semi-editorial clean up, giving definitions to members
+which in some cases weren't defined since C++98.
+This resolution also offers editorially different wording for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>,
+and it also provides wording for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1196">1196</a>.
 ]</i></p>
 
 
-<ol>
-<li>
 <p>
-Change 20.6.1 [meta.rqmts]/1 as indicated:
+Change  container.adaptors, p1:
 </p>
+
 <blockquote>
-[..] It shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, and publicly
-<ins>and unambiguously</ins> derived, directly or indirectly, from
-<ins>its <i>BaseCharacteristic</i>, which is</ins> a specialization of the
-template <tt>integral_constant</tt> (20.6.3), with the arguments to the template
-<tt>integral_constant</tt> determined by the requirements for the particular
-property being described. <ins>The member names of the
-<i>BaseCharacteristic</i> shall be unhidden and unambiguously
-available in the <i>UnaryTypeTrait</i>.</ins>
+The container adaptors each take a <tt>Container</tt> template parameter, and
+each constructor takes a <tt>Container</tt> reference argument. This container is
+copied into the <tt>Container</tt> member of each adaptor. If the container takes
+an allocator, then a compatible allocator may be passed in to the
+adaptor's constructor. Otherwise, normal copy or move construction is
+used for the container argument. <del>[<i>Note:</i> it is not necessary for an
+implementation to distinguish between the one-argument constructor that
+takes a <tt>Container</tt> and the one- argument constructor that takes an
+allocator_type. Both forms use their argument to construct an instance
+of the container. &#8212; <i>end note</i>]</del>
 </blockquote>
-</li>
-<li>
+
 <p>
-Change 20.6.1 [meta.rqmts]/2 as indicated:
+Change  queue.defn, p1:
+</p>
+
+<blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt;
+class queue {
+public:
+  typedef typename Container::value_type      value_type;
+  typedef typename Container::reference       reference;
+  typedef typename Container::const_reference const_reference;
+  typedef typename Container::size_type       size_type;
+  typedef Container                           container_type;
+protected:
+  Container c;
+
+public:
+  explicit queue(const Container&amp;);
+  explicit queue(Container&amp;&amp; = Container());
+  queue(queue&amp;&amp; q)<ins>;</ins><del> : c(std::move(q.c)) {}</del>
+  template &lt;class Alloc&gt; explicit queue(const Alloc&amp;);
+  template &lt;class Alloc&gt; queue(const Container&amp;, const Alloc&amp;);
+  template &lt;class Alloc&gt; queue(Container&amp;&amp;, const Alloc&amp;);
+  template &lt;class Alloc&gt; queue(queue&amp;&amp;, const Alloc&amp;);
+  queue&amp; operator=(queue&amp;&amp; q)<ins>;</ins><del> { c = std::move(q.c); return *this; }</del>
+
+  bool empty() const          { return c.empty(); }
+  ...
+};
+</pre></blockquote>
+
+<p>
+Add a new section after 23.3.5.1.1 [queue.defn], [queue.cons]:
 </p>
+
 <blockquote>
-[..] It shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, and publicly
-<ins>and unambiguously</ins> derived, directly or indirectly, from
-<del>an instance</del> <ins>its <i>BaseCharacteristic</i>, which is a
-specialization</ins> of the template <tt>integral_constant</tt> (20.6.3), with
-the arguments to the template <tt>integral_constant</tt> determined by the
-requirements for the particular relationship being described. <ins>The
-member names of the <i>BaseCharacteristic</i> shall be unhidden
-and unambiguously available in the <i>BinaryTypeTrait</i>.</ins>
+<p><b><tt>queue</tt> constructors [queue.cons]</b></p>
+
+<pre>explicit queue(const Container&amp; cont);
+</pre>
+
+<blockquote>
+
+<p>
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>cont</tt>.
+</p>
+
 </blockquote>
-</li>
-<li>
+
+<pre>explicit queue(Container&amp;&amp; cont = Container());
+</pre>
+
+<blockquote>
+
 <p>
-Change 20.6.4 [meta.unary]/2 as indicated:
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(cont)</tt>.
 </p>
+
+</blockquote>
+
+<pre>queue(queue&amp;&amp; q)
+</pre>
+
 <blockquote>
-Each of these templates shall be a <i>UnaryTypeTrait</i> (20.6.1),
-<del>publicly derived directly or indirectly from <tt>true_type</tt> if the
-corresponding condition is true, otherwise from <tt>false_type</tt></del>
-<ins>where its <i>BaseCharacteristic</i> shall be <tt>true_type</tt> if the
-corresponding condition is true, otherwise <tt>false_type</tt></ins>.
+
+<p>
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(q.c)</tt>.
+</p>
+
 </blockquote>
-</li>
-<li>
+
+<p>
+For each of the following constructors,
+if <tt>uses_allocator&lt;container_type, Alloc&gt;::value</tt> is <tt>false</tt>,
+then the constructor shall not participate in overload resolution.
+</p>
+
+<pre>template &lt;class Alloc&gt; 
+  explicit queue(const Alloc&amp; a);
+</pre>
+
+<blockquote>
+
 <p>
-Change 20.6.5 [meta.rel]/2 as indicated:
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>a</tt>.
 </p>
 
-<blockquote>
-Each of these templates shall be a <i>BinaryTypeTrait</i> (20.6.1),
-<del>publicly derived directly or indirectly from <tt>true_type</tt> if the
-corresponding condition is true, otherwise from <tt>false_type</tt></del>
-<ins>where its <i>BaseCharacteristic</i> shall be <tt>true_type</tt> if the
-corresponding condition is true, otherwise <tt>false_type</tt></ins>.
 </blockquote>
-</li>
-</ol>
 
+<pre>template &lt;class Alloc&gt; 
+  queue(const container_type&amp; cont, const Alloc&amp; a);
+</pre>
+
+<blockquote>
 
+<p>
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>cont</tt> as the first
+argument and <tt>a</tt> as the second argument.
+</p>
 
+</blockquote>
 
+<pre>template &lt;class Alloc&gt; 
+  queue(container_type&amp;&amp; cont, const Alloc&amp; a);
+</pre>
 
+<blockquote>
 
-<hr>
-<h3><a name="1115"></a>1115. <tt>va_copy</tt> missing from Standard macros table</h3>
-<p><b>Section:</b> C.2 [diff.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Miles Zhao <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-05-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#diff.library">active issues</a> in [diff.library].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#diff.library">issues</a> in [diff.library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-In "Table 122 -- Standard macros" of C.2 [diff.library], which lists the 56 macros
-inherited from C library, <tt>va_copy</tt> seems to be missing. But in
-"Table 21 -- Header <tt>&lt;cstdarg&gt;</tt> synopsis" (18.10 [support.runtime]), there is.
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(cont)</tt> as the
+first argument and <tt>a</tt> as the second argument.
 </p>
 
+</blockquote>
+
+<pre>template &lt;class Alloc&gt; 
+  queue(queue&amp;&amp; q, const Alloc&amp; a);
+</pre>
+
+<blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Add <tt>va_copy</tt> to Table 122 -- Standard macros in C.2 [diff.library].
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(q.c)</tt> as the
+first argument and <tt>a</tt> as the second argument.
 </p>
 
+</blockquote>
 
+<pre>queue&amp; operator=(queue&amp;&amp; q);
+</pre>
 
+<blockquote>
 
-
-<hr>
-<h3><a name="1116"></a>1116. Literal constructors for tuple</h3>
-<p><b>Section:</b> 20.5.2 [tuple.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-05-24</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.tuple">issues</a> in [tuple.tuple].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-It is not currently possible to construct <tt>tuple</tt> literal values,
-even if the elements are all literal types.  This is because parameters
-are passed to constructor by reference.
-</p>
-<p>
-An alternative would be to pass all constructor arguments by value, where it
-is known that *all* elements are literal types.  This can be determined with
-concepts, although note that the negative constraint really requires
-factoring out a separate concept, as there is no way to provide an 'any of
-these fails' constraint inline.
+<i>Effects:</i> Assigns <tt>c</tt> with <tt>std::move(q.c)</tt>.
 </p>
+
 <p>
-Note that we will have similar issues with <tt>pair</tt> (and
-<tt>tuple</tt> constructors from <tt>pair</tt>) although I am steering
-clear of that class while other constructor-related issues settle.
+<i>Returns:</i> <tt>*this</tt>.
 </p>
 
+</blockquote>
+
+
+
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Ammend the tuple class template declaration in 20.5.2 [tuple.tuple] as
-follows
+Add to 23.3.5.2.1 [priqueue.cons]:
 </p>
 
 <blockquote>
+
+<pre>priority_queue(priority_queue&amp;&amp; q);
+</pre>
+
+<blockquote>
+
 <p>
-Add the following concept:
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(q.c)</tt> and
+initializes <tt>comp</tt> with <tt>std::move(q.comp)</tt>.
 </p>
 
-<blockquote><pre>auto concept AllLiteral&lt; typename ... Types &gt; {
-  requires LiteralType&lt;Types&gt;...;
-}
-</pre></blockquote>
+</blockquote>
 
 <p>
-ammend the constructor 
+For each of the following constructors,
+if <tt>uses_allocator&lt;container_type, Alloc&gt;::value</tt> is <tt>false</tt>,
+then the constructor shall not participate in overload resolution.
 </p>
 
-<blockquote><pre><ins>template &lt;class... UTypes&gt;
-  requires AllLiteral&lt;Types...&gt;
-        &amp;&amp; Constructible&lt;Types, UTypes&gt;...
-  explicit tuple(UTypes...);</ins>
+<pre>template &lt;class Alloc&gt;
+  explicit priority_queue(const Alloc&amp; a);
+</pre>
 
-template &lt;class... UTypes&gt;
-  requires <ins>!AllLiteral&lt;Types...&gt;</ins>
-        <ins>&amp;&amp;</ins> Constructible&lt;Types, UTypes&amp;&amp;&gt;...
-  explicit tuple(UTypes&amp;&amp;...);
-</pre></blockquote>
+<blockquote>
 
 <p>
-ammend the constructor
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>a</tt> and value-initializes <tt>comp</tt>.
 </p>
 
-<blockquote><pre><ins>template &lt;class... UTypes&gt;
-  requires AllLiteral&lt;Types...&gt;
-        &amp;&amp; Constructible&lt;Types, UTypes&gt;...
-  tuple(tuple&lt;UTypes...&gt;);</ins>
+</blockquote>
 
-template &lt;class... UTypes&gt;
-  requires <ins>!AllLiteral&lt;Types...&gt;</ins>
-        <ins>&amp;&amp;</ins> Constructible&lt;Types, const UTypes&amp;&gt;...
-  tuple(const tuple&lt;UTypes...&gt;&amp;);
-</pre></blockquote>
+<pre>template &lt;class Alloc&gt;
+  priority_queue(const Compare&amp; compare, const Alloc&amp; a);
+</pre>
 
-</blockquote>
+<blockquote>
 
 <p>
-Update the same signatures in 20.5.2.1 [tuple.cnstr], paras 3 and 5.
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>a</tt> and initializes <tt>comp</tt>
+with <tt>compare</tt>.
 </p>
 
+</blockquote>
 
+<pre>template &lt;class Alloc&gt;
+  priority_queue(const Compare&amp; compare, const Container&amp; cont, const Alloc&amp; a);
+</pre>
 
+<blockquote>
 
-
-<hr>
-<h3><a name="1117"></a>1117. tuple copy constructor</h3>
-<p><b>Section:</b> 20.5.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-05-30</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-The copy constructor for the <tt>tuple</tt> template is constrained.  This seems an
-unusual strategy, as the copy constructor will be implicitly deleted if the
-constraints are not met.  This is exactly the same effect as requesting an
-<tt>=default;</tt> constructor.  The advantage of the latter is that it retains
-triviality, and provides support for <tt>tuple</tt>s as literal types if issue
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1116">1116</a> is also accepted.
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>cont</tt> as the first argument
+and <tt>a</tt> as the second argument,
+and initializes <tt>comp</tt> with <tt>compare</tt>.
 </p>
+
+</blockquote>
+
+<pre>template &lt;class Alloc&gt;
+  priority_queue(const Compare&amp; compare, Container&amp;&amp; cont, const Alloc&amp; a);
+</pre>
+
+<blockquote>
+
 <p>
-Actually, it might be worth checking with core if a constrained copy
-constructor is treated as a constructor template, and as such does not
-suppress the implicit generation of the copy constructor which would hide
-the template in this case.
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(cont)</tt> as 
+the first argument and <tt>a</tt> as the second argument,
+and initializes <tt>comp</tt> with <tt>compare</tt>.
 </p>
 
-<p><i>[
-2009-05-27 Daniel adds:
-]</i></p>
+</blockquote>
 
+<pre>template &lt;class Alloc&gt;
+  priority_queue(priority_queue&amp;&amp; q, const Alloc&amp; a);
+</pre>
 
 <blockquote>
-This would solve one half of the suggested changes in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>.
+
+<p>
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(q.c)</tt> as the
+first argument and <tt>a</tt> as the second argument, 
+and initializes <tt>comp</tt> with <tt>std::move(q.comp)</tt>.
+</p>
+
 </blockquote>
 
+<pre>priority_queue&amp; operator=(priority_queue&amp;&amp; q);
+</pre>
+
+<blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 20.5.2 [tuple.tuple] and 20.5.2.1 [tuple.cnstr] p4:
+<i>Effects:</i> Assigns <tt>c</tt> with <tt>std::move(q.c)</tt> and
+assigns <tt>comp</tt> with <tt>std::move(q.comp)</tt>.
 </p>
 
-<blockquote><pre><del>requires CopyConstructible&lt;Types&gt;...</del> tuple(const tuple&amp;)<ins> = default</ins>;
-</pre></blockquote>
+<p>
+<i>Returns:</i> <tt>*this</tt>.
+</p>
 
+</blockquote>
+
+</blockquote>
 
 
 
 
-<hr>
-<h3><a name="1118"></a>1118. tuple query APIs do not support cv-qualification</h3>
-<p><b>Section:</b> 20.5.2.3 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-05-25</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.helper">active issues</a> in [tuple.helper].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</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.
+Change 23.3.5.3.1 [stack.defn]:
 </p>
+
+<blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt;
+class stack {
+public:
+  typedef typename Container::value_type      value_type;
+  typedef typename Container::reference       reference;
+  typedef typename Container::const_reference const_reference;
+  typedef typename Container::size_type       size_type;
+  typedef Container                           container_type;
+protected:
+  Container c;
+
+public:
+  explicit stack(const Container&amp;);
+  explicit stack(Container&amp;&amp; = Container());
+  <ins>stack(stack&amp;&amp; s);</ins>
+  template &lt;class Alloc&gt; explicit stack(const Alloc&amp;);
+  template &lt;class Alloc&gt; stack(const Container&amp;, const Alloc&amp;);
+  template &lt;class Alloc&gt; stack(Container&amp;&amp;, const Alloc&amp;);
+  template &lt;class Alloc&gt; stack(stack&amp;&amp;, const Alloc&amp;);
+  <ins>stack&amp; operator=(stack&amp;&amp; s);</ins>
+
+  bool empty() const          { return c.empty(); }
+  ...
+};
+</pre></blockquote>
+
 <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.
+Add a new section after 23.3.5.3.1 [stack.defn], [stack.cons]:
 </p>
 
-<p><i>[
-2009-05-24 Daniel adds:
-]</i></p>
+<blockquote>
+<p><b><tt>stack</tt> constructors [stack.cons]</b></p>
 
+<pre>stack(stack&amp;&amp; s);
+</pre>
 
 <blockquote>
+
 <p>
-All <tt>tuple_size</tt> templates with a base class need to derive publicly, e.g.
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(s.c)</tt>.
 </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>
+</blockquote>
 
 <p>
-The same applies to the tuple_element class hierarchies.
+For each of the following constructors,
+if <tt>uses_allocator&lt;container_type, Alloc&gt;::value</tt> is <tt>false</tt>,
+then the constructor shall not participate in overload resolution.
 </p>
+
+<pre>template &lt;class Alloc&gt; 
+  explicit stack(const Alloc&amp; a);
+</pre>
+
+<blockquote>
+
 <p>
-What is actually meant with the comment
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>a</tt>.
 </p>
-<blockquote>
-this solution relies on 'metafunction forwarding' to inherit the
-nested typename type
+
 </blockquote>
+
+<pre>template &lt;class Alloc&gt; 
+  stack(const container_type&amp; cont, const Alloc&amp; a);
+</pre>
+
+<blockquote>
+
 <p>
-?
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>cont</tt> as the
+first argument and <tt>a</tt> as the second argument.
 </p>
+
+</blockquote>
+
+<pre>template &lt;class Alloc&gt; 
+  stack(container_type&amp;&amp; cont, const Alloc&amp; a);
+</pre>
+
+<blockquote>
+
 <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.
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(cont)</tt> as the
+first argument and <tt>a</tt> as the second argument.
 </p>
-</blockquote>
 
-<p><i>[
-2009-05-24 Alisdair adds:
-]</i></p>
+</blockquote>
 
+<pre>template &lt;class Alloc&gt; 
+  stack(stack&amp;&amp; s, const Alloc&amp; a);
+</pre>
 
 <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.
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(s.c)</tt> as the
+first argument and <tt>a</tt> as the second argument.
 </p>
+
+</blockquote>
+
+<pre>stack&amp; operator=(stack&amp;&amp; s);
+</pre>
+
+<blockquote>
+
 <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.
+<i>Effects:</i> Assigns <tt>c</tt> with <tt>std::move(s.c)</tt>.
 </p>
+
 <p>
-The constrained template with an unconstrained base is a good observation
-though.
+<i>Returns:</i> <tt>*this</tt>.
 </p>
+
+</blockquote>
+
 </blockquote>
 
 
 
-<p><b>Proposed resolution:</b></p>
+
+
+
+<hr>
+<h3><a name="1197"></a>1197. Can unordered containers have <tt>bucket_count() == 0</tt>?</h3>
+<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-08-24  <b>Last modified:</b> 2009-09-03</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Add to 20.5.1 [tuple.general] p2 (Header <tt>&lt;tuple&gt;</tt> synopsis)
+Table 97 "Unordered associative container requirements" in
+23.2.5 [unord.req] says:
 </p>
 
-<blockquote><pre>// 20.5.2.3, tuple helper classes:
-template &lt;IdentityOf T&gt; class tuple_size; // undefined
-<ins>template &lt;IdentityOf T&gt; class tuple_size&lt; const T &gt; : tuple_size&lt;T&gt; {};</ins>
-<ins>template &lt;IdentityOf T&gt; class tuple_size&lt; volatile T &gt; : tuple_size&lt;T&gt; {};</ins>
-<ins>template &lt;IdentityOf T&gt; class tuple_size&lt; const volatile T &gt; : tuple_size&lt;T&gt; {};</ins>
+<blockquote>
+<table border="1">
+<caption>Table 97 &#8212; Unordered associative container requirements
+(in addition to container)</caption>
 
-template &lt;VariableType... Types&gt; class tuple_size&lt;tuple&lt;Types...&gt; &gt;;
+<tbody><tr>
+<th>Expression</th>
+<th>Return type</th>
+<th>Assertion/note pre-/post-condition</th>
+<th>Complexity</th>
+</tr>
 
-template &lt;size_t I, IdentityOf T&gt; class tuple_element; // undefined
-<ins>template &lt;size_t I, IdentityOf T&gt; class tuple_element&lt;I, const T&gt;;</ins>
-<ins>template &lt;size_t I, IdentityOf T&gt; class tuple_element&lt;I, volatile T&gt;;</ins>
-<ins>template &lt;size_t I, IdentityOf T&gt; class tuple_element&lt;I, const volatile T&gt;;</ins>
+<tr>
+<td><tt>b.bucket(k)</tt></td>
+<td><tt>size_type</tt></td>
+<td>Returns the index of the bucket in which elements with keys 
+equivalent to <tt>k</tt> would be found, 
+if any such element existed. 
+Post: the return value shall be 
+in the range <tt>[0, 
+b.bucket_count())</tt>.</td>
+<td>Constant</td>
+</tr>
 
-template &lt;size_t I, VariableType... Types&gt;
-  requires True&lt;(I &lt; sizeof...(Types))&gt; class tuple_element&lt;I, tuple&lt;Types...&gt; &gt;;
-</pre></blockquote>
+</tbody></table>
+</blockquote>
 
 <p>
-Add to 20.5.2.3 [tuple.helper]
+What should <tt>b.bucket(k)</tt> return if <tt>b.bucket_count() == 0</tt>?
 </p>
-<p><i>[
-(note that this solution relies on 'metafunction forwarding' to inherit the
-nested typename type)
-]</i></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;
-requires True&lt;(I &lt; sizeof...(Types))&gt;
-class tuple_element&lt;I, tuple&lt;Types...&gt; &gt; {
-public:
-  typedef TI type;
-};
+<p>
+I believe allowing <tt>b.bucket_count() == 0</tt> is important.  It is a
+very reasonable post-condition of the default constructor, or of a moved-from
+container.
+</p>
 
-<ins>template &lt;size_t I, IdentityOf T&gt;
-  class tuple_element&lt;I, const T&gt; : add_const&lt;tuple_element&lt;I,T&gt;&gt; {};</ins>
+<p>
+I can think of several reasonable results from <tt>b.bucket(k)</tt> when
+<tt>b.bucket_count() == 0</tt>:
+</p>
 
-<ins>template &lt;size_t I, IdentityOf T&gt;
-  class tuple_element&lt;I, volatile T&gt; : add_volatile&lt;tuple_element&lt;I,T&gt;&gt; {};</ins>
+<ol>
+<li>
+Return 0.
+</li>
+<li>
+Return <tt>numeric_limits&lt;size_type&gt;::max()</tt>.
+</li>
+<li>
+Throw a <tt>domain_error</tt>.
+</li>
+<li>
+Precondition: <tt>b.bucket_count() != 0</tt>.
+</li>
+</ol>
 
-<ins>template &lt;size_t I, IdentityOf T&gt;
-  class tuple_element&lt;I, const volatile T&gt; : add_cv&lt;tuple_element&lt;I,T&gt;&gt; {};</ins>
-</pre></blockquote>
+<p><i>[
+2009-08-26 Daniel adds:
+]</i></p>
 
 
+<blockquote>
+<p>
+A forth choice would be to add the pre-condition "<tt>b.bucket_count() != 0</tt>"
+and thus imply undefined behavior if this is violated.
+</p>
 
+<p><i>[
+Howard:  I like this option too, added to the list.
+]</i></p>
 
 
-<hr>
-<h3><a name="1119"></a>1119. tuple query APIs do not support references</h3>
-<p><b>Section:</b> 20.5.2.3 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-05-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.helper">active issues</a> in [tuple.helper].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-The <tt>tuple</tt> query APIs <tt>tuple_size</tt> and
-<tt>tuple_element</tt> do not support references-to-tuples.  This can be
-annoying when a template deduced a parameter type to be a reference,
-which must be explicitly stripped with <tt>remove_reference</tt> before calling
-these APIs.
+Further on here my own favorite solution (rationale see below):
 </p>
+
+<p><b>Suggested resolution:</b></p>
+
 <p>
-I am not proposing a resolution at this point, as there is a
-combinatorial explosion with lvalue/rvalue references and
-cv-qualification (see previous issue) that suggests some higher
-refactoring is in order.  This might be something to kick back over to
-Core/Evolution.
+[Rationale: I suggest to follow choice (1). The main reason is
+that all associative container functions which take a key argument,
+are basically free of pre-conditions and non-disrupting, therefore
+excluding choices (3) and (4). Option (2) seems a bit unexpected
+to me. It would be more natural, if several similar functions
+would exist which would also justify the existence of a symbolic
+constant like npos for this situation. The value 0 is both simple
+and consistent, it has exactly the same role as a past-the-end
+iterator value. A typical use-case is:
 </p>
+
+<blockquote><pre>size_type pos = m.bucket(key);
+if (pos != m.bucket_count()) {
+ ...
+} else {
+ ...
+}
+</pre></blockquote>
+
+<p>&#8212; end Rationale]</p>
+
 <p>
-Note that we have the same problem in numeric_limits.
+- Change Table 97 in 23.2.5 [unord.req] as follows (Row b.bucket(k), Column "Assertion/..."):
 </p>
 
+<blockquote>
+<table border="1">
+<caption>Table 97 &#8212; Unordered associative container requirements
+(in addition to container)</caption>
 
-<p><b>Proposed resolution:</b></p>
-
+<tbody><tr>
+<th>Expression</th>
+<th>Return type</th>
+<th>Assertion/note pre-/post-condition</th>
+<th>Complexity</th>
+</tr>
 
+<tr>
+<td><tt>b.bucket(k)</tt></td>
+<td><tt>size_type</tt></td>
+<td>Returns the index of the bucket in which elements with keys 
+equivalent to <tt>k</tt> would be found, 
+if any such element existed. 
+Post: <ins>if b.bucket_count() != 0, </ins>the return value shall be 
+in the range <tt>[0, 
+b.bucket_count())</tt><ins>, otherwise 0</ins>.</td>
+<td>Constant</td>
+</tr>
 
+</tbody></table>
+</blockquote>
 
+</blockquote>
 
-<hr>
-<h3><a name="1120"></a>1120. New type trait - remove_all</h3>
-<p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-05-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Sometimes it is necessary to remove all qualifiers from a type before
-passing on to a further API.  A good example would be calling the
-<tt>tuple</tt> query APIs <tt>tuple_size</tt> or <tt>tuple_element</tt>
-with a deduced type inside a function template.  If the deduced type is
-cv-qualified or a reference then the call will fail.  The solution is to
-chain calls to
-<tt>remove_cv&lt;remove_reference&lt;T&gt;::type&gt;::type</tt>, and
-note that the order matters.
-</p>
-<p>
-Suggest it would be helpful to add a new type trait,
-<tt>remove_all</tt>, that removes all top-level qualifiers from a type
-i.e. cv-qualification and any references.  Define the term in such a way
-that if additional qualifiers are added to the language, then
-<tt>remove_all</tt> is defined as stripping those as well.
-</p>
 
 
 <p><b>Proposed resolution:</b></p>
+<p>
+</p>
 
 
 
 
 
 <hr>
-<h3><a name="1121"></a>1121. Support for multiple arguments</h3>
-<p><b>Section:</b> 20.4.2 [ratio.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-25  <b>Last modified:</b> 2009-05-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.arithmetic">issues</a> in [ratio.arithmetic].</p>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-08-26  <b>Last modified:</b> 2009-09-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.adaptors">active issues</a> in [container.adaptors].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.adaptors">issues</a> in [container.adaptors].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Both add and multiply could sensibly be called with more than two arguments.
-The variadic template facility makes such declarations simple, and is likely
-to be frequently wrapped by end users if we do not supply the variant
-ourselves.
+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>
-We deliberately ignore divide at this point as it is not transitive.
-Likewise, subtract places special meaning on the first argument so I do not
-suggest extending that immediately.  Both could be supported with analogous
-wording to that for add/multiply below.
+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>
-Note that the proposed resolution is potentially incompatible with that
-proposed for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, although the addition of the typedef to ratio would be
-equally useful.
+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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a> both in style and in content (e.g. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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><b>Proposed resolution:</b></p>
 <p><i>[
-note that this wording relies on 'metafunction forwarding' as described by
-Boost MPL
+Changes written with respect to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>.
 ]</i></p>
 
 
 <p>
-20.4 [ratio] p3 synopsis: change
+Change 23.3.5.1.1 [queue.defn]:
 </p>
 
-<blockquote><pre>// ratio arithmetic
-template &lt;class R1, class R2<ins>, class ... RList</ins>&gt; struct ratio_add;
-template &lt;class R1, class R2&gt; struct ratio_subtract;
-template &lt;class R1, class R2<ins>, class ... RList</ins>&gt; struct ratio_multiply;
-template &lt;class R1, class R2&gt; struct ratio_divide;
+<blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt; 
+class queue {
+   ...
+   void swap(queue&amp;<del>&amp;</del> q) { <ins>using std::swap;</ins>
+                          <del>c.</del>swap(<ins>c, </ins>q.c); }
+   ...
+};
 </pre></blockquote>
 
 <p>
-20.4.2 [ratio.arithmetic] p1: change
+Change 23.3.5.2 [priority.queue]:
 </p>
 
-<blockquote><pre><ins>template &lt;class R1, class R2, class ... RList&gt; struct ratio_add
-  : ratio_add&lt; R1, ratio_add&lt;R2, RList...&gt;&gt; {
-};</ins>
-
-template &lt;class R1, class R2&gt; struct ratio_add<ins>&lt;R1, R2&gt;</ins> {
-  typedef <i>see below</i> type;
+<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;<del>&amp;</del> <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>
-20.4.2 [ratio.arithmetic] p3: change
+Change 23.3.5.3.1 [stack.defn]:
 </p>
 
-<blockquote><pre><ins>template &lt;class R1, class R2, class ... RList&gt; struct ratio_multiply
-  : ratio_multiply&lt; R1, ratio_ multiply &lt;R2, RList...&gt;&gt; {
-};</ins>
-
-template &lt;class R1, class R2&gt; struct ratio_ multiply<ins>&lt;R1, R2&gt;</ins> {
-  typedef <i>see below</i> type;
+<blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt; 
+class stack {
+   ...
+   void swap(stack&amp;<del>&amp;</del> s) { <ins>using std::swap;</ins>
+                          <del>c.</del>swap(<ins>c, </ins>s.c); }
+   ...
 };
 </pre></blockquote>
 
@@ -28116,221 +23829,198 @@ template &lt;class R1, class R2&gt; struct ratio_ multiply<ins>&lt;R1, R2&gt;</i
 
 
 <hr>
-<h3><a name="1122"></a>1122. Ratio values should be constexpr</h3>
-<p><b>Section:</b> 20.4.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-25  <b>Last modified:</b> 2009-05-25</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ratio.ratio">active issues</a> in [ratio.ratio].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.ratio">issues</a> in [ratio.ratio].</p>
+<h3><a name="1199"></a>1199. Missing extended copy constructor in container adaptors</h3>
+<p><b>Section:</b> 23.3.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-08-26  <b>Last modified:</b> 2009-08-31</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.adaptors">active issues</a> in [container.adaptors].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.adaptors">issues</a> in [container.adaptors].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The values <tt>num</tt> and <tt>den</tt> in the <tt>ratio</tt> template
-should be declared <tt>constexpr</tt>.
+<tt>queue</tt> has a constructor:
 </p>
 
+<blockquote><pre>template &lt;class Alloc&gt;
+  queue(queue&amp;&amp;, const Alloc&amp;);
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-20.4.1 [ratio.ratio]
+but it is missing a corresponding constructor:
 </p>
 
-<blockquote><pre>namespace std {
-  template &lt;intmax_t N, intmax_t D = 1&gt;
-  class ratio {
-  public:
-    static const<ins>expr</ins> intmax_t num;
-    static const<ins>expr</ins> intmax_t den;
-  };
-}
+<blockquote><pre>template &lt;class Alloc&gt;
+  queue(const queue&amp;, const Alloc&amp;);
 </pre></blockquote>
 
-
-
-
-
-
-<hr>
-<h3><a name="1123"></a>1123. no requirement that standard streams be flushed</h3>
-<p><b>Section:</b> 27.5.2.1.6 [ios::Init] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> James Kanze <b>Opened:</b> 2009-05-14  <b>Last modified:</b> 2009-05-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::Init">issues</a> in [ios::Init].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-As currently formulated, the standard doesn't require that there 
-is ever a flush of <tt>cout</tt>, etc.  (This implies, for example, that 
-the classical hello, world program may have no output.)  In the 
-current draft
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>),
-there is a requirement that the objects 
-be constructed before <tt>main</tt>, and before the dynamic 
-initialization of any non-local objects defined after the 
-inclusion of <tt>&lt;iostream&gt;</tt> in the same translation unit.  The only 
-requirement that I can find concerning flushing, however, is in 
-27.5.2.1.6 [ios::Init], where the destructor of the last 
-<tt>std::ios_base::Init</tt> object flushes.  But there is, as far as I 
-can see, no guarantee that such an object ever exists. 
-</p>
-<p>
-Also, the wording in  [iostreams.objects] says that:
-</p>
-<blockquote>
-The objects 
-are constructed and the associations are established at some 
-time prior to or during the first time an object of class 
-<tt>ios_base::Init</tt> is constructed, and in any case before the body 
-of main begins execution.
-</blockquote>
-<p>
-In 27.5.2.1.6 [ios::Init], however, as an 
-effect of the constructor, it says that
-</p>
-<blockquote>
-If <tt>init_cnt</tt> is zero, 
-the function stores the value one in <tt>init_cnt</tt>, then constructs 
-and initializes the objects <tt>cin</tt>, <tt>cout</tt>, <tt>cerr</tt>, <tt>clog</tt> 
-<tt>wcin</tt>, <tt>wcout</tt>, <tt>wcerr</tt>, and <tt>wclog</tt>"
-</blockquote>
-
 <p>
-which seems to forbid earlier 
-construction. 
+The same is true of <tt>priority_queue</tt>, and <tt>stack</tt>.  This
+"extended copy constructor" is needed for consistency and to ensure that the
+user of a container adaptor can always specify the allocator for his adaptor.
 </p>
 
-<p>
-(Note that with these changes, the exposition only "<tt>static 
-int init_cnt</tt>" in <tt>ios_base::Init</tt> can be dropped.) 
-</p>
-<p>
-Of course, a determined programmer can still inhibit the 
-flush with things like: 
-</p>
-<blockquote><pre>new std::ios_base::Init ;       //  never deleted 
-</pre></blockquote>
-<p>
-or (in a function): 
-</p>
-<blockquote><pre>std::ios_base::Init ensureConstruction ; 
-//  ... 
-exit( EXIT_SUCCESS ) ; 
-</pre></blockquote>
-<p>
-Perhaps some words somewhere to the effect that all 
-<tt>std::ios_base::Init</tt> objects should have static lifetime 
-would be in order. 
-</p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>
-Change 27.4 [iostream.objects]/2:
-</p>
+<p><i>[
+This resolution has been harmonized with the proposed resolution to issue
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1194">1194</a>
+]</i></p>
 
-<blockquote>
--2- The objects are constructed and the associations are established at
-some time prior to or during the first time an object of class
-<tt>ios_base::Init</tt> is constructed, and in any case before the body
-of main begins execution.<sup>292</sup> The objects are not destroyed
-during program execution.<sup>293</sup>
-<del>If a translation unit includes
-<tt>&lt;iostream&gt;</tt> or explicitly constructs an
-<tt>ios_base::Init</tt> object, these stream objects shall be
-constructed before dynamic initialization of non-local objects defined
-later in that translation unit.</del>
-<ins>The results of including <tt>&lt;iostream&gt;</tt> in a translation
-unit shall be as if <tt>&lt;iostream&gt;</tt> defined an instance of
-<tt>ios_base::Init</tt> with static lifetime. Similarly, the entire
-program shall behave as if there were at least one instance of
-<tt>ios_base::Init</tt> with static lifetime.</ins>
-</blockquote>
 
-<p>
-Change 27.5.2.1.6 [ios::Init]/3:
-</p>
+<p>Change 23.3.5.1.1 [queue.defn], p1:</p>
 
-<blockquote>
-<pre>Init();
-</pre>
-<blockquote>
--3- <i>Effects:</i> Constructs an object of class <tt>Init</tt>. 
-<del>If <tt>init_cnt</tt> is zero, the function stores the value one in
-<tt>init_cnt</tt>, then constructs and initializes the objects
-<tt>cin</tt>, <tt>cout</tt>, <tt>cerr</tt>, <tt>clog</tt> (27.4.1),
-<tt>wcin</tt>, <tt>wcout</tt>, <tt>wcerr</tt>, and <tt>wclog</tt>
-(27.4.2). In any case, the function then adds one to the value stored in
-<tt>init_cnt</tt>.</del>
-<ins>Constructs and initializes the objects <tt>cin</tt>, <tt>cout</tt>,
-<tt>cerr</tt>, <tt>clog</tt>, <tt>wcin</tt>, <tt>wcout</tt>,
-<tt>wcerr</tt> and <tt>wclog</tt> if they have not already been
-constructed and initialized.</ins>
-</blockquote>
-</blockquote>
+<blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt;
+class queue {
+public:
+  typedef typename Container::value_type      value_type;
+  typedef typename Container::reference       reference;
+  typedef typename Container::const_reference const_reference;
+  typedef typename Container::size_type       size_type;
+  typedef Container                           container_type;
+protected:
+  Container c;
+
+public:
+  explicit queue(const Container&amp;);
+  explicit queue(Container&amp;&amp; = Container());
+  queue(queue&amp;&amp; q);
+
+  template &lt;class Alloc&gt; explicit queue(const Alloc&amp;);
+  template &lt;class Alloc&gt; queue(const Container&amp;, const Alloc&amp;);
+  template &lt;class Alloc&gt; queue(Container&amp;&amp;, const Alloc&amp;);
+  <ins>template &lt;class Alloc&gt; queue(const queue&amp;, const Alloc&amp;);</ins>
+  template &lt;class Alloc&gt; queue(queue&amp;&amp;, const Alloc&amp;);
+  queue&amp; operator=(queue&amp;&amp; q);
+
+  bool empty() const          { return c.empty(); }
+  ...
+};
+</pre></blockquote>
 
 <p>
-Change 27.5.2.1.6 [ios::Init]/4:
+To the new section  [queue.cons], introduced
+in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1194">1194</a>, add:
 </p>
 
 <blockquote>
-<pre>~Init();
+
+<pre>template &lt;class Alloc&gt; 
+  queue(const queue&amp; q, const Alloc&amp; a);
 </pre>
-<blockquote>
--4- <i>Effects:</i> Destroys an object of class <tt>Init</tt>.
-<del>The function subtracts one from the value stored in <tt>init_cnt</tt> and,
-if the resulting stored value is one,</del>
-<ins>If there are no other instances of the class still in
-existance,</ins>
-calls <tt>cout.flush()</tt>,
-<tt>cerr.flush()</tt>, <tt>clog.flush()</tt>, <tt>wcout.flush()</tt>,
-<tt>wcerr.flush()</tt>, <tt>wclog.flush()</tt>.
-</blockquote>
-</blockquote>
 
+<blockquote><p>
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>q.c</tt> as the
+first argument and <tt>a</tt> as the second argument.
+</p></blockquote>
 
+</blockquote>
 
+<p>Change 23.3.5.2 [priority.queue] as follows (I've an included an editorial change to
+  move the poorly-placed move-assignment operator):</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 {
+public:
+  typedef typename Container::value_type      value_type;
+  typedef typename Container::reference       reference;
+  typedef typename Container::const_reference const_reference;
+  typedef typename Container::size_type       size_type;
+  typedef          Container                  container_type;
+protected:
+  Container c;
+  Compare comp;
 
+public:
+  priority_queue(const Compare&amp; x, const Container&amp;);
+  explicit priority_queue(const Compare&amp; x = Compare(), Container&amp;&amp; = Container());
+  template &lt;class InputIterator&gt;
+    priority_queue(InputIterator first, InputIterator last,
+                   const Compare&amp; x, const Container&amp;);
+  template &lt;class InputIterator&gt;
+    priority_queue(InputIterator first, InputIterator last,
+                   const Compare&amp; x = Compare(), Container&amp;&amp; = Container());
+  priority_queue(priority_queue&amp;&amp;);
+  <del>priority_queue&amp; operator=(priority_queue&amp;&amp;);</del>
+  template &lt;class Alloc&gt; explicit priority_queue(const Alloc&amp;);
+  template &lt;class Alloc&gt; priority_queue(const Compare&amp;, const Alloc&amp;);
+  template &lt;class Alloc&gt; priority_queue(const Compare&amp;,
+                                        const Container&amp;, const Alloc&amp;);
+  template &lt;class Alloc&gt; priority_queue(const Compare&amp;,
+                                        Container&amp;&amp;, const Alloc&amp;);
+  <ins>template &lt;class Alloc&gt; priority_queue(const priority_queue&amp;, const Alloc&amp;);</ins>
+  template &lt;class Alloc&gt; priority_queue(priority_queue&amp;&amp;, const Alloc&amp;);
+
+  <ins>priority_queue&amp; operator=(priority_queue&amp;&amp;);</ins>
+  ...
+};
+</pre></blockquote>
 
-<hr>
-<h3><a name="1125"></a>1125. ostream_iterator does not work with movable types</h3>
-<p><b>Section:</b> 24.6.2.2 [ostream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28  <b>Last modified:</b> 2009-05-30</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-<tt>ostream_iterator</tt> has not been updated to support moveable types, in a
-similar manner to the insert iterators.
-Note that this is not a problem for <tt>ostreambuf_iterator</tt>, as the types it is
-restricted to dealing with do not support extra-efficient moving.
+Add to 23.3.5.2.1 [priqueue.cons]:
 </p>
 
+<blockquote>
+
+<pre>template &lt;class Alloc&gt;
+  explicit priority_queue(const priority_queue&amp; q, const Alloc&amp; a);
+</pre>
+
+<blockquote><p>
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>q.c</tt> as the
+first argument and <tt>a</tt> as the second argument, 
+and initializes <tt>comp</tt> with <tt>q.comp</tt>.
+</p></blockquote>
+
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Add second <tt>operator=</tt> overload to class <tt>template ostream_iterator</tt>
-in 24.6.2 [ostream.iterator], para 2:
+Change 23.3.5.3.1 [stack.defn]:
 </p>
 
-<blockquote><pre>ostream_iterator&lt;T,charT,traits&gt;&amp; operator=(const T&amp; value);
-<ins>ostream_iterator&lt;T,charT,traits&gt;&amp; operator=(T&amp;&amp; value);</ins>
+<blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt;
+class stack {
+public:
+  typedef typename Container::value_type      value_type;
+  typedef typename Container::reference       reference;
+  typedef typename Container::const_reference const_reference;
+  typedef typename Container::size_type       size_type;
+  typedef Container                           container_type;
+protected:
+  Container c;
+
+public:
+  explicit stack(const Container&amp;);
+  explicit stack(Container&amp;&amp; = Container());
+  stack(stack&amp;&amp; s);
+
+  template &lt;class Alloc&gt; explicit stack(const Alloc&amp;);
+  template &lt;class Alloc&gt; stack(const Container&amp;, const Alloc&amp;);
+  template &lt;class Alloc&gt; stack(Container&amp;&amp;, const Alloc&amp;);
+  <ins>template &lt;class Alloc&gt; stack(const stack&amp;, const Alloc&amp;);</ins>
+  template &lt;class Alloc&gt; stack(stack&amp;&amp;, const Alloc&amp;);
+  stack&amp; operator=(stack&amp;&amp; s);
+
+  bool empty() const          { return c.empty(); }
+  ...
+};
 </pre></blockquote>
 
 <p>
-Add a new paragraph: in 24.6.2.2 [ostream.iterator.ops]:
+To the new section  [stack.cons], introduced
+in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1194">1194</a>, add:
 </p>
 
 <blockquote>
-<pre>ostream_iterator&amp; operator=(T&amp;&amp; value);
+
+<pre>template &lt;class Alloc&gt; 
+  stack(const stack&amp; s, const Alloc&amp; a);
 </pre>
-<blockquote>
-<p>
--2- <i>Effects:</i>
-</p>
-<blockquote><pre>*out_stream &lt;&lt; std::move(value);
-if(delim != 0)
-  *out_stream &lt;&lt; delim;
-return (*this);
-</pre></blockquote>
-</blockquote>
+
+<blockquote><p>
+<i>Effects:</i> Initializes <tt>c</tt> with <tt>s.c</tt> as the
+first argument and <tt>a</tt> as the second argument.
+</p></blockquote>
 </blockquote>
 
 
@@ -28339,1107 +24029,1170 @@ return (*this);
 
 
 <hr>
-<h3><a name="1126"></a>1126. <tt>istreambuff_iterator::equal</tt> needs a const &amp; parameter</h3>
-<p><b>Section:</b> 24.6.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28  <b>Last modified:</b> 2009-05-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator::equal">issues</a> in [istreambuf.iterator::equal].</p>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Sean Hunt <b>Opened:</b> 2009-09-03  <b>Last modified:</b> 2009-10-28</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.typedefs">issues</a> in [char.traits.typedefs].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The <tt>equal</tt> member function of <tt>istreambuf_iterator</tt> is
-declared <tt>const</tt>, but takes its argument by non-const reference.
+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 is not compatible with the <tt>operator==</tt> free function overload, which is
-defined in terms of calling <tt>equal</tt> yet takes both arguments by reference to
-const.
+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>[
-The proposed wording is consistent with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a> with status TC1.
+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 &#8212; <i>end
+note</i>]</ins>.
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Ammend in both:<br>
-24.6.3 [istreambuf.iterator]<br>
-24.6.3.5 [istreambuf.iterator::equal]<br>
+Replace 21.2.3.3 [char.traits.specializations.char32_t] para 3 with:
 </p>
 
-<blockquote><pre>bool equal(<ins>const </ins>istreambuf_iterator&amp; b) const;
-</pre></blockquote>
+<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 &#8212; <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 &#8212; <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>
 
-<hr>
-<h3><a name="1129"></a>1129. <tt>istream(buf)_iterator</tt> should support literal sentinel value</h3>
-<p><b>Section:</b> 24.6.1.1 [istream.iterator.cons], 24.6.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-30  <b>Last modified:</b> 2009-06-09</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-<tt>istream_iterator</tt> and <tt>istreambuf_iterator</tt> should support literal sentinel
-values.  The default constructor is frequently used to terminate ranges, and
-could easily be a literal value for <tt>istreambuf_iterator</tt>, and
-<tt>istream_iterator</tt> when iterating value types.  A little more work using a
-suitably sized/aligned char-array for storage (or an updated component like
-<tt>boost::optional</tt> proposed for TR2) would allow <tt>istream_iterator</tt> to support
-<tt>constexpr</tt> default constructor in all cases, although we might leave this
-tweak as a QoI issue.  Note that requiring <tt>constexpr</tt> be supported also
-allows us to place no-throw guarantees on this constructor too.
+Replace 21.2.3.3 [char.traits.specializations.char32_t] para 3 with:
 </p>
 
-<p><i>[
-2009-06-02 Daniel adds:
-]</i></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 &#8212; <i>end
+note</i>]</ins>.
+</blockquote>
+</li>
+</ol>
+</blockquote>
 
 
-<blockquote>
-<p>
-I agree with the usefulness of the issue suggestion, but we need
-to ensure that <tt>istream_iterator</tt> <em>can</em> satisfy be literal if needed.
-Currently this is not clear, because 24.6.1 [istream.iterator]/3 declares
-a copy constructor and a destructor and explains their semantic in
-24.6.1.1 [istream.iterator.cons]/3+4.
-</p>
+
+<p><b>Proposed resolution:</b></p>
 <p>
-The prototype semantic specification is ok (although it seems
-somewhat redundant to me, because the semantic doesn't say
-anything interesting in both cases), but for support of trivial class
-types we also need a trivial copy constructor and destructor as of
-9 [class]/6. The current non-informative specification of these
-two special members suggests to remove their explicit declaration
-in the class and add explicit wording that says that if <tt>T</tt> is
-trivial a default constructed iterator is also literal, alternatively it
-would be possible to mark both as defaulted and add explicit
-(memberwise) wording that guarantees that they are trivial.
 </p>
+
+
+
+
+
+<hr>
+<h3><a name="1201"></a>1201. Do we always want to unwrap <tt>ref</tt>-wrappers in <tt>make_tuple</tt></h3>
+<p><b>Section:</b> 20.5.2.4 [tuple.creation], 20.3.4 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">Tentatively NAD Future</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-09-05  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Future">Tentatively NAD Future</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Btw.: I'm quite sure that the <tt>istreambuf_iterator</tt> additions to
-ensure triviality are not sufficient as suggested, because the
-library does not yet give general guarantees that a defaulted
-special member declaration makes this member also trivial.
-Note that e.g. the atomic types do give a general statement!
+Spotting a recent thread on the boost lists regarding collapsing
+optional representations in <tt>optional&lt;optional&lt;T&gt;&gt;</tt> instances, I wonder if
+we have some of the same issues with <tt>make_tuple</tt>, and now <tt>make_pair</tt>?
 </p>
+
 <p>
-Finally there is a wording issue: There does not exist something
-like a "literal constructor". The core language uses the term
-"constexpr constructor" for this.
+Essentially, if my generic code in my own library is handed a
+<tt>reference_wrapper</tt> by a user, and my library in turn delegates some logic
+to <tt>make_pair</tt> or <tt>make_tuple</tt>, then I am going to end up with a <tt>pair</tt>/<tt>tuple</tt>
+holding a real reference rather than the intended reference wrapper.
 </p>
+
 <p>
-Suggestion:
+There are two things as a library author I can do at this point:
 </p>
-<ol>
+
+<ol type="i">
 <li>
-<p>
-Change 24.6.1 [istream.iterator]/3 as indicated:
-</p>
-<blockquote><pre><ins>constexpr</ins> istream_iterator();
-istream_iterator(istream_type&amp; s);
-istream_iterator(const istream_iterator<del>&lt;T,charT,traits,Distance&gt;</del>&amp; x)<ins> = default</ins>;
-~istream_iterator()<ins> = default</ins>;
-</pre></blockquote>
+document my library also has the same reference-wrapper behaviour as
+<tt>std::make_tuple</tt>
 </li>
 <li>
+roll my own <tt>make_tuple</tt> that does not unwrap rereferences, a lost
+opportunity to re-use the standard library.
+</li>
+</ol>
+
 <p>
-Change 24.6.1.1 [istream.iterator.cons]/1 as indicated:
+(There may be some metaprogramming approaches my library can use to wrap
+the <tt>make_tuple</tt> call, but all will be significantly more complex than
+simply implementing a simplified <tt>make_tuple</tt>.)
 </p>
-<blockquote><pre><ins>constexpr</ins> istream_iterator();
-</pre>
+
+<p>
+Now I don't propose we lose this library facility, I think unwrapping
+references will be the common behaviour.  However, we might want to
+consider adding another overload that does nothing special with
+<tt>ref</tt>-wrappers.  Note that we already have a second overload of <tt>make_tuple</tt>
+in the library, called <tt>tie</tt>.
+</p>
+
+<p><i>[
+2009-09-30 Daniel adds:
+]</i></p>
+
+
 <blockquote>
--1- <i>Effects:</i> Constructs the end-of-stream iterator. <ins>If <tt>T</tt> is a literal type,
-then this constructor shall be a constexpr constructor.</ins>
-</blockquote>
-</blockquote>
-</li>
-<li>
 <p>
-Change 24.6.1.1 [istream.iterator.cons]/3 as indicated:
+I suggest to change the currently proposed paragraph for
+<tt>make_simple_pair</tt>
 </p>
-<blockquote><pre>istream_iterator(const istream_iterator<del>&lt;T,charT,traits,Distance&gt;</del>&amp; x)<ins> = default</ins>;
+
+<blockquote><pre>template&lt;typename... Types&gt;
+  pair&lt;typename decay&lt;Types&gt;::type...&gt; make_simple_pair(Types&amp;&amp;... t);
 </pre>
 <blockquote>
--3- <i>Effects:</i> Constructs a copy of <tt>x</tt>. <ins>If <tt>T</tt> is a literal type, then
-this constructor shall be a trivial copy constructor.</ins>
+<p>
+<del><i>Type requirements:</i> <tt>sizeof...(Types) == 2</tt>.</del>
+<ins><i>Remarks:</i> The program shall be ill-formed, if
+<tt>sizeof...(Types) != 2</tt>.</ins>
+</p>
+<p>
+...
+</p>
 </blockquote>
 </blockquote>
-</li>
-<li>
+
 <p>
-Change 24.6.1.1 [istream.iterator.cons]/4 as indicated:
+or alternatively (but with a slightly different semantic):
 </p>
 
-<blockquote><pre>~istream_iterator()<ins> = default</ins>;
-</pre>
 <blockquote>
--4- <i>Effects:</i> The iterator is destroyed. <ins>If <tt>T</tt> is a literal type, then
-this destructor shall be a trivial
-destructor.</ins>
+<blockquote>
+<i>Remarks:</i> If <tt>sizeof...(Types) != 2</tt>, this function shall not
+participate in overload resolution.
 </blockquote>
 </blockquote>
-</li>
-<li>
+
 <p>
-Change 24.6.3 [istreambuf.iterator] before p. 1 as indicated:
+to follow a currently introduced style and because the library does
+not have yet a specific "<i>Type requirements</i>" element. If such thing
+would be considered as useful this should be done as a separate
+issue. Given the increasing complexity of either of these wordings
+it might be preferable to use the normal two-argument-declaration
+style again in either of the following ways:
 </p>
 
-<blockquote><pre><ins>constexpr</ins> istreambuf_iterator() throw();
-<ins>istreambuf_iterator(const istreambuf_iterator&amp;)  throw() = default;</ins>
-<ins>~istreambuf_iterator()  throw() = default;</ins>
-</pre></blockquote>
+<ol type="A">
+<li>
+<pre>template&lt;class T1, class T2&gt;
+pair&lt;typename decay&lt;T1&gt;::type, typename decay&lt;T2&gt;::type&gt;
+make_simple_pair(T1&amp;&amp; t1, T2&amp;&amp; t2);
+</pre>
 </li>
 <li>
-<p>
-Change 24.6.3 [istreambuf.iterator]/1 as indicated:
-</p>
+<pre>template&lt;class T1, class T2&gt;
+pair&lt;V1, V2&gt; make_simple_pair(T1&amp;&amp; t1, T2&amp;&amp; t2);
+</pre>
 <blockquote>
-[..] The default constructor <tt>istreambuf_iterator()</tt> and the constructor
-<tt>istreambuf_iterator(0)</tt> both
-construct an end of stream iterator object suitable for use as an
-end-of-range. <ins>All
-specializations of <tt>istreambuf_iterator</tt> shall have a trivial copy
-constructor, a constexpr default
-constructor and a trivial destructor.</ins>
+Let <tt>V1</tt> be <tt>typename decay&lt;T1&gt;::type</tt> and <tt>V2</tt> be
+<tt>typename decay&lt;T2&gt;::type</tt>.
 </blockquote>
 </li>
 </ol>
+
 </blockquote>
 
+<p><i>[
+2009-10 post-Santa Cruz:
+]</i></p>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-24.6.1 [istream.iterator] para 3
-</p>
 
-<blockquote><pre><ins>constexpr</ins> istream_iterator();
-</pre></blockquote>
+<blockquote>
+Mark as Tentatively NAD Future.
+</blockquote>
 
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-24.6.1.1 [istream.iterator.cons]
+Add the following function to 20.3.4 [pairs] and signature in
+appropriate synopses:
 </p>
 
-<blockquote><pre><ins>constexpr</ins> istream_iterator();
+<blockquote><pre>template&lt;typename... Types&gt;
+  pair&lt;typename decay&lt;Types&gt;::type...&gt; make_simple_pair(Types&amp;&amp;... t);
 </pre>
 <blockquote>
--1- <i>Effects:</i> Constructs the end-of-stream iterator.
-<ins>If <tt>T</tt> is a literal type, then this constructor shall
-be a literal constructor.</ins>
+<p>
+<i>Type requirements:</i> <tt>sizeof...(Types) == 2</tt>.
+</p>
+<p>
+<i>Returns:</i> <tt>pair&lt;typename decay&lt;Types&gt;::type...&gt;(std::forward&lt;Types&gt;(t)...)</tt>.
+</p>
 </blockquote>
 </blockquote>
 
+<p><i>[
+Draughting note: I chose a variadic representation similar to <tt>make_tuple</tt>
+rather than naming both types as it is easier to read through the
+clutter of metaprogramming this way.  Given there are exactly two
+elements, the committee may prefer to draught with two explicit template
+type parameters instead
+]</i></p>
+
+
 <p>
-24.6.3 [istreambuf.iterator]
+Add the following function to 20.5.2.4 [tuple.creation] and
+signature in appropriate synopses:
 </p>
 
-<blockquote><pre><ins>constexpr</ins> istreambuf_iterator() throw();
-</pre></blockquote>
-
+<blockquote><pre>template&lt;typename... Types&gt;
+  tuple&lt;typename decay&lt;Types&gt;::type...&gt; make_simple_tuple(Types&amp;&amp;... t);
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>tuple&lt;typename decay&lt;Types&gt;::type...&gt;(std::forward&lt;Types&gt;(t)...)</tt>.
+</p>
+</blockquote>
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="1130"></a>1130. <tt>copy_exception</tt> name misleading</h3>
-<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-05-13  <b>Last modified:</b> 2009-06-02</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
+<h3><a name="1202"></a>1202. <tt>integral_constant</tt> needs a spring clean</h3>
+<p><b>Section:</b> 20.6.3 [meta.help] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-09-05  <b>Last modified:</b> 2009-09-06</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.help">issues</a> in [meta.help].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The naming of <tt>std::copy_exception</tt> misleads almost everyone
-(experts included!) to think that it is the function that copies an
-<tt>exception_ptr</tt>:
+The specification of <tt>integral_constant</tt> has been inherited
+essentially unchanged from TR1:
 </p>
 
-<blockquote><pre>exception_ptr p1 = current_exception();
-exception_ptr p2 = copy_exception( p1 );
+<blockquote><pre>template &lt;class T, T v&gt;
+struct integral_constant {
+  static const T value = v;
+  typedef T value_type;
+  typedef integral_constant&lt;T,v&gt; type;
+};
 </pre></blockquote>
 
 <p>
-But this is not at all what it does. The above actually creates an
-<tt>exception_ptr p2</tt> that contains a copy of <tt>p1</tt>, not of
-the exception to which <tt>p1</tt> refers!
-</p>
-<p>
-This is, of course, all my fault; in my defence, I used <tt>copy_exception</tt>
-because I was unable to think of a better name.
-</p>
-<p>
-But I believe that, based on what we've seen so far, <em>any</em> other name would be better.
+In light of 0x language changes there are several things we might
+consider changing, notably the form of specification for value.
 </p>
+
 <p>
-Therefore, I propose <tt>copy_exception</tt> to be renamed to
-<tt>create_exception</tt>:
+The current form requires a static data member have storage allocated
+for it, where we could now implement without this using the new enum
+syntax:
 </p>
 
-<blockquote><pre>template&lt;class E&gt; exception_ptr create_exception(E e);
+<blockquote><pre>template &lt;class T, T v&gt;
+struct integral_constant {
+  <b>enum : T { value = v };</b>
+  typedef T value_type;
+  typedef integral_constant type;
+};
 </pre></blockquote>
 
 <p>
-with the following explanatory paragraph after it:
+The effective difference between these two implementation is:
 </p>
 
-<blockquote>
-Creates an <tt>exception_ptr</tt> that refers to a copy of <tt>e</tt>.
-</blockquote>
+<ol type="i">
+<li>
+No requirement to allocate storage for data member (which we hope but do
+not guarantee compilers strip today)
+</li>
 
-<p><i>[
-2009-05-13 Daniel adds:
-]</i></p>
+<li>
+You can no longer take the address of the constant as
+<tt>&amp;integral_constant&lt;T,v&gt;::value;</tt>
+</li>
+</ol>
 
+<p>
+Also note the editorial change to drop the explicit qualification of
+<tt>integral_constant</tt> in the <tt>typedef type</tt>.  This makes it quite clear we
+mean the current instantiation, and cannot be mistaken for a recursive
+metaprogram.
+</p>
 
-<blockquote>
 <p>
-What about
+Even if we don't mandate this implementation, it would be nice to give
+vendors freedom under QoI to choose their preferred representation.
 </p>
-<blockquote><pre>make_exception_ptr
-</pre></blockquote>
+
 <p>
-in similarity to <tt>make_pair</tt> and <tt>make_tuple</tt>, <tt>make_error_code</tt> and
-<tt>make_error_condition</tt>, or <tt>make_shared</tt>? Or, if a stronger symmetry to
-<tt>current_exception</tt> is preferred:
+The other side of this issue is if we choose to retain the static
+constant form.  In that case we should go further and insist on
+<tt>constexpr</tt>, much like we did throughout <tt>numeric_limits</tt>:
 </p>
 
-<blockquote><pre>make_exception
+<blockquote><pre>template &lt;class T, T v&gt;
+struct integral_constant {
+  static <b>constexpr</b> T value = v;
+  typedef T value_type;
+  typedef integral_constant type;
+};
 </pre></blockquote>
+
 <p>
-We have not a single <tt>create_*</tt> function in the library, it was always
-<tt>make_*</tt> used.
+[Footnote] It turns out <tt>constexpr</tt> is part of the Tentatively Ready
+resolution for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>.  I don't want to interfere with that issue, but
+would like a new issue to consider if the fixed-base enum implementation
+should be allowed.
 </p>
-</blockquote>
 
 <p><i>[
-2009-05-13 Peter adds:
+2009-09-05 Daniel adds:
 ]</i></p>
 
 
 <blockquote>
-<tt>make_exception_ptr</tt> works for me.
-</blockquote>
+<p>
+I think that the suggested resolution is incomplete and
+may have some possible unwanted side-effects. To understand
+why, note that <tt>integral_constant</tt> is <em>completely</em> specified
+by code in 20.6.3 [meta.help]. While this is usually considered
+as a good thing, let me give a possible user-defined
+specialization that would break given the suggested changes:
+</p>
 
-<p><i>[
-2009-06-02 Thomas J. Gritzan adds:
-]</i></p>
+<blockquote><pre>enum NodeColor { Red, Black };
 
+std::integral_constant&lt;NodeColor, Red&gt; red;
+</pre></blockquote>
 
-<blockquote>
 <p>
-To avoid surprises and unwanted recursion, how about making a call to
-<tt>std::make_exception_ptr</tt> with an <tt>exception_ptr</tt> illegal?
+The reason why that breaks is due to the fact that
+current core language rules does only allow integral
+types as enum-bases, see 7.2 [dcl.enum]/2.
 </p>
+
 <p>
-It might work like this:
+So, I think that we cannot leave the implementation the
+freedom to decide which way they would like to provide
+the implementation, because that is easily user-visible
+(I don't speak of addresses, but of instantiation errors),
+therefore if applied, this should be either specified or
+wording must be added that gives a note about this
+freedom of implementation.
 </p>
-<blockquote><pre>template&lt;class E&gt;
-exception_ptr make_exception_ptr(E e);
-template&lt;&gt;
-exception_ptr make_exception_ptr&lt;exception_ptr&gt;(exception_ptr e) = delete;
-</pre></blockquote>
-</blockquote>
-
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 18.8.5 [propagation]:
+Another possible disadvantage seems to me that user-expectations
+are easy to disappoint if they see a failure
+of the test
 </p>
 
-<blockquote>
-<pre>template&lt;class E&gt; exception_ptr <del>copy_exception</del><ins>make_exception_ptr</ins>(E e);
-</pre>
+<blockquote><pre>assert(typeid(std::integral_constant&lt;int, 0&gt;::value) == typeid(int));
+</pre></blockquote>
 
-<blockquote>
 <p>
--11- <i>Effects:</i> <ins>Creates an <tt>exception_ptr</tt> that refers
-to a copy of <tt>e</tt>,</ins> as if
+or of
 </p>
 
-<blockquote><pre>try {
-  throw e;
-} catch(...) {
-  return current_exception();
-}
+<blockquote><pre>static_assert(std::is_same&lt;decltype(std::integral_constant&lt;int, 0&gt;::value), const int&gt;::value, "Bad library");
 </pre></blockquote>
 
-<p>...</p>
 </blockquote>
 
-</blockquote>
 
 
+<p><b>Proposed resolution:</b></p>
+
 
 
 
 
 <hr>
-<h3><a name="1131"></a>1131. C++0x does not need <tt>alignment_of</tt></h3>
-<p><b>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2009-06-01  <b>Last modified:</b> 2009-06-02</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="1204"></a>1204. Global permission to move</h3>
+<p><b>Section:</b> 17.6.3.9 [res.on.arguments] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-09-12  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The <tt>alignment_of</tt> template is no longer necessary, now that the
-core language will provide <tt>alignof</tt>. Scott Meyers raised this
-issue at comp.std.c++,
-<a href="http://groups.google.com/group/comp.std.c++/browse_thread/thread/9b020306e803f08a">C++0x: alignof vs. alignment_of</a>,
-May 21, 2009.  In a reply, Daniel Krügler pointed out that
-<tt>alignof</tt> was added to the working paper <i>after</i>
-<tt>alignment_of</tt>. So it appears that <tt>alignment_of</tt> is only
-part of the current Working Draft 
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>)
-because it is in TR1.
+When a library function binds an rvalue reference parameter to an argument, the
+library must be able to assume that the bound argument is a temporary, and not
+a moved-from lvalue.  The reason for this is that the library function must be
+able to modify that argument without concern that such modifications will corrupt
+the logic of the calling code.  For example:
+</p>
+
+<blockquote><pre>template &lt;class T, class A&gt;
+void
+vector&lt;T, A&gt;::push_back(value_type&amp;&amp; v)
+{
+    <font color="#c80000">// This function should move from v, potentially modifying</font>
+    <font color="#c80000">//   the object v is bound to.</font>
+}
+</pre></blockquote>
+
+<p>
+If <tt>v</tt> is truly bound to a temporary, then <tt>push_back</tt> has the
+<em>only</em> reference to this temporary in the entire program.  Thus any
+modifications will be invisible to the rest of the program.
 </p>
+
 <p>
-Having both <tt>alignof</tt> and <tt>alignment_of</tt> would cause
-unwanted confusion. In general, I think TR1 functionality should not be
-brought into C++0x if it is entirely redundant with other C++0x language
-or library features.
+If the client supplies <tt>std::move(x)</tt> to <tt>push_back</tt>, the onus is
+on the client to ensure that the value of <tt>x</tt> is no longer important to
+the logic of his program after this statement.  I.e. the client is making a statement
+that <tt>push_back</tt> may treat <tt>x</tt> as a temporary.
 </p>
 
+<blockquote><em>
+The above statement is the very foundation upon which move semantics is based.
+</em></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Remove from Header &lt;type_traits&gt; synopsis 20.6.2 [meta.type.synop]:
+The standard is currently lacking a global statement to this effect.  I propose
+the following addition to 17.6.3.9 [res.on.arguments]:
 </p>
-<blockquote><pre><del>template &lt;class T&gt; struct alignment_of;</del>
-</pre></blockquote>
 
+<blockquote>
 <p>
-Remove the first row of Table 34 ("Type property queries"), from
-Type properties 20.6.4.3 [meta.unary.prop]:
+Each of the following statements applies to all arguments to functions
+defined in the C++ standard library, unless explicitly stated otherwise.
 </p>
+<ul>
+<li>
+If an argument to a function has an invalid value (such as a value
+outside the domain of the function, or a pointer invalid for its
+intended use), the behavior is undefined.
+</li>
+<li>
+If a function argument is described as being an array, the pointer
+actually passed to the function shall have a value such that all address
+computations and accesses to objects (that would be valid if the pointer
+did point to the first element of such an array) are in fact valid.
+</li>
+<li><ins>
+If a function argument binds to an rvalue reference parameter, the C++
+standard library may assume that this parameter is a unique reference
+to this argument.  If the parameter is a generic parameter of the
+form <tt>T&amp;&amp;</tt>, and an lvalue of type <tt>A</tt> is bound,
+then the binding is considered to be to an lvalue reference
+(14.9.2.1 [temp.deduct.call]) and thus not covered by this clause.
+[<i>Note:</i>
+If a program casts an lvalue to an rvalue while passing that lvalue to
+a library function (e.g. <tt>move(x)</tt>), then the program is effectively
+asking the library to treat that lvalue as a temporary.  The library is at
+liberty to optimize away aliasing checks which might be needed if the argument
+were an lvalue.
+&#8212; <i>end note</i>]
+</ins></li>
+</ul>
+
+</blockquote>
+
+<p>
+Such a global statement will eliminate the need for piecemeal statements such as
+23.2.1 [container.requirements.general]/13:
+</p>
+
 <blockquote>
-<table border="1">
-<caption>Table 34 -- Type property queries</caption>
-<tbody><tr>
-<td><del><tt>template &lt;class T&gt; struct alignment_of;</tt></del></td>
-<td><del><tt>alignof(T)</tt>.</del><br>
-<del><i>Precondition:</i> <tt>T</tt> shall be a complete type, a reference
-type, or an array of unknown bound, but shall not be a function type or
-(possibly cv-qualified) <tt>void</tt>.</del>
-</td>
-</tr>
-</tbody></table>
+An object bound to an rvalue reference parameter of a member function of
+a container shall not be an element of that container; no diagnostic
+required.
 </blockquote>
 
 <p>
-Change text in Table 41 ("Other transformations"), from Other
-transformations 20.6.7 [meta.trans.other], as follows:
+Additionally this clarifies that move assignment operators need not perform the
+traditional <tt>if (this != &amp;rhs)</tt> test commonly found (and needed) in
+copy assignment operators.
 </p>
+
+<p><i>[
+2009-09-13 Niels adds:
+]</i></p>
+
+
 <blockquote>
-<table border="1">
-<caption>Table 41 -- Other transformations</caption>
-<tbody><tr><td>...</td>
-<td>
- Align shall be equal to <tt>
- <del>alignment_of&lt;T&gt;::value</del>
- <ins>alignof(T)</ins>
- </tt> for some type <tt>T</tt> or to <i>default-alignment</i>.
-</td>
-<td>...</td>
-</tr></tbody></table>
+Note: This resolution supports the change of 27.9.1.3 [filebuf.assign]/1,
+proposed by LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>.
 </blockquote>
 
+<p><i>[
+2009 Santa Cruz:
+]</i></p>
 
 
+<blockquote>
+Move to Ready.
+</blockquote>
 
 
-<hr>
-<h3><a name="1132"></a>1132. JP-30: nested exceptions</h3>
-<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Seiji Hayashida <b>Opened:</b> 2009-06-01  <b>Last modified:</b> 2009-06-02</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p><b>Addresses JP 30</b></p>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-C++0x <tt>nested_exception</tt> cannot handle a structured exception well. The
-following codes show two types of tree structured exception handling.
-</p>
-<p>
-The first one is based on <tt>nested_exception</tt> in C++0x,
-while the second one is based on my library <tt>trickerr.h</tt> (in Japanese).
-<a href="http://tricklib.com/cxx/dagger/trickerr.h">http://tricklib.com/cxx/dagger/trickerr.h</a>
-</p>
-<p>
-Assume that Function <tt>A()</tt> calls two sub functions <tt>A_a()</tt> and <tt>A_b()</tt>, both might
-throw tree structured exceptions, and <tt>A_b()</tt> must be called even if <tt>A_a()</tt>
-throws an exception.
+Add a bullet to 17.6.3.9 [res.on.arguments]:
 </p>
+
+<blockquote>
 <p>
-List A (code of tree structured exception handling based on nested_exception
-in C++0x)
+Each of the following statements applies to all arguments to functions
+defined in the C++ standard library, unless explicitly stated otherwise.
 </p>
-
-<blockquote><pre>void A()
-{
-    try
-    {
-        std::vector&lt;exception_ptr&gt; exception_list;
-        try
-        {
-            // A_a() does a similar processing as A().
-            A_a();
-        }
-        catch(...)
-        {
-            exception_list.push_back(current_exception());
-        }
-
-        // ***The processing A() has to do even when A_a() fails. ***
-        try
-        {
-            // A_b() does a similar processing as A().
-            A_b();
-        }
-        catch(...)
-        {
-            exception_list.push_back(current_exception());
-        }
-        if (!exception_list.empty())
-        {
-            throw exception_list;
-        }
-    }
-    catch(...)
-    {
-        throw_with_nested(A_exception("someone error"));
-    }
-}
-void print_tree_exception(exception_ptr e, const std::string &amp; indent ="")
-{
-    const char * indent_unit = " ";
-    const char * mark = "- ";
-    try
-    {
-        rethow_exception(e);
-    }
-    catch(const std::vector&lt;exception_ptr&gt; e)
-    {
-        for(std::vector&lt;exception_ptr&gt;::const_iterator i = e.begin(); i!=e.end(); ++i)
-        {
-            print_tree_exception(i, indent);
-        }
-    }
-    catch(const std::nested_exception  e)
-    {
-        print_tree_exception(evil_i(e), indent +indent_unit);
-    }
-    catch(const std::exception e)
-    {
-        std::cout &lt;&lt; indent &lt;&lt; mark &lt;&lt; e.what() &lt;&lt; std::endl;
-    }
-    catch(...)
-    {
-        std::cout &lt;&lt; indent &lt;&lt; mark &lt;&lt; "unknown exception" &lt;&lt; std::endl;
-    }
-}
-int main(int, char * [])
-{
-    try
-    {
-        A();
-    }
-    catch()
-    {
-        print_tree_exception(current_exception());
-    }
-    return EXIT_SUCCESS;
-}
-</pre></blockquote>
+<ul>
+<li>
+If an argument to a function has an invalid value (such as a value
+outside the domain of the function, or a pointer invalid for its
+intended use), the behavior is undefined.
+</li>
+<li>
+If a function argument is described as being an array, the pointer
+actually passed to the function shall have a value such that all address
+computations and accesses to objects (that would be valid if the pointer
+did point to the first element of such an array) are in fact valid.
+</li>
+<li><ins>
+If a function argument binds to an rvalue reference parameter, the C++
+standard library may assume that this parameter is a unique reference
+to this argument.  If the parameter is a generic parameter of the
+form <tt>T&amp;&amp;</tt>, and an lvalue of type <tt>A</tt> is bound,
+then the binding is considered to be to an lvalue reference
+(14.9.2.1 [temp.deduct.call]) and thus not covered by this clause.
+[<i>Note:</i>
+If a program casts an lvalue to an rvalue while passing that lvalue to
+a library function (e.g. <tt>move(x)</tt>), then the program is effectively
+asking the library to treat that lvalue as a temporary.  The library is at
+liberty to optimize away aliasing checks which might be needed if the argument
+were an lvalue.
+&#8212; <i>end note</i>]
+</ins></li>
+</ul>
+</blockquote>
 
 <p>
-List B ( code of tree structured exception handling based on <tt>trickerr.h</tt>. )
-"trickerr.h" (in Japanese), refer to:
-<a href="http://tricklib.com/cxx/dagger/trickerr.h">http://tricklib.com/cxx/dagger/trickerr.h</a>.
+Delete 23.2.1 [container.requirements.general]/13:
 </p>
 
-<blockquote><pre>void A()
-{
-    tricklib::error_listener_type error_listener;
-    // A_a() is like A(). A_a() can throw tree structured exception.
-    A_a();
+<blockquote><del>
+An object bound to an rvalue reference parameter of a member function of
+a container shall not be an element of that container; no diagnostic
+required.
+</del></blockquote>
 
-    // *** It must do process so that A_a() throws exception in A(). ***
-    // A_b() is like A(). A_b() can throw tree structured exception.
-    A_b();
 
-    if (error_listener.has_error()) // You can write this "if block" in destructor
-                                    //  of class derived from error_listener_type.
-    {
-        throw_error(new A_error("someone error",error_listener.listener_off().extract_pending_error()));
-    }
-}
-void print_tree_error(const tricklib::error_type &amp;a_error, const std::string &amp; indent = "")
-{
-    const char * indent_unit = " ";
-    const char * mark = "- ";
 
-    tricklib::error_type error = a_error;
-    while(error)
-    {
-        std::cout &lt;&lt; indent &lt;&lt; mark &lt;&lt; error-&gt;message &lt;&lt; std::endl;
-        if (error-&gt;children)
-        {
-            print_tree_error(error-&gt;children, indent +indent_unit);
-        }
-        error = error-&gt;next;
-    }
-}
-int main(int, char * [])
-{
-    tricklib::error_thread_power error_thread_power_on; // This object is necessary per thread.
 
-    try
-    {
-        A();
-    }
-    catch(error_type error)
-    {
-        print_tree_error(error);
-    }
-    catch(...)
-    {
-        std::cout &lt;&lt; "- unknown exception" &lt;&lt; std::endl;
-    }
-    return EXIT_SUCCESS;
-}
-</pre></blockquote>
 
+
+<hr>
+<h3><a name="1205"></a>1205. Some algorithms could more clearly document their handling of empty ranges</h3>
+<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-09-13  <b>Last modified:</b> 2009-09-13</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#algorithms">active issues</a> in [algorithms].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Prospect
+There are a number of algorithms whose result might depend on the
+handling of an empty range.  In some cases the result is not clear,
+while in others it would help readers to clearly mention the result
+rather than require some subtle intuition of the supplied wording.
 </p>
+
 <p>
-We will focus on the method A() since the other methods, also main(), occur
-only once respectively.
+25.2.1 [alg.all_of]
 </p>
 
-<ul>
-<li>
- In the List A above (of the nested exception handling), it is hard to
- find out an active reason to use the nested exception handling at this
- scene. Rather, we can take a simpler description by throwing the entire
- exception_list directly to the top level.
-</li>
-<li>
- The code in the same example gives us a kind of redundant impression,
- which might have come from the fact that the try-throw-catch framework does
- not assume a tree structured exception handling.
-</li>
-</ul>
+<blockquote>
+<i>Returns:</i> <tt>true</tt> if <tt>pred(*i)</tt> is <tt>true</tt> for every
+iterator <tt>i</tt> in the range <tt>[first,last)</tt>, ...
+</blockquote>
 
 <p>
-According to the above observation, we cannot help concluding that it is not
-so easy to use the nested_exception handling as a tree structured exception
-handling mechanism in a practical sense.
+What does this mean if the range is empty?
 </p>
+
 <p>
-This text is based on the web page below (in Japanese).
-<a href="http://d.hatena.ne.jp/wraith13/20081231/1230715424">http://d.hatena.ne.jp/wraith13/20081231/1230715424</a>
+I believe that we intend this to be <tt>true</tt> and suggest a
+non-normative note to clarify:
 </p>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
+Add to p1 25.2.1 [alg.all_of]:
 </p>
 
+<blockquote>
+[<i>Note:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
+&#8212; <i>end note</i>]
+</blockquote>
 
+<p>
+25.2.3 [alg.none_of]
+</p>
 
+<blockquote>
+<i>Returns:</i> <tt>true</tt> if <tt>pred(*i)</tt> is <tt>false</tt> for every
+iterator <tt>i</tt> in the range <tt>[first,last)</tt>, ...
+</blockquote>
 
-
-<hr>
-<h3><a name="1133"></a>1133. Does N2844 break current specification of list::splice?</h3>
-<p><b>Section:</b> 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-09  <b>Last modified:</b> 2009-06-09</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forwardlist.ops">active issues</a> in [forwardlist.ops].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-IIUC,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
-means that lvalues will no longer bind to rvalue references.
-Therefore, the current specification of <tt>list::splice</tt> (list
-operations 23.3.4.4 [list.ops]) will be a breaking change of behaviour for existing
-programs.  That is because we changed the signature to swallow via an rvalue
-reference rather than the lvalue reference used in 03.
+What does this mean if the range empty?
 </p>
+
 <p>
-Retaining this form would be safer, requiring an explicit move when splicing
-from lvalues.  However, this will break existing programs.
-We have the same problem with <tt>forward_list</tt>, although without the risk of
-breaking programs so here it might be viewed as a positive feature.
+I believe that we intend this to be <tt>true</tt> and suggest a
+non-normative note to clarify:
 </p>
+
 <p>
-The problem signatures:
+Add to p1 25.2.3 [alg.none_of]:
 </p>
-<blockquote><pre>void splice_after(const_iterator position, forward_list&lt;T,Alloc&gt;&amp;&amp; x);
-void splice_after(const_iterator position, forward_list&lt;T,Alloc&gt;&amp;&amp; x,
-                  const_iterator i);
-void splice_after(const_iterator position, forward_list&lt;T,Alloc&gt;&amp;&amp; x,
-                  const_iterator first, const_iterator last);
-
-void splice(const_iterator position, list&lt;T,Alloc&gt;&amp;&amp; x);
-void splice(const_iterator position, list&lt;T,Alloc&gt;&amp;&amp; x,
-            const_iterator i);
-void splice(const_iterator position, list&lt;T,Alloc&gt;&amp;&amp; x,
-            const_iterator first, const_iterator last);
-</pre></blockquote>
 
-<b>Possible resolutions:</b>
+<blockquote>
+[<i>Note:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
+&#8212; <i>end note</i>]
+</blockquote>
 
 <p>
-Option A.      Add an additional (non-const) lvalue-reference
-overload in each case
+25.2.2 [alg.any_of]
 </p>
+
 <p>
-Option B.      Change rvalue reference back to (non-const)
-lvalue-reference overload in each case
+The specification for an empty range is actually fairly clear in this
+case, but a note wouldn't hurt and would be consistent with proposals
+for <tt>all_of</tt>/<tt>none_of</tt> algorithms.
 </p>
+
 <p>
-Option C.      Add an additional (non-const) lvalue-reference
-overload in just the <tt>std::list</tt> cases
+Add to p1 25.2.2 [alg.any_of]:
 </p>
+
+<blockquote>
+[<i>Note:</i> Returns <tt>false</tt> if <tt>[first,last)</tt> is empty. 
+&#8212; <i>end note</i>]
+</blockquote>
+
 <p>
-I think (B) would be very unfortunate, I really like the <tt>forward_list</tt>
-behaviour in (C) but feel (A) is needed for consistency.
+25.2.6 [alg.find.end]
 </p>
+
 <p>
-My actual preference would be NAD, ship with this as a breaking change as it
-is a more explicit interface.  I don't think that will fly though!
+what does this mean if <tt>[first2,last2)</tt> is empty?
 </p>
 
 <p>
-See the thread starting with c++std-lib-23725 for more discussion.
+I believe the wording suggests the algorithm should return
+<tt>last1</tt> in this case, but am not 100% sure. Is this in fact the
+correct result anyway? Surely an empty range should always match and the
+naive expected result would be <tt>first1</tt>?
 </p>
 
+<p>
+My proposed wording is a note to clarify the current semantic:
+</p>
 
-<p><b>Proposed resolution:</b></p>
-
+<p>
+Add to p2 25.2.6 [alg.find.end]:
+</p>
 
+<blockquote>
+[<i>Note:</i> Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is
+empty. &#8212; <i>end note</i>]
+</blockquote>
 
+<p>
+I would prefer a normative wording treating empty ranges specially, but
+do not believe we can change semantics at this point in the process,
+unless existing implementations actually yield this result:
+</p>
 
+<p>
+Alternative wording: (NOT a note)
+</p>
+<p>
+Add to p2 25.2.6 [alg.find.end]:
+</p>
+<blockquote>
+Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is empty.
+</blockquote>
 
-<hr>
-<h3><a name="1134"></a>1134. Redundant specification of stdint.h, fenv.h, tgmath.h, and maybe complex.h</h3>
-<p><b>Section:</b> 18.4.2 [stdinth], 26.3.2 [fenv], 26.8 [c.math], 26.4.11 [cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2009-05-26  <b>Last modified:</b> 2009-06-14</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-This is probably editorial.
+25.2.7 [alg.find.first.of]
 </p>
+
 <p>
-The following items should be removed from the draft, because they're
-redundant with Annex D, and they arguably make some *.h headers
-non-deprecated:
+The phrasing seems precise when <tt>[first2, last2)</tt> is empty, but a small
+note to confirm the reader's understanding might still help.
 </p>
+
 <p>
-18.4.2 [stdinth] (regarding <tt>&lt;stdint.h&gt;</tt>) 
+Add to p2 25.2.7 [alg.find.first.of]
 </p>
+<blockquote>
+[<i>Note:</i> Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is
+empty. &#8212; <i>end note</i>]
+</blockquote>
+
 <p>
-26.3.2 [fenv] (regarding <tt>&lt;fenv.h&gt;</tt>
+25.2.12 [alg.search]
 </p>
+
 <p>
-Line 3 of 26.8 [c.math] (regarding <tt>&lt;tgmath.h&gt;</tt>) 
+What is the expected result if <tt>[first2, last2)</tt> is empty?
 </p>
+
 <p>
-26.4.11 [cmplxh] (regarding <tt>&lt;complex.h&gt;</tt>, though the note in this subclause is not redundant) 
+I believe the wording suggests the algorithm should return <tt>last1</tt> in this
+case, but am not 100% sure. Is this in fact the correct result anyway? 
+Surely an empty range should always match and the naive expected result
+would be <tt>first1</tt>?
 </p>
 
-<p><i>[
-2009-06-10 Ganesh adds:
-]</i></p>
+<p>
+My proposed wording is a note to clarify the current semantic:
+</p>
 
+<p>
+Add to p2 25.2.12 [alg.search]:
+</p>
 
 <blockquote>
-While searching for <tt>stdint</tt> in the CD, I found that <tt>&lt;stdint.h&gt;</tt> is also
-mentioned in 3.9.1 [basic.fundamental] /5. It guess it should refer to
-<tt>&lt;cstdint&gt;</tt> instead.
+[<i>Note:</i> Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is
+empty. &#8212; <i>end note</i>]
 </blockquote>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Remove the section 18.4.2 [stdinth].
+Again, I would prefer a normative wording treating empty ranges
+specially, but do not believe we can change semantics at this point in
+the process, unless existing implementations actually yield this result:
 </p>
+
 <p>
-Remove the section 26.3.2 [fenv].
+Alternative wording: (NOT a note)
 </p>
 <p>
-Remove 26.8 [c.math], p3:
+Add to p2 25.2.12 [alg.search]:
 </p>
 
 <blockquote>
-<del>-3- The header <tt>&lt;tgmath.h&gt;</tt> effectively includes the headers <tt>&lt;complex.h&gt;</tt>
-and <tt>&lt;math.h&gt;</tt>.</del>
+Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is empty.
 </blockquote>
+
 <p>
-Remove the section 26.4.11 [cmplxh].
+25.3.13 [alg.partitions]
 </p>
 
-
-
-
-
-<hr>
-<h3><a name="1135"></a>1135. <tt>exception_ptr</tt> should support contextual conversion to <tt>bool</tt></h3>
-<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-06  <b>Last modified:</b> 2009-06-09</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-As of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
-18.8.5 [propagation]/5, the implementation-defined type
-<tt>exception_ptr</tt> does provide the following ways to check whether
-it is a null value:
+Is an empty range partitioned or not?
 </p>
-<blockquote><pre>void f(std::exception_ptr p) {
-  p == nullptr;
-  p == 0;
-  p == exception_ptr();
-}
-</pre></blockquote>
+
 <p>
-This is rather cumbersome way of checking for the null value
-and I suggest to require support for evaluation in a boolean
-context like so:
+Proposed wording:
 </p>
 
-<blockquote><pre>void g(std::exception_ptr p) {
-  if (p) {}
-  !p;
-}
-</pre></blockquote>
+<p>
+Add to p1 25.3.13 [alg.partitions]:
+</p>
 
+<blockquote>
+[<i>Note:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
+&#8212; <i>end note</i>]
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-In section 18.8.5 [propagation] insert a new paragraph between p.5 and p.6:
+25.4.5.1 [includes]
 </p>
 
 <blockquote>
-<ins>
-An object <tt>e</tt> of type <tt>exception_ptr</tt> can be contextually converted to <tt>bool</tt>.
-The effect shall be as if <tt>e != exception_ptr()</tt> had been evaluated in place
-of <tt>e</tt>. There shall be no implicit conversion to arithmetic type, to
-enumeration type or to pointer type.
-</ins>
+<i>Returns:</i> <tt>true</tt> if every element in the range
+<tt>[first2,last2)</tt> is contained in the range
+<tt>[first1,last1)</tt>. ...
 </blockquote>
 
+<p>
+I really don't know what this means if <tt>[first2,last2)</tt> is empty.
+I could loosely guess that this implies empty ranges always match, and
+my proposed wording is to clarify exactly that:
+</p>
 
+<p>
+Add to p1 25.4.5.1 [includes]:
+</p>
 
+<blockquote>
+[<i>Note:</i> Returns <tt>true</tt> if <tt>[first2,last2)</tt> is empty.
+&#8212; <i>end note</i>]
+</blockquote>
 
+<p>
+25.4.6.2 [pop.heap]
+</p>
 
-<hr>
-<h3><a name="1136"></a>1136. Incomplete specification of <tt>nested_exception::rethrow_nested()</tt></h3>
-<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-06  <b>Last modified:</b> 2009-06-09</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-It was recently mentioned in a newsgroup article
-<a href="http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d">http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d</a>
-that the specification of the member function <tt>rethrow_nested()</tt> of the
-class <tt>nested_exception</tt> is incomplete, specifically it remains unclear
-what happens, if member <tt>nested_ptr()</tt> returns a null value. In
-18.8.6 [except.nested] we find only the following paragraph related to that:
+The effects clause is invalid if the range <tt>[first,last)</tt> is empty, unlike
+all the other heap alogorithms.  The should be called out in the
+requirements.
 </p>
-<blockquote><pre>void rethrow_nested() const; // [[noreturn]]
-</pre>
+
+<p>
+Proposed wording:
+</p>
+<p>
+Revise p2 25.4.6.2 [pop.heap]
+</p>
+
 <blockquote>
--4- <i>Throws:</i> the stored exception captured by this <tt>nested_exception</tt> object.
-</blockquote>
+<i>Requires:</i> The range <tt>[first,last)</tt> shall be a valid
+<ins>non-empty</ins> heap.
 </blockquote>
+
 <p>
-This is a problem, because it is possible to create an object of
-<tt>nested_exception</tt> with exactly such a state, e.g.
+[Editorial] Reverse order of 25.4.6.2 [pop.heap] p1 and p2.
 </p>
-<blockquote><pre>#include &lt;exception&gt;
-#include &lt;iostream&gt;
 
-int main() try {
-  std::nested_exception e; // OK, calls current_exception() and stores it's null value
-  e.rethrow_nested(); // ?
-  std::cout &lt;&lt; "A" &lt;&lt; std::endl;
-}
-catch(...) {
-  std::cout &lt;&lt; "B" &lt;&lt; std::endl;
-}
-</pre></blockquote>
 <p>
-I suggest to follow the proposal of the reporter, namely to invoke
-<tt>terminate()</tt> if <tt>nested_ptr()</tt> return a null value of <tt>exception_ptr</tt> instead
-of relying on the fallback position of undefined behavior. This would
-be consistent to the behavior of a <tt>throw;</tt> statement when no
-exception is being handled.
+25.4.7 [alg.min.max]
 </p>
 
+<p>
+<tt>minmax_element</tt> does not clearly specify behaviour for an empty
+range in the same way that <tt>min_element</tt> and <tt>max_element</tt> do.
+</p>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Change around 18.8.6 [except.nested]/4 as indicated:
+Add to p31 25.4.7 [alg.min.max]:
 </p>
+
 <blockquote>
+Returns <tt>make_pair(first, first)</tt> if <tt>first == last</tt>.
+</blockquote>
+
 <p>
--4- <i>Throws:</i> the stored exception captured by this <tt>nested_exception</tt>
-object<ins>, if <tt>nested_ptr() != nullptr</tt></ins>
+25.4.8 [alg.lex.comparison]
 </p>
+
 <p>
-<ins>- <i>Remarks:</i> If <tt>nested_ptr() == nullptr</tt>, <tt>terminate()</tt>
-shall be called.</ins>
+The wording here seems quite clear, especially with the sample algorithm
+implementation.  A note is recommended purely for consistency with the
+rest of these issue resolutions:
 </p>
-</blockquote>
-
 
+<p>
+Add to p1 25.4.8 [alg.lex.comparison]:
+</p>
 
+<blockquote>
+[<i>Note:</i> An empty sequence is lexicographically less than any other
+non-empty sequence, but not to another empty sequence. &#8212; <i>end note</i>]
+</blockquote>
 
 
-<hr>
-<h3><a name="1137"></a>1137. Return type of <tt>conj</tt> and <tt>proj</tt></h3>
-<p><b>Section:</b> 26.4.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Marc Steinbach <b>Opened:</b> 2009-06-11  <b>Last modified:</b> 2009-06-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cmplx.over">issues</a> in [cmplx.over].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Proposed resolution:</b></p>
 <p>
-In clause 1, the Working Draft 
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>)
-specifies overloads of the
-functions
+Add to p1 25.2.1 [alg.all_of]:
 </p>
-<blockquote><pre>arg, conj, imag, norm, proj, real
-</pre></blockquote>
+<blockquote>
+[<i>Note:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
+&#8212; <i>end note</i>]
+</blockquote>
+
 <p>
-for non-complex arithmetic types (<tt>float</tt>, <tt>double</tt>,
-<tt>long double</tt>, and integers).
-The only requirement (clause 2) specifies effective type promotion of arguments.
+Add to p1 25.2.2 [alg.any_of]:
 </p>
+<blockquote>
+[<i>Note:</i> Returns <tt>false</tt> if <tt>[first,last)</tt> is empty. 
+&#8212; <i>end note</i>]
+</blockquote>
+
 <p>
-I strongly suggest to add the following requirement on the return types:
+Add to p1 25.2.3 [alg.none_of]:
 </p>
 <blockquote>
-All the specified overloads must return real (i.e., non-complex) values,
-specifically, the nested <tt>value_type</tt> of effectively promoted arguments.
+[<i>Note:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
+&#8212; <i>end note</i>]
 </blockquote>
 
 <p>
-(This has no effect on <tt>arg</tt>, <tt>imag</tt>, <tt>norm</tt>, <tt>real</tt>:
-they are real-valued anyway.)
+Add to p2 25.2.6 [alg.find.end]:
 </p>
-<p><b>Rationale:</b></p>
+<blockquote>
+[<i>Note:</i> Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is
+empty.  &#8212; <i>end note</i>]
+</blockquote>
+
 <p>
-Mathematically, <tt>conj()</tt> and <tt>proj()</tt>, like the transcendental functions, are
-complex-valued in general but map the (extended) real line to itself.
-In fact, both functions act as identity on the reals.
-A typical user will expect <tt>conj()</tt> and <tt>proj()</tt> to preserve this essential
-mathematical property in the same way as <tt>exp()</tt>, <tt>sin()</tt>, etc.
-A typical use of <tt>conj()</tt>, e.g., is the generic scalar product of n-vectors:
+Add to p2 25.2.7 [alg.find.first.of]
 </p>
+<blockquote>
+[<i>Note:</i> Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is
+empty.  &#8212; <i>end note</i>]
+</blockquote>
 
-<blockquote><pre>template&lt;typename T&gt;
-inline T
-scalar_product(size_t n, T const* x, T const* y) {
-  T result = 0;
-  for (size_t i = 0; i &lt; n; ++i)
-    result += x[i] * std::conj(y[i]);
-  return result;
-}
-</pre></blockquote>
 <p>
-This will work equally well for real and complex floating-point types <tt>T</tt> if
-<tt>conj()</tt> returns <tt>T</tt>. It will not work with real types if <tt>conj()</tt>
-returns complex values.
+Add to p2 25.2.12 [alg.search]:
 </p>
+<blockquote>
+[<i>Note:</i> Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is
+empty.  &#8212; <i>end note</i>]
+</blockquote>
+
 <p>
-Instead, the implementation of <tt>scalar_product</tt> becomes either less efficient
-and less useful (if a complex result is always returned), or unnecessarily
-complicated (if overloaded versions with proper return types are defined).
-In the second case, the real-argument overload of <tt>conj()</tt> cannot be used.
-In fact, it must be avoided.
+Add to p1 25.3.13 [alg.partitions]:
 </p>
-<p>
-Overloaded <tt>conj()</tt> and <tt>proj()</tt> are principally needed in generic programming.
-All such use cases will benefit from the proposed return type requirement,
-in a similar way as the <tt>scalar_product</tt> example.
-The requirement will not harm use cases where a complex return value
-is expected, because of implicit conversion to complex.
-Without the proposed return type guarantee, I find overloaded versions
-of <tt>conj()</tt> and <tt>proj()</tt> not only useless but actually troublesome.
+<blockquote>
+[<i>Note:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
+&#8212; <i>end note</i>]
+</blockquote>
+
+<p>
+Add to p1 25.4.5.1 [includes]:
 </p>
+<blockquote>
+[<i>Note:</i> Returns <tt>true</tt> if <tt>[first2,last2)</tt> is empty. 
+&#8212; <i>end note</i>]
+</blockquote>
 
+<p>
+Revise p2 25.4.6.2 [pop.heap]
+</p>
+<blockquote>
+Requires: The range <tt>[first,last)</tt> shall be a valid
+<ins>non-empty</ins> heap.
+</blockquote>
 
+<p>
+[Editorial] 
+</p>
+<blockquote>
+Reverse order of 25.4.6.2 [pop.heap] p1 and p2.
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Insert a new paragraph after 26.4.9 [cmplx.over]/2:
+Add to p31 25.4.7 [alg.min.max]:
 </p>
+<blockquote>
+Returns <tt>make_pair(first, first)</tt> if <tt>first == last</tt>.
+</blockquote>
 
+<p>
+Add to p1 25.4.8 [alg.lex.comparison]:
+</p>
 <blockquote>
-<ins>
-All of the specified overloads shall have a return type which is the nested <tt>value_type</tt> of
-the effectively promoted arguments.
-</ins>
+[<i>Note:</i> An empty sequence is lexicographically less than any other
+non-empty sequence, but not less than another empty sequence. &#8212;
+<i>end note</i>]
 </blockquote>
 
 
 
 
 
+
 <hr>
-<h3><a name="1138"></a>1138. unusal return value for operator+</h3>
-<p><b>Section:</b> 21.4.8.1 [string::op+] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-06-12  <b>Last modified:</b> 2009-06-15</p>
+<h3><a name="1206"></a>1206. Incorrect requires for <tt>move_backward</tt> and <tt>copy_backward</tt></h3>
+<p><b>Section:</b> 25.3.2 [alg.move] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-09-13  <b>Last modified:</b> 2009-09-13</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Many of the <tt>basic_string operator+</tt> overloads return an rvalue-reference.  Is
-that really intended?
+25.3.2 [alg.move], p6 says:
 </p>
+
+<blockquote>
+<pre>template&lt;class BidirectionalIterator1, class BidirectionalIterator2&gt;
+  BidirectionalIterator2
+    move_backward(BidirectionalIterator1 first,
+                  BidirectionalIterator1 last,
+                  BidirectionalIterator2 result);
+</pre>
+<blockquote>
+<p>...</p>
 <p>
-I'm considering it might be a mild performance tweak to avoid making
-un-necessary copies of a cheaply movable type, but it opens risk to dangling
-references in code like:
+<i>Requires:</i> <tt>result</tt> shall not be in the range
+<tt>[first,last)</tt>.
 </p>
-
-<blockquote><pre>auto &amp;&amp; s = string{"x"} + string{y};
-</pre></blockquote>
+</blockquote>
+</blockquote>
 
 <p>
-and I'm not sure about:
+This is essentially an "off-by-one" error.
 </p>
 
-<blockquote><pre>auto s = string{"x"} + string{y};
-</pre></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Strike the <tt>&amp;&amp;</tt> from the return type in the following function
-signatures:
+When <tt>result == last</tt>, which
+<em>is</em> allowed by this specification, then the range <tt>[first, last)</tt>
+is being move assigned into the range <tt>[first, last)</tt>.  The <tt>move</tt>
+(forward) algorithm doesn't allow self move assignment, and neither should
+<tt>move_backward</tt>.  So <tt>last</tt> should be included in the range which
+<tt>result</tt> can not be in.
 </p>
 
-<blockquote>
 <p>
-21.3 [string.classes] p2 Header Synopsis
+Conversely, when <tt>result == first</tt>, which <em>is not</em> allowed by this
+specification, then the range <tt>[first, last)</tt>
+is being move assigned into the range <tt>[first - (last-first), first)</tt>.
+I.e. into a <em>non-overlapping</em> range.  Therefore <tt>first</tt> should
+not be included in the range which <tt>result</tt> can not be in.
 </p>
 
-<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
-  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
-    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
-              const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs);
-
-template&lt;class charT, class traits, class Allocator&gt;
-  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
-    operator+(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
-              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
-
-template&lt;class charT, class traits, class Allocator&gt;
-  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
-    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
-              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
-
-
-template&lt;class charT, class traits, class Allocator&gt;
-  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
-    operator+(const charT* lhs,
-              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
-
-template&lt;class charT, class traits, class Allocator&gt;
-  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
-    operator+(charT lhs, basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
-
-template&lt;class charT, class traits, class Allocator&gt;
-  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
-    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
-              const charT* rhs);
-
-template&lt;class charT, class traits, class Allocator&gt;
-  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
-    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs, charT rhs);
-</pre></blockquote>
-
 <p>
-21.4.8.1 [string::op+]
+The same argument applies to <tt>copy_backward</tt> though copy assigning elements
+to themselves (<tt>result == last</tt>) should be harmless (though is disallowed
+by <tt>copy</tt>).
 </p>
 
-<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
-  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
-    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
-              const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs);
-
-template&lt;class charT, class traits, class Allocator&gt;
-  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
-    operator+(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
-              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
-
-template&lt;class charT, class traits, class Allocator&gt;
-  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
-    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
-              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
-
 
-template&lt;class charT, class traits, class Allocator&gt;
-  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
-    operator+(const charT* lhs,
-              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
 
-template&lt;class charT, class traits, class Allocator&gt;
-  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
-    operator+(charT lhs, basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 25.3.2 [alg.move], p6:
+</p>
 
-template&lt;class charT, class traits, class Allocator&gt;
-  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
-    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
-              const charT* rhs);
+<blockquote>
+<pre>template&lt;class BidirectionalIterator1, class BidirectionalIterator2&gt;
+  BidirectionalIterator2
+    move_backward(BidirectionalIterator1 first,
+                  BidirectionalIterator1 last,
+                  BidirectionalIterator2 result);
+</pre>
+<blockquote>
+<p>...</p>
+<p>
+<i>Requires:</i> <tt>result</tt> shall not be in the range
+<tt><del>[</del><ins>(</ins>first,last<ins>]</ins><del>)</del></tt>.
+</p>
+</blockquote>
+</blockquote>
 
-template&lt;class charT, class traits, class Allocator&gt;
-  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
-    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs, charT rhs);
-</pre></blockquote>
+<p>
+Change 25.3.1 [alg.copy], p13:
+</p>
 
+<blockquote>
+<pre>template&lt;class BidirectionalIterator1, class BidirectionalIterator2&gt;
+  BidirectionalIterator2
+    copy_backward(BidirectionalIterator1 first,
+                  BidirectionalIterator1 last,
+                  BidirectionalIterator2 result);
+</pre>
+<blockquote>
+<p>...</p>
+<p>
+<i>Requires:</i> <tt>result</tt> shall not be in the range
+<tt><del>[</del><ins>(</ins>first,last<ins>]</ins><del>)</del></tt>.
+</p>
+</blockquote>
 </blockquote>
-
 
 
 
 
 
 <hr>
-<h3><a name="1144"></a>1144. "thread safe" is undefined</h3>
-<p><b>Section:</b> 18.5 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-16  <b>Last modified:</b> 2009-07-04</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.start.term">issues</a> in [support.start.term].</p>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Loïc Joly <b>Opened:</b> 2009-09-13  <b>Last modified:</b> 2009-09-19</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#list.ops">active issues</a> in [list.ops].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 187</b></p>
-
 <p>
-The term "thread safe" is not defined nor used in this context
-anywhere else in the standard.
+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><b>Suggested action:</b></p>
 <p>
-Clarify the meaning of "thread safe".
+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>
 
 
@@ -29450,379 +25203,397 @@ Clarify the meaning of "thread safe".
 
 
 <hr>
-<h3><a name="1145"></a>1145. inappropriate headers for atomics</h3>
-<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-16  <b>Last modified:</b> 2009-07-04</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="1208"></a>1208. valarray initializer_list constructor has incorrect effects</h3>
+<p><b>Section:</b> 26.6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-09-23  <b>Last modified:</b> 2009-10-29</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
 <p><b>Discussion:</b></p>
+<p>
+26.6.2.1 [valarray.cons] says:
+</p>
 
-<p><b>Addresses UK 312</b></p>
+<blockquote>
+<pre>valarray(initializer_list&lt;T&gt; il);
+</pre>
+<blockquote>
+<i>Effects:</i> Same as <tt>valarray(il.begin(), il.end())</tt>.
+</blockquote>
+</blockquote>
 
 <p>
-The contents of the <tt>&lt;stdatomic.h&gt;</tt> header are not listed anywhere,
-and <tt>&lt;cstdatomic&gt;</tt> is listed as a C99 header in chapter 17.
-If we intend to use these for compatibility with a future C standard,
-we should not use them now.
+But there is no <tt>valarray</tt> constructor taking two <tt>const T*</tt>.
 </p>
 
+<p><i>[
+2009-10-29 Howard:
+]</i></p>
+
+
+<blockquote>
+Moved to Tentatively Ready after 6 positive votes on c++std-lib.
+</blockquote>
+
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Remove <tt>&lt;cstdatomic&gt;</tt> from the C99 headers in table 14.
-Add a new header <tt>&lt;atomic&gt;</tt> to the headers in table 13.
-Update chapter 29 to remove reference to <tt>&lt;stdatomic.h&gt;</tt>
-and replace the use of <tt>&lt;cstdatomic&gt;</tt> with <tt>&lt;atomic&gt;</tt>.
+Change 26.6.2.1 [valarray.cons]:
 </p>
-<p><i>[
-If and when WG14 adds atomic operations to C
-we can add corresponding headers to table 14 with a TR.
-]</i></p>
 
+<blockquote>
+<pre>valarray(initializer_list&lt;T&gt; il);
+</pre>
+<blockquote>
+<i>Effects:</i> Same as <tt>valarray(il.begin(), il.<del>end</del><ins>size</ins>())</tt>.
+</blockquote>
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="1146"></a>1146. "lockfree" does not say enough</h3>
-<p><b>Section:</b> 29.4 [atomics.lockfree] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-06-16  <b>Last modified:</b> 2009-07-04</p>
+<h3><a name="1209"></a>1209. match_results should be moveable</h3>
+<p><b>Section:</b> 28.10.1 [re.results.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2009-09-15  <b>Last modified:</b> 2009-09-21</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses US 88</b></p>
+<p>
+In Working Draft
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>,
+<tt>match_results</tt> lacks a move constructor and move
+assignment operator. Because it owns dynamically allocated memory, it
+should be moveable.
+</p>
 
 <p>
-The "lockfree" facilities do not tell the programmer enough.
+As far as I can tell, this isn't tracked by an active issue yet; Library
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a> doesn't talk about <tt>match_results</tt>.
 </p>
 
+<p><i>[
+2009-09-21 Daniel provided wording.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
 <p>
-There are 2 problems here.
-First, at least on x86,
-it's less important to me whether some integral types are lock free
-than what is the largest type I can pass to atomic and have it be lock-free.
-For example, if <tt>long long</tt>s are not lock-free,
-<tt>ATOMIC_INTEGRAL_LOCK_FREE</tt> is probably 1,
-but I'd still be interested in knowing whether longs are always lock-free.
-Or if long longs at any address are lock-free,
-I'd expect <tt>ATOMIC_INTEGRAL_LOCK_FREE</tt> to be 2,
-but I may actually care whether I have access to
-the <code>cmpxchg16b</code> instruction.
-None of the support here helps with that question.
-(There are really 2 related questions here:
-what alignment requirements are there for lock-free access;
-and what processor is the program actually running on,
-as opposed to what it was compiled for?)
+Add the following member declarations to 28.10 [re.results]/3:
 </p>
 
+<blockquote><pre>// 28.10.1, construct/copy/destroy:
+explicit match_results(const Allocator&amp; a = Allocator());
+match_results(const match_results&amp; m);
+<ins>match_results(match_results&amp;&amp; m);</ins>
+match_results&amp; operator=(const match_results&amp; m);
+<ins>match_results&amp; operator=(match_results&amp;&amp; m);</ins>
+~match_results();
+</pre></blockquote>
+</li>
+
+<li>
 <p>
-Second, having <tt>atomic_is_lock_free</tt> only apply to individual objects
-is pretty useless
-(except, as Lawrence Crowl points out,
-for throwing an exception when an object is unexpectedly not lock-free).
-I'm likely to want to use its result to decide what algorithm to use,
-and that algorithm is probably going to allocate new memory
-containing atomic objects and then try to act on them.
-If I can't predict the lock-freedom of the new object
-by checking the lock-freedom of an existing object,
-I may discover after starting the algorithm that I can't continue.
+Add the following new prototype descriptions to 28.10.1 [re.results.const]
+using the table numbering of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>:
 </p>
 
-<p><i>[
-2009-06-16 Jeffrey Yasskin adds:
-]</i></p>
+<blockquote>
+<pre>match_results(const match_results&amp; m);
+</pre>
 
+<blockquote>
+4 <i>Effects:</i> Constructs an object of class <tt>match_results</tt>, as a
+copy of <tt>m</tt>.
+</blockquote>
+
+<pre><ins>match_results(match_results&amp;&amp; m);</ins>
+</pre>
 
 <blockquote>
 <p>
-To solve the first problem, I think 2 macros would help:
-<tt>MAX_POSSIBLE_LOCK_FREE_SIZE</tt> and <tt>MAX_GUARANTEED_LOCK_FREE_SIZE</tt>,
-which expand to the maximum value of <tt>sizeof(T)</tt> for which atomic may
-(or will, respectively) use lock-free operations.
-Lawrence points out that this
-"relies heavily on implementations
-using word-size compare-swap on sub-word-size types,
-which in turn requires address modulation."
-He expects that to be the end state anyway, so it doesn't bother him much.
+<ins>5 <i>Effects:</i> Move-constructs an object of class <tt>match_results</tt>
+from <tt>m</tt> satisfying the same postconditions as Table 132. Additionally
+the stored <tt>Allocator</tt> value is move constructed from <tt>m.get_allocator()</tt>.
+After the initialization of <tt>*this</tt> sets <tt>m</tt> to an unspecified but valid
+state.</ins>
 </p>
 
 <p>
-To solve the second,
-I think one could specify that equally aligned objects of the same type
-will return the same value from <tt>atomic_is_lock_free()</tt>.
-I don't know how to specify "equal alignment".
-Lawrence suggests an additional function, <tt>atomic_is_always_lock_free()</tt>.
+<ins>6 <i>Throws:</i> Nothing if the allocator's move constructor throws nothing.</ins>
 </p>
 </blockquote>
 
+<pre>match_results&amp; operator=(const match_results&amp; m);
+</pre>
 
+<blockquote>
+7 <i>Effects:</i> Assigns <tt>m</tt> to <tt>*this</tt>. The postconditions of this function are
+indicated in Table 132.
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
+<pre><ins>match_results&amp; operator=(match_results&amp;&amp; m);</ins>
+</pre>
+
+<blockquote>
+<p>
+<ins>8 <i>Effects:</i> Move-assigns <tt>m</tt> to <tt>*this</tt>. The postconditions of this
+function are indicated in Table 132. After the assignment, <tt>m</tt> is in
+a valid but unspecified state.</ins>
+</p>
+
+<p>
+<ins>9 <i>Throws:</i> Nothing.</ins>
+</p>
+</blockquote>
+</blockquote>
+</li>
+
+</ol>
 
 
 
 
 
 <hr>
-<h3><a name="1147"></a>1147. non-volatile atomic functions</h3>
-<p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-06-16  <b>Last modified:</b> 2009-07-04</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types.operations">active issues</a> in [atomics.types.operations].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
+<h3><a name="1210"></a>1210. iterator reachability should not require a container</h3>
+<p><b>Section:</b> 24.2 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-09-18  <b>Last modified:</b> 2009-09-19</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses US 90</b></p>
-
 <p>
-The C++0X draft
-declares all of the functions dealing with atomics (section 29.6 [atomics.types.operations])
-to take volatile arguments.
-Yet it also says (29.4-3),
+p6 Iterator requirements 24.2 [iterator.requirements]
 </p>
 
 <blockquote>
-<p>
-[ Note: Many operations are volatile-qualified.
-The "volatile as device register" semantics have not changed in the standard.
-This qualification means that volatility is preserved
-when applying these operations to volatile objects.
-It does not mean that operations on non-volatile objects become volatile.
-Thus, volatile qualified operations on non-volatile objects
-may be merged under some conditions. &#8212;end note ]
-</p>
+An iterator <tt>j</tt> is called reachable from an iterator <tt>i</tt> if and only if
+there is a finite sequence of applications of the expression <tt>++i</tt> that
+makes <tt>i == j</tt>. If <tt>j</tt> is reachable from <tt>i</tt>, they refer to the same
+container.
 </blockquote>
 
 <p>
-I was thinking about how to implement this in gcc,
-and I believe that we'll want to overload most of the functions
-on volatile and non-volatile.
-Here's why:
+A good example would be stream iterators, which do not refer to a
+container.  Typically, the end iterator from a range of stream iterators
+will compare equal for many such ranges.  I suggest striking the second
+sentence.
 </p>
 
 <p>
-To let the compiler take advantage of the permission
-to merge non-volatile atomic operations and reorder atomics in certain,
-we'll need to tell the compiler backend
-about exactly which atomic operation was used.
-So I expect most of the functions of the form atomic_&lt;op&gt;_explicit()
-(e.g. atomic_load_explicit, atomic_exchange_explicit,
-atomic_fetch_add_explicit, etc.)
-to become compiler builtins.
-A builtin can tell whether its argument was volatile or not,
-so those functions don't really need extra explicit overloads.
-However, I don't expect that we'll want to add builtins
-for every function in chapter 29,
-since most can be implemented in terms of the _explicit free functions:
+An alternative wording might be:
 </p>
 
-<pre><code>class atomic_int {
-  __atomic_int_storage value;
- public:
-  int fetch_add(int increment, memory_order order = memory_order_seq_cst) volatile {
-    // &amp;value has type "volatile __atomic_int_storage*".
-    atomic_fetch_add_explicit(&amp;value, increment, order);
-  }
-  ...
-};
-</code></pre>
+<blockquote>
+If <tt>j</tt> is reachable from <tt>i</tt>, and both <tt>i</tt> and
+<tt>j</tt> are dereferencable iterators, then they refer to the same
+range.
+</blockquote>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-But now this <em>always</em> calls
-the volatile builtin version of atomic_fetch_add_explicit(),
-even if the atomic_int wasn't declared volatile.
-To preserve volatility and the compiler's permission to optimize,
-I'd need to write:
+Change 24.2 [iterator.requirements], p6:
 </p>
 
-<pre><code>class atomic_int {
-  __atomic_int_storage value;
- public:
-  int fetch_add(int increment, memory_order order = memory_order_seq_cst) volatile {
-    atomic_fetch_add_explicit(&amp;value, increment, order);
-  }
-  int fetch_add(int increment, memory_order order = memory_order_seq_cst) {
-    atomic_fetch_add_explicit(&amp;value, increment, order);
-  }
-  ...
-};
-</code></pre>
+<blockquote>
+An iterator <tt>j</tt> is called <i>reachable</i> from an iterator
+<tt>i</tt> if and only if there is a finite sequence of applications of
+the expression <tt>++i</tt> that makes <tt>i == j</tt>. <del>If
+<tt>j</tt> is reachable from <tt>i</tt>, they refer to the same
+container.</del>
+</blockquote>
+
+
 
-<p>
-But this is visibly different from the declarations in the standard
-because it's now overloaded.
-(Consider passing &amp;atomic_int::fetch_add as a template parameter.)
-</p>
 
+
+<hr>
+<h3><a name="1211"></a>1211. move iterators should be restricted as input iterators</h3>
+<p><b>Section:</b> 24.5.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-09-18  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#move.iterator">issues</a> in [move.iterator].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-The implementation may already have permission to add overloads
-to the member functions:
+I contend that while we can support both bidirectional and random access
+traversal, the category of a move iterator should never be better than
+<tt>input_iterator_tag</tt>.
 </p>
 
-<blockquote>
 <p>
-17.6.4.5 [member.functions] An implementation may declare additional non-virtual
-member function signatures within a class:<br>
-...
+The contentious point is that you cannot truly have a multipass property
+when values are moved from a range.  This is contentious if you view a
+moved-from object as still holding a valid value within the range.  
 </p>
-<ul>
-<li>by adding a member function signature for a member function name.</li>
-</ul>
-</blockquote>
 
 <p>
-but I don't see an equivalent permission to add overloads to the free functions.
+The second reason comes from the Forward Iterator requirements table:
 </p>
 
-<p><i>[
-2009-06-16 Lawrence adds:
-]</i></p>
-
-
 <blockquote>
 <p>
-I recommend allowing non-volatile overloads.
+Forward iterators 24.2.3 [forward.iterators]
 </p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
 
+<p>
+Table 102 -- Forward iterator requirements
+</p>
 
+<blockquote>
+For expression <tt>*a</tt> the return type is:
+"<tt>T&amp;</tt> if <tt>X</tt> is mutable, otherwise <tt>const T&amp;</tt>"
+</blockquote>
+</blockquote>
 
-<hr>
-<h3><a name="1148"></a>1148. Wrong argument type of I/O stream manipulators <tt>setprecision()</tt>
-and <tt>setw()</tt></h3>
-<p><b>Section:</b> 27.7 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Marc Steinbach <b>Opened:</b> 2009-06-20  <b>Last modified:</b> 2009-07-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-The header <tt>&lt;iomanip&gt;</tt> synopsis in 27.7 [iostream.format] specifies
+There is a similar constraint on <tt>a-&gt;m</tt>.
 </p>
-<blockquote><pre>T5 setprecision(int n);
-T6 setw(int n);
-</pre></blockquote>
 
 <p>
-The argument types should be streamsize, as in class <tt>ios_base</tt>
-(see 27.5.2 [ios.base]):
+There is no support for rvalue references, nor do I believe their should
+be.  Again, opinions may vary but either this table or the definition of
+<tt>move_iterator</tt> need updating.
 </p>
-<blockquote><pre>streamsize precision() const;
-streamsize precision(streamsize prec);
-streamsize width() const;
-streamsize width(streamsize wide);
-</pre></blockquote>
 
 <p>
-(Editorial: 'wide' should probably be renamed as 'width', or maybe just 'w'.)
+Note: this requirement probably need updating anyway if we wish to
+support proxy iterators but I am waiting to see a new working paper
+before filing that issue.
 </p>
 
 <p><i>[
-2009-07-29 Daniel clarified wording.
+2009-10 post-Santa Cruz:
 ]</i></p>
 
 
+<blockquote>
+Move to Open. Howard to put his rationale mentioned above into the issue
+as a note.
+</blockquote>
+
+<p><i>[
+2009-10-26 Howard adds:
+]</i></p>
+
 
-<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
+<blockquote>
 <p>
-In 27.7 [iostream.format], header <tt>&lt;iomanip&gt;</tt> synopsis change as indicated:
+<tt>vector::insert(pos, iter, iter)</tt> is significantly more effcient when
+<tt>iter</tt> is a random access iterator, as compared to when it is an
+input iterator.
 </p>
 
-<blockquote><pre>T5 setprecision(<del>int</del><ins>streamsize</ins> n);
-T6 setw(<del>int</del><ins>streamsize</ins> n);
-</pre></blockquote>
-</li>
+<p>
+When <tt>iter</tt> is an input iterator, the best algorithm
+is to append the inserted range to the end of the <tt>vector</tt> using
+<tt>push_back</tt>.  This may involve several reallocations before the input
+range is exhausted.  After the append, then one can use <tt>std::rotate</tt>
+to place the inserted range into the correct position in the vector.
+</p>
 
-<li>
 <p>
-In 27.7.3 [std.manip], just before p. 6 change as indicated:
+But when <tt>iter</tt> is a random access iterator, the best algorithm
+is to first compute the size of the range to be inserted (<tt>last - first</tt>),
+do a buffer reallocation if necessary, scoot existing elements in the <tt>vector</tt>
+down to make the "hole", and then insert the new elements directly to their correct
+place.
 </p>
 
-<blockquote><pre>unspecified setprecision(<del>int</del><ins>streamsize</ins> n);
-</pre></blockquote>
-</li>
+<blockquote><b>
+The insert-with-random-access-iterators algorithm is considerably more efficient
+than the insert-with-input-iterators algorithm
+</b></blockquote>
 
-<li>
 <p>
-In 27.7.3 [std.manip], just before p. 7 change as indicated:
+Now consider:
 </p>
 
-<blockquote><pre>unspecified setw(<del>int</del><ins>streamsize</ins> n);
+<blockquote><pre>vector&lt;A&gt; v;
+<font color="#c80000">//  ... build up a large vector of A ...</font>
+vector&lt;A&gt; temp;
+<font color="#c80000">//  ... build up a large temporary vector of A to later be inserted ...</font>
+typedef move_iterator&lt;vector&lt;A&gt;::iterator&gt; MI;
+<font color="#c80000">//  Now insert the temporary elements:</font>
+v.insert(v.begin() + N, MI(temp.begin()), MI(temp.end()));
 </pre></blockquote>
-</li>
-</ol>
-
-
-
-
-
-
 
+<p>
+A major motivation for using <tt>move_iterator</tt> in the above example is the
+expectation that <tt>A</tt> is cheap to move but expensive to copy.  I.e. the
+customer is looking for <em>high performance</em>.  If we allow <tt>vector::insert</tt>
+to subtract two <tt>MI</tt>'s to get the distance between them, the customer enjoys
+substantially better performance, compared to if we say that <tt>vector::insert</tt>
+can not subtract two <tt>MI</tt>'s.
+</p>
 
-<hr>
-<h3><a name="1150"></a>1150. wchar_t, char16_t and char32_t filenames</h3>
-<p><b>Section:</b> 27.9.1.14 [fstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-04</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p><b>Addresses JP 73</b></p>
+<p>
+I can find no rationale for not giving this performance boost to our customers.
+Therefore I am strongly against restricting <tt>move_iterator</tt> to the
+<tt>input_iterator_tag</tt> category.
+</p>
 
-   <p><b>Description</b></p>
-        <p>It is a problem
-        from C++98, <tt>fstream</tt> cannot appoint a filename of wide
-        character string(<tt>const wchar_t</tt> and <tt>const wstring&amp;</tt>).</p>
-<p><b>Suggestion</b></p>
-        <p>Add
-        interface corresponding to <tt>wchar_t</tt>, <tt>char16_t</tt> and <tt>char32_t</tt>.</p>
+<p>
+I believe that the requirement that forward
+iterators have a dereference that returns an lvalue reference to cause unacceptable
+pessimization.  For example <tt>vector&lt;bool&gt;::iterator</tt> also does not return
+a <tt>bool&amp;</tt> on dereference.  Yet I am not aware of a single vendor that
+is willing to ship <tt>vector&lt;bool&gt;::iterator</tt> as an input iterator.
+Everyone classifies it as a random access iterator.  Not only does this not
+cause any problems, it prevents significant performance problems.
+</p>
 
-<p><i>[
-2009-07-01 Alisdair notes that this is a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a> which has more
-in-depth rationale.
-]</i></p>
+</blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
+<p>
+Class template move_iterator 24.5.3.1 [move.iterator]
+</p>
+
+<blockquote><pre>namespace std {
+template &lt;class Iterator&gt;
+class move_iterator {
+public:
+ ...
+ typedef <del>typename iterator_traits&lt;Iterator&gt;::iterator_category</del> <ins>input_iterator_tag</ins> iterator_category;
+</pre></blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="1151"></a>1151. Behavior of the library in the presence of threads is incompletely specified</h3>
-<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-06-28</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<h3><a name="1212"></a>1212. result of post-increment/decrement operator</h3>
+<p><b>Section:</b> 24.2 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-09-18  <b>Last modified:</b> 2009-09-19</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-<p><b>Addresses US 63</b></p>
+<p>Forward iterator and bidirectional iterator place different
+requirements on the result of post-increment/decrement operator. The
+same form should be used in each case.
+</p>
 
-   <p><b>Description</b></p>
-        <p>The behavior of the library in the presence of threads
-        is incompletely specified.</p>
-        <p>For example, if thread 1 assigns to <tt>X</tt>, then writes data
-        to file <tt>f</tt>, which is read by thread 2, and then accesses
-        variable <tt>X</tt>, is thread 2 guaranteed to be able to see the
-        value assigned to <tt>X</tt> by thread 1? In other words, does the
-        write of the data "happen before" the read?</p>
-        <p>Another example: does simultaneous access using <tt>operator
-        at()</tt> to different characters in the same non-const string
-        really introduce a data race?</p>
-<p><b>Suggestion</b></p>
-<p><b>Notes</b></p><p>17 SG: should go to threads group; misclassified in document
+<p>
+Merging row from:
 </p>
 
-    <p>Concurrency SG: Create an issue. Hans will look into it.</p>
+<blockquote><pre>Table 102 -- Forward iterator requirements
+Table 103 -- Bidirectional iterator requirements
+
+    r++ : convertible to const X&amp;
+    r-- : convertible to const X&amp;
+    
+    *r++ : T&amp; if X is mutable, otherwise const T&amp;
+    *r-- : convertible to T
+</pre></blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
@@ -29832,167 +25603,129 @@ in-depth rationale.
 
 
 <hr>
-<h3><a name="1152"></a>1152. expressions parsed differently than intended</h3>
-<p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Seungbeom Kim <b>Opened:</b> 2009-06-27  <b>Last modified:</b> 2009-07-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.put.virtuals">active issues</a> in [facet.num.put.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-09-19  <b>Last modified:</b> 2009-09-19</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-In Table 73 -- Floating-point conversions, 22.4.2.2.2 [facet.num.put.virtuals], 
-in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>,
-we have the following entries: 
+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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a> (including further updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/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>
-<table border="1">
-<caption>Table 73 &#8212; Floating-point conversions</caption>
-<tbody><tr>
-<th>State</th> <th><tt>stdio</tt> equivalent</th>
-</tr>
-<tr>
-<td><tt>floatfield == ios_base::fixed | ios_base::scientific &amp;&amp; !uppercase</tt></td>
-<td align="center"><tt>%a</tt></td>
-</tr>
-
-<tr>
-<td><tt>floatfield == ios_base::fixed | ios_base::scientific</tt></td>
-<td align="center"><tt>%A</tt></td>
-</tr>
-</tbody></table>
 
+<blockquote>
 <p>
-These expressions are supposed to mean: 
+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>
 
-<blockquote><pre>floatfield == (ios_base::fixed | ios_base::scientific) &amp;&amp; !uppercase 
-floatfield == (ios_base::fixed | ios_base::scientific) 
-</pre></blockquote>
 <p>
-but technically parsed as: 
+10 - An invalid iterator is an iterator that may be singular.
 </p>
-<blockquote><pre>((floatfield == ios_base::fixed) | ios_base::scientific) &amp;&amp; (!uppercase) 
-((floatfield == ios_base::fixed) | ios_base::scientific) 
-</pre></blockquote>
+</blockquote>
+
 <p>
-and should be corrected with additional parentheses, as shown above. 
+First, issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/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><b>Proposed resolution:</b></p>
 <p>
-Change Table 73 &#8212; Floating-point conversions in  22.4.2.2.2 [facet.num.put.virtuals]:
+and <a href="http://www.sgi.com/tech/stl/InputIterator.html">proceeds</a>:
 </p>
 
-<table border="1">
-<caption>Table 73 &#8212; Floating-point conversions</caption>
-<tbody><tr>
-<th>State</th> <th><tt>stdio</tt> equivalent</th>
-</tr>
-<tr>
-<td><tt>floatfield == <ins>(</ins>ios_base::fixed | ios_base::scientific<ins>)</ins> &amp;&amp; !uppercase</tt></td>
-<td align="center"><tt>%a</tt></td>
-</tr>
-
-<tr>
-<td><tt>floatfield == <ins>(</ins>ios_base::fixed | ios_base::scientific<ins>)</ins></tt></td>
-<td align="center"><tt>%A</tt></td>
-</tr>
-</tbody></table>
-
-
-
-
-
-<hr>
-<h3><a name="1153"></a>1153. Standard library needs review for constructors to be
-explicit to avoid treatment as initializer-list constructor</h3>
-<p><b>Section:</b> 17 [library], 30 [thread], D [depr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-04</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p><b>Addresses DE 2</b></p>
-
-<p><b>Description</b></p>
-        <p>Marking a constructor with <tt>explicit</tt> has semantics
-        even for a constructor with zero or several parameters:
-        Such a constructor cannot be used with list-initialization
-        in a copy-initialization context, see 13.3.1.7 [over.match.list]. The
-        standard library apparently has not been reviewed for
-        marking non-single-parameter constructors as <tt>explicit</tt>.</p>
-<p><b>Suggestion</b></p>
-        <p>Consider marking zero-parameter and multi-parameter
-        constructors <tt>explicit</tt> in classes that have at least one
-        constructor marked <tt>explicit</tt> and that do not have an
-        initializer-list constructor.</p>
-
-<p><b>Notes</b></p>
-        <p>Robert Klarer to address this one.</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="1154"></a>1154. <tt>complex</tt> should accept integral types</h3>
-<p><b>Section:</b> 26.4 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-04</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p><b>Addresses FR 35</b></p>
-
-<p><b>Description</b></p>
-        <p>Instantiations of the class
-        template <tt>complex&lt;&gt;</tt> have to be allowed for integral
-        types, to reflect existing practice and ISO standards
-        (LIA-III).</p>
-        
-<p><b>Suggestion</b></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.8.13 [specialized.algorithms]/1 says:
+</p>
 
-<p><b>Proposed resolution:</b></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. &#8212;<i>end note</i>]
+</blockquote>
 
-<hr>
-<h3><a name="1155"></a>1155. Reference should be to C99</h3>
-<p><b>Section:</b> C.2 [diff.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-25</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#diff.library">active issues</a> in [diff.library].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#diff.library">issues</a> in [diff.library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
+<p>
+[..]
+</p>
 
-<p><b>Addresses FR 38</b></p>
+<pre>void X::deallocate(pointer p, size_type n);
+</pre>
 
-<p><b>Description</b></p>
-        <p>What is ISO/IEC 1990:9899/DAM
-        1? My guess is that's a typo for ISO/IEC
-        9899/Amd.1:1995 which I'd
-        have expected to be referenced here (the tables
-        make reference to things
-        which were introduced by Amd.1).</p>
-<p><b>Suggestion</b></p>
-        <p>One need probably a reference
-        to the document which introduce <tt>char16_t</tt> and
-        <tt>char32_t</tt> in C (ISO/IEC TR 19769:2004?).</p>
-<p><b>Notes</b></p>
-<p>Create issue. Document in question should be C99, not C90+amendment1. The 
-    rest of the section requires careful review for completeness. Example &lt;cstdint&gt; 
-    18.4.1 [cstdint.syn]. Assign to C liasons.</p>
+<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>
@@ -30002,205 +25735,227 @@ explicit to avoid treatment as initializer-list constructor</h3>
 
 
 <hr>
-<h3><a name="1156"></a>1156. Constraints on bitmask and enumeration types to be tightened</h3>
-<p><b>Section:</b> 17.5.2.1.2 [enumerated.types], 17.5.2.1.3 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-25</p>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-09-20  <b>Last modified:</b> 2009-09-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> and to an inconsistency of requirements on keys in ordered and
+unordered associative
+containers:
+</p>
 
-<p><b>Addresses UK 165</b></p>
-
-<p><b>Description</b></p>
-        <p>Constraints on
-        bitmask and enumeration types were supposed to be tightened
-        up as part of the motivation for the <tt>constexpr</tt> feature -
-        see paper
-        <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf">N2235</a>
-        for details</p>
-<p><b>Suggestion</b></p>
-        <p>Adopt wording in line with the motivation
-        described in
-        <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf">N2235</a></p>
-<p><b>Notes</b></p>
-        <p>Robert Klarer to review</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
+<blockquote>
+<p>
+1) <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/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="http://www.open-std.org/jtc1/sc22/wg21/docs/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>
 
-<hr>
-<h3><a name="1157"></a>1157. Local types can now instantiate templates</h3>
-<p><b>Section:</b> 17.6.3.2.1 [namespace.std] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-28</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></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><b>Addresses UK 175</b></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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> did for the ordered associative containers also for the unordered
+containers.
+</p>
+</blockquote>
 
-<p><b>Description</b></p>
-        <p>Local types can
-        now be used to instantiate templates, but don't have
-        external linkage.</p>
-<p><b>Suggestion</b></p>
-        <p>Remove the reference to external linkage.</p>
 
-<p><b>Notes</b></p>
-<p>We accept the proposed solution. Martin will draft an issue.</p>
+<p><b>Proposed resolution:</b></p>
 
-<p><i>[
-2009-07-28 Alisdair provided wording.
-]</i></p>
 
 
 
 
-<p><b>Proposed resolution:</b></p>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#list.ops">active issues</a> in [list.ops].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-17.6.3.2.1 [namespace.std]
+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>
-Strike "of external linkage" in p1 and p2:
+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>
--1- The behavior of a C++ program is undefined if it adds declarations or
-definitions to namespace <tt>std</tt> or to a namespace within namespace <tt>std</tt>
-unless otherwise specified. A program may add a concept map for any
-standard library concept or a template specialization for any standard
-library template to namespace <tt>std</tt> only if the declaration depends on a
-user-defined type <del>of external linkage</del> and the specialization meets the
-standard library requirements for the original template and is not
-explicitly prohibited.<sup>179</sup>
+<i>Requires</i>: both the list and the argument list shall be sorted
+according to operator&lt; or comp.
 </p>
-
 <p>
--2- The behavior of a C++ program is undefined if it declares
+<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>
-<ul>
-<li>
-an explicit specialization of any member function of a standard library
-class template, or
-</li>
-<li>
-an explicit specialization of any member function template of a standard
-library class or class template, or
-</li>
-<li>
-an explicit or partial specialization of any member class template of a
-standard library class or class template.
-</li>
-</ul>
 <p>
-A program may explicitly instantiate a template defined in the standard
-library only if the declaration depends on the name of a user-defined
-type <del>of external linkage</del> and the instantiation meets the standard
-library requirements for the original template.
+<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="1158"></a>1158. Encouragement to use monotonic clock</h3>
-<p><b>Section:</b> 30.2.4 [thread.req.timing] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-05</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="1216"></a>1216. LWG 1066 Incomplete?</h3>
+<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-09-25  <b>Last modified:</b> 2009-10-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
+<p>
+LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a> adds <tt>[[noreturn]]</tt> to a bunch of things.
+It doesn't add it to <tt>rethrow_nested()</tt>, which seems like an obvious
+candidate. I've made the changes indicated in the issue, and haven't
+changed <tt>rethrow_nested()</tt>.
+</p>
 
-<p><b>Addresses UK 322, US 96</b></p>
+<p><i>[
+2009 Santa Cruz:
+]</i></p>
 
-<p><b>Description</b></p>
-        <p>Not all systems
-        can provide a monotonic clock. How are they expected to
-        treat a _for function?</p>
-<p><b>Suggestion</b></p>
-        <p>Add at least a note explaining the intent
-        for systems that do not support a monotonic clock.</p>
 
-<p><b>Notes</b></p>
-<p>Create an issue, together with UK 96. Note that the specification as is 
-    already allows a non-monotonic clock due to the word &#8220;should&#8221; rather than 
-    &#8220;shall&#8221;. If this wording is kept, a footnote should be added to make the 
-    meaning clear.</p>
+<blockquote>
+Move to Ready.
+</blockquote>
 
-<p><i>[ 2009-06-29 Beman provided a proposed resolution. ] </i></p>
-    
 
 
 <p><b>Proposed resolution:</b></p>
+<p>
+Add <tt>[[noreturn]]</tt> to <tt>rethrow_nested()</tt> in 18.8.6 [except.nested].
+</p>
 
-<p><i>Change Timing specifications 30.2.4 [thread.req.timing] as indicated:</i></p>
 
-<p>The member functions whose names end in <tt>_for</tt> take an argument that
-specifies a relative time. Implementations
-<del>should</del> <ins>are encouraged but not required to</ins> use a
-monotonic clock to measure time for these functions.</p>
 
 
 
+<hr>
+<h3><a name="1218"></a>1218. mutex destructor synchronization</h3>
+<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30  <b>Last modified:</b> 2009-09-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+If an object <tt>*o</tt> contains a mutex <tt>mu</tt> and a
+correctly-maintained reference count <tt>c</tt>, is the following code
+safe?
+</p>
+
+<blockquote><pre>o-&gt;mu.lock();
+bool del = (--(o-&gt;c) == 0);
+o-&gt;mu.unlock();
+if (del) { delete o; }
+</pre></blockquote>
+
+<p>
+If the implementation of <tt>mutex::unlock()</tt> can touch the mutex's
+memory after the moment it becomes free, this wouldn't be safe, and
+"Construction and destruction of an object of a Mutex type need not be
+thread-safe" 30.4.1 [thread.mutex.requirements] may imply that
+it's not safe. Still, it's useful to allow mutexes to guard reference
+counts, and if it's not allowed, users are likely to write bugs.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
 
 
 
 <hr>
-<h3><a name="1159"></a>1159. Unclear spec for <tt>resource_deadlock_would_occur</tt></h3>
+<h3><a name="1219"></a>1219. unique_lock::lock and resource_deadlock_would_occur</h3>
 <p><b>Section:</b> 30.4.3.2.2 [thread.lock.unique.locking] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-04</p>
+ <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30  <b>Last modified:</b> 2009-09-30</p>
 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.lock.unique.locking">active issues</a> in [thread.lock.unique.locking].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.lock.unique.locking">issues</a> in [thread.lock.unique.locking].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 327, UK 328</b></p>
-
-<p><b>UK 327 Description</b></p>
-        <p>Not clear what
-        the specification for error condition
-        <tt>resource_deadlock_would_occur</tt> means. It is perfectly
-        possible for this thread to own the mutex without setting
-        owns to true on this specific lock object. It is also
-        possible for lock operations to succeed even if the thread
-        does own the mutex, if the mutex is recursive. Likewise, if
-        the mutex is not recursive and the mutex has been locked
-        externally, it is not always possible to know that this
-        error condition should be raised, depending on the host
-        operating system facilities. It is possible that 'i.e.' was
-        supposed to be 'e.g.' and that suggests that recursive
-        locks are not allowed. That makes sense, as the
-        exposition-only member owns is boolean and not a integer to
-        count recursive locks.</p>
-        
-<p><b>UK 327 Suggestion</b></p>
-        <p>Add a precondition <tt>!owns</tt>. Change the 'i.e.'
-        in the error condition to be 'e.g.' to allow for this
-        condition to propogate deadlock detection by the host OS.</p>
-<p><b>UK 327 Notes</b></p>
-<p>Create an issue. Assigned to Lawrence Crowl. Note: not sure what try_lock 
-    means for recursive locks when you are the owner. POSIX has language on 
-    this, which should ideally be followed. Proposed fix is not quite right, for 
-    example, try_lock should have different wording from lock.</p>
-
-<p><b>UK 328 Description</b></p>
-
-        <p>There is a missing precondition that <tt>owns</tt>
-        is true, or an <tt>if(owns)</tt> test is missing from the effect
-        clause</p>
-<p><b>UK 328 Suggestion</b></p>
-        <p>Add a
-        precondition that <tt>owns == true</tt>. Add an error condition to
-        detect a violation, rather than yield undefined behaviour.</p>
-<p><b>UK 328 Notes</b></p>
-<p>Handle in same issue as UK 327. Also uncertain that the proposed resolution 
-    is the correct one.</p>
-
-    
+<p>
+<tt>unique_lock::lock</tt> and friends raise
+"<tt>resource_deadlock_would_occur</tt> -- if the current thread already
+owns the mutex (i.e., on entry, <tt>owns</tt> is <tt>true</tt>)."  1)
+The current thread owning a mutex is not the same as any particular
+<tt>unique_lock::owns</tt> being <tt>true</tt>. 2) There's no need to
+raise this exception for a <tt>recursive_mutex</tt> if <tt>owns</tt> is
+<tt>false</tt>. 3) If <tt>owns</tt> is true, we need to raise some
+exception or the unique_lock will lose track of whether to unlock itself
+on destruction, but "deadlock" isn't it. For (3), s/bool owns/int
+ownership_level/ would fix it.
+</p>
 
 
 <p><b>Proposed resolution:</b></p>
@@ -30210,86 +25965,79 @@ monotonic clock to measure time for these functions.</p>
 
 
 <hr>
-<h3><a name="1160"></a>1160. <tt>future_error</tt> public constructor is 'exposition only'</h3>
-<p><b>Section:</b> 30.6.3 [futures.future_error] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1220"></a>1220. What does condition_variable wait on?</h3>
+<p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30  <b>Last modified:</b> 2009-11-06</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition">active issues</a> in [thread.condition].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition">issues</a> in [thread.condition].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 331</b></p>
-
-<p><b>Description</b></p>
-        <p>Not clear what
-        it means for a public constructor to be 'exposition only'.
-        If the intent is purely to support the library calling this
-        constructor then it can be made private and accessed
-        through friendship. Otherwise it should be documented for
-        public consumption.</p>
-<p><b>Suggestion</b></p>
-        <p>Declare the constructor as private with a
-        note about intended friendship, or remove the
-        exposition-only comment and document the semantics.</p>
-<p><b>Notes</b></p>
-<p>Create an issue. Assigned to Detlef. Suggested resolution probably makes 
-    sense.</p>
+<p>
+"Class <tt>condition_variable</tt> provides a condition variable that can only
+wait on an object of type <tt>unique_lock</tt>" should say "...object of type
+<tt>unique_lock&lt;mutex&gt;</tt>"
+</p>
 
 <p><i>[
-2009-07 Frankfurt
+2009-11-06 Howard adds:
 ]</i></p>
 
 
 <blockquote>
-Pending a paper from Anthony Williams / Detleff Volleman.
+Moved to Tentatively Ready after 5 positive votes on c++std-lib.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
+<p>
+Change 30.5 [thread.condition], p1:
+</p>
+
+<blockquote>
+Condition variables provide synchronization primitives used to block a
+thread until notified by some other thread that some condition is met or
+until a system time is reached. Class <tt>condition_variable</tt>
+provides a condition variable that can only wait on an object of type
+<tt>unique_lock<ins>&lt;mutex&gt;</ins></tt>, allowing maximum
+efficiency on some platforms. Class <tt>condition_variable_any</tt>
+provides a general condition variable that can wait on objects of
+user-supplied lock types.
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="1161"></a>1161. Unnecessary <tt>unique_future</tt> limitations</h3>
-<p><b>Section:</b> 30.6.5 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.unique_future">active issues</a> in [futures.unique_future].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1221"></a>1221. condition_variable wording</h3>
+<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30  <b>Last modified:</b> 2009-09-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
+<p>
+30.5.1 [thread.condition.condvar] says:
+</p>
 
-<p><b>Addresses UK 336</b></p>
-
-<p><b>Description</b></p>
-
-        <p>It is possible
-        to transfer ownership of the asynchronous result from one
-        unique_future instance to another via the move-constructor.
-        However, it is not possible to transfer it back, and nor is
-        it possible to create a default-constructed unique_future
-        instance to use as a later move target. This unduly limits
-        the use of <tt>unique_future</tt> in code. Also, the lack of a
-        move-assignment operator restricts the use of <tt>unique_future</tt>
-        in containers such as <tt>std::vector</tt> - <tt>vector::insert</tt> requires
-        move-assignable for example.</p>
-<p><b>Suggestion</b></p>
-        <p>Add a default constructor with the
-        semantics that it creates a <tt>unique_future</tt> with no
-        associated asynchronous result. Add a move-assignment
-        operator which transfers ownership.</p>
-<p><b>Notes</b></p>
-<p>Create an issue. Detlef will look into it.</p>
-
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
-
-
 <blockquote>
-Pending a paper from Anthony Williams / Detleff Volleman.
+<pre>~condition_variable();
+</pre>
+<blockquote>
+<i>Precondition:</i> There shall be no thread blocked on <tt>*this</tt>.
+[<i>Note:</i> That is, all threads shall have been notified; they may
+subsequently block on the lock specified in the wait. Beware that
+destroying a <tt>condition_variable</tt> object while the corresponding
+predicate is <tt>false</tt> is likely to lead to undefined behavior.
+&#8212; <i>end note</i>]
+</blockquote>
 </blockquote>
 
+<p>
+The text hasn't introduced the notion of a "corresponding predicate"
+yet.
+</p>
 
 
 <p><b>Proposed resolution:</b></p>
@@ -30299,35 +26047,90 @@ Pending a paper from Anthony Williams / Detleff Volleman.
 
 
 <hr>
-<h3><a name="1162"></a>1162. <tt>shared_future</tt> should support an efficient move constructor</h3>
-<p><b>Section:</b> 30.6.6 [future.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#future.shared_future">active issues</a> in [future.shared_future].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#future.shared_future">issues</a> in [future.shared_future].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1222"></a>1222. condition_variable incorrect effects for exception safety</h3>
+<p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30  <b>Last modified:</b> 2009-09-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition">active issues</a> in [thread.condition].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition">issues</a> in [thread.condition].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
+<p>
+30.5.1 [thread.condition.condvar] says:
+</p>
 
-<p><b>Addresses UK 337</b></p>
+<blockquote>
+<pre>void wait(unique_lock&lt;mutex&gt;&amp; lock);
+</pre>
+<blockquote>
+<p>...</p>
+<p>
+<i>Effects:</i>
+</p>
+<ul>
+<li>...</li>
+<li>
+If the function exits via an exception, <tt>lock.unlock()</tt> shall be
+called prior to exiting the function scope.
+</li>
+</ul>
+</blockquote>
+</blockquote>
 
-<p><b>Description</b></p>
-        <p><tt>shared_future</tt>
-        should support an efficient move constructor that can avoid
-        unnecessary manipulation of a reference count, much like
-        <tt>shared_ptr</tt></p>
-<p><b>Suggestion</b></p>
-        <p>Add a move constructor</p>
-<p><b>Notes</b></p>
-<p>Create an issue. Detlef will look into it.</p>
+<p>
+Should that be <tt>lock.lock()</tt>?
+</p>
 
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
 
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Change 30.5.1 [thread.condition.condvar] p10:
+</p>
 
 <blockquote>
-Pending a paper from Anthony Williams / Detleff Volleman.
+<pre>void wait(unique_lock&lt;mutex&gt;&amp; lock);
+</pre>
+<blockquote>
+<p>...</p>
+<p>
+<i>Effects:</i>
+</p>
+<ul>
+<li>...</li>
+<li>
+If the function exits via an exception, <tt>lock.<del>un</del>lock()</tt> shall be
+called prior to exiting the function scope.
+</li>
+</ul>
+</blockquote>
 </blockquote>
 
+<p>
+And make a similar change in p16, and in 30.5.2 [thread.condition.condvarany],
+p8 and p13.
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="1223"></a>1223. condition_variable_any lock matching?</h3>
+<p><b>Section:</b> 30.5.2 [thread.condition.condvarany] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30  <b>Last modified:</b> 2009-09-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvarany">active issues</a> in [thread.condition.condvarany].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvarany">issues</a> in [thread.condition.condvarany].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+For <tt>condition_variable_any</tt>, must all lock arguments to concurrent wait calls
+"match" in some way, similar to the requirement in
+30.5.1 [thread.condition.condvar] that <tt>lock.mutex()</tt> returns the same
+value for each of the lock arguments supplied by all concurrently
+waiting threads (via <tt>wait</tt> or <tt>timed_wait</tt>)?
+</p>
+
 
 
 <p><b>Proposed resolution:</b></p>
@@ -30337,52 +26140,16 @@ Pending a paper from Anthony Williams / Detleff Volleman.
 
 
 <hr>
-<h3><a name="1163"></a>1163. <tt>shared_future</tt> is inconsistent with <tt>shared_ptr</tt></h3>
-<p><b>Section:</b> 30.6.6 [future.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#future.shared_future">active issues</a> in [future.shared_future].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#future.shared_future">issues</a> in [future.shared_future].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1224"></a>1224. condition_variable_any support for recursive mutexes?</h3>
+<p><b>Section:</b> 30.5.2 [thread.condition.condvarany] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30  <b>Last modified:</b> 2009-09-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvarany">active issues</a> in [thread.condition.condvarany].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvarany">issues</a> in [thread.condition.condvarany].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p><b>Addresses UK 338</b></p>
-
-<p><b>Description</b></p>
-
-        <p><tt>shared_future</tt> is currently
-        CopyConstructible, but not CopyAssignable. This is
-        inconsistent with <tt>shared_ptr</tt>, and will surprise users.
-        Users will then write work-arounds to provide this
-        behaviour. We should provide it simply and efficiently as
-        part of shared_future. Note that since the shared_future
-        member functions for accessing the state are all declared
-        const, the original usage of an immutable shared_future
-        value that can be freely copied by multiple threads can be
-        retained by declaring such an instance as "<tt>const
-        shared_future</tt>".</p>
-<p><b>Suggestion</b></p>
-        <p>Remove "=delete"
-        from the copy-assignment operator of shared_future. Add a
-        move-constructor <tt>shared_future(shared_future&amp;&amp;
-        rhs)</tt>, and a move-assignment operator <tt>shared_future&amp;
-        operator=(shared_future&amp;&amp; rhs)</tt>. The postcondition
-        for the copy-assignment operator is that <tt>*this</tt> has the same
-        associated state as <tt>rhs</tt>. The postcondition for the
-        move-constructor and move assignment is that <tt>*this</tt> has the
-        same associated as <tt>rhs</tt> had before the
-        constructor/assignment call and that <tt>rhs</tt> has no associated
-        state.</p>
-<p><b>Notes</b></p>
-<p>Create an issue. Detlef will look into it.</p>
-
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
-
-
-<blockquote>
-Pending a paper from Anthony Williams / Detleff Volleman.
-</blockquote>
+<p>
+For <tt>condition_variable_any</tt>, are recursive mutexes allowed? (I think "no")
+</p>
 
 
 
@@ -30393,485 +26160,516 @@ Pending a paper from Anthony Williams / Detleff Volleman.
 
 
 <hr>
-<h3><a name="1165"></a>1165. Unneeded promise move constructor</h3>
-<p><b>Section:</b> 30.6.4 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="1225"></a>1225. C++0x result_of issue </h3>
+<p><b>Section:</b> 20.7.4 [func.ret] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Sebastian Gesemann <b>Opened:</b> 2009-10-05  <b>Last modified:</b> 2009-10-17</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.ret">issues</a> in [func.ret].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
+<p>
+I think the text about <tt>std::result_of</tt> could be a little more precise.
+Quoting from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>...
+</p>
 
-<p><b>Addresses UK 343</b></p>
-
-<p><b>Description</b></p>
-        <p>The move constructor of a std::promise
-        object does not need to allocate any memory, so the
-        move-construct-with-allocator overload of the constructor
-        is superfluous.</p>
-<p><b>Suggestion</b></p>
-        <p>Remove the
-        constructor with the signature <tt>template &lt;class
-        Allocator&gt; promise(allocator_arg_t, const Allocator&amp;
-        a, promise&amp; rhs);</tt></p>
-<p><b>Notes</b></p>
-<p>Create an issue. Detlef will look into it. Will solicit feedback from Pablo. 
-    Note that &#8220;rhs&#8221; argument should also be an rvalue reference in any case.</p>
+<blockquote>
+<p>
+20.7.4 [func.ret] Function object return types
+</p>
 
-<p><i>[
-2009-07 Frankfurt
-]</i></p>
+<pre>template&lt;class&gt; class result_of;
 
+template&lt;class Fn, class... ArgTypes&gt;
+class result_of&lt;Fn(ArgTypes...)&gt; {
+public:
+  typedef <i>see below</i> type;
+};
+</pre>
 
-<blockquote>
-Pending a paper from Anthony Williams / Detleff Volleman.
+<p>
+Given an rvalue <tt>fn</tt> of type <tt>Fn</tt> and values <tt>t1, t2,
+..., tN</tt> of types <tt>T1, T2, ... TN</tt> in <tt>ArgTypes</tt>
+respectivly, the <tt>type</tt> member is the result type of the
+expression <tt>fn(t1,t2,...,tN)</tt>. the values <tt>ti</tt> are lvalues
+when the corresponding type <tt>Ti</tt> is an lvalue-reference type, and
+rvalues otherwise.
+</p>
 </blockquote>
 
+<p>
+This text doesn't seem to consider lvalue reference types for <tt>Fn</tt>.
+Also, it's not clear whether this class template can be used for
+"SFINAE" like <tt>std::enable_if</tt>. Example:
+</p>
 
+<blockquote><pre>template&lt;typename Fn, typename... Args&gt;
+typename std::result_of&lt;Fn(Args...)&gt;::type
+apply(Fn &amp;&amp; fn, Args &amp;&amp; ...args)
+{
+  // Fn may be an lvalue reference, too
+  return std::forward&lt;Fn&gt;(fn)(std::forward&lt;Args&gt;(args)...);
+}
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
+<p>
+Either <tt>std::result_of&lt;...&gt;</tt> can be instantiated and simply may not have
+a typedef "<tt>type</tt>" (--&gt;SFINAE) or instantiating the class template for
+some type combinations will be a "hard" compile-time error.
+</p>
 
 
+<p><b>Proposed resolution:</b></p>
 
+<p><i>[
+These changes will require compiler support
+]</i></p>
 
 
-<hr>
-<h3><a name="1166"></a>1166. Allocator-specific move/copy break model of move-constructor and
-        move-assignment</h3>
-<p><b>Section:</b> X [allocator.propagation], X [allocator.propagation.map], 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-04</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
+<p>
+Change 20.7.4 [func.ret]:
+</p>
 
-<p><b>Addresses US 77</b></p>
+<blockquote><pre>template&lt;class&gt; class result_of; // <i>undefined</i>
 
-<p><b>Description</b></p>
-        <p>Allocator-specific move and copy behavior for containers
-        (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>) complicates a little-used and already-complicated
-        portion of the standard library (allocators), and breaks
-        the conceptual model of move-constructor and
-        move-assignment operations on standard containers being
-        efficient operations. The extensions for allocator-specific
-        move and copy behavior should be removed from the working
-        paper.</p>
-        <p>With the
-        introduction of rvalue references, we are teaching
-        programmers that moving from a standard container (e.g., a
-        <tt>vector&lt;string&gt;</tt>) is an efficient, constant-time
-        operation. The introduction of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a> removed that
-        guarantee; depending on the behavior of four different
-        traits (20.8.4), the complexity of copy and move operations
-        can be constant or linear time. This level of customization
-        greatly increases the complexity of standard containers,
-        and benefits only a tiny fraction of the C++ community.</p>
-<p><b>Suggestion</b></p>
+template&lt;class Fn, class... ArgTypes&gt;
+class result_of&lt;Fn(ArgTypes...)&gt; {
+public:
+  <del>typedef</del> <i>see below</i> <del>type;</del>
+};
+</pre>
 
-        <p>Remove 20.8.4.</p>
-        
-        <p>Remove 20.8.5.</p>
-        
-        <p>Remove all references to the facilities in
-        20.8.4 and 20.8.5 from clause 23.</p>
+<p><del>
+Given an rvalue <tt>fn</tt> of type <tt>Fn</tt> and values <tt>t1, t2,
+..., tN</tt> of types <tt>T1, T2, ... TN</tt> in <tt>ArgTypes</tt>
+respectivly, the <tt>type</tt> member is the result type of the
+expression <tt>fn(t1,t2,...,tN)</tt>. the values <tt>ti</tt> are lvalues
+when the corresponding type <tt>Ti</tt> is an lvalue-reference type, and
+rvalues otherwise.
+</del></p>
+
+<p>
+<ins>The class template <tt>result_of</tt> shall meet the requirements of a
+<i>TransformationTrait</i>: Given the types <tt>Fn</tt>, <tt>T1</tt>, <tt>T2</tt>, ..., <tt>TN</tt> every
+template specialization <tt>result_of&lt;Fn(T1,T2,...,TN)&gt;</tt> shall define the
+member typedef type equivalent to <tt>decltype(<i>RE</i>)</tt> if and only if
+the expression <tt><i>RE</i></tt>
+</ins></p>
 
+<blockquote><pre><ins>
+value&lt;Fn&gt;() ( value&lt;T1&gt;(), value&lt;T2&gt;(), ... value&lt;TN&gt;()  )
+</ins></pre></blockquote>
 
+<p><ins>
+would be well-formed. Otherwise, there shall be no member typedef
+<tt>type</tt> defined.
+</ins></p>
 
+</blockquote>
+ 
+<p><i>[
+The <tt>value&lt;&gt;</tt> helper function is a utility Daniel Krügler
+proposed in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2958.html">N2958</a>.
+]</i></p>
 
-<p><b>Proposed resolution:</b></p>
 
 
 
 
 
 <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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Cosmin Truta <b>Opened:</b> 2009-07-04  <b>Last modified:</b> 2009-07-07</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="1226"></a>1226. Incomplete changes of #890</h3>
+<p><b>Section:</b> 30.6.2 [futures.errors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-10-05  <b>Last modified:</b> 2009-10-27</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</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>±HUGE_VALF</code>,
-<code>±HUGE_VAL</code> and <code>±HUGE_VALL</code>, respectively.
-On the other hand, the result of <code>num_get</code> conversion of such
-out-of-range floating-point values results in the most positive/negative
-representable value.
-Although many C library implementations do implement <code>HUGE_VAL</code>
-(etc.) as the highest representable (which is, usually, the infinity), 
-this
-isn't required by the C standard. The C library specification makes no
-statement regarding the value of <code>HUGE_VAL</code> and friends, which
-potentially raises the same compatibility issue as in the above case of
-unsigned integers.
-In addition, neither C nor C++ define symbolic constants for the maximum
-representable floating-point values (they only do so only for the maximum
-representable <i>finite</i> floating-point values), which raises a 
-usability
-issue (it would be hard for the programmer to check the result of
-<code>num_get</code> against overflow).
+Defect issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a> overlooked to adapt the <tt>future_category</tt> from
+30.6.1 [futures.overview] and 30.6.2 [futures.errors]:
 </p>
+
+<blockquote><pre>extern const error_category* const future_category;
+</pre></blockquote>
+
 <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.
+which should be similarly transformed into function form.
 </p>
 
+<p><i>[
+2009-10-27 Howard:
+]</i></p>
+
+
+<blockquote>
+Moved to Tentatively Ready after 5 positive votes on c++std-lib.
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
 <p>
-Change 22.4.2.1.2 [facet.num.get.virtuals] as follows:
+Change in 30.6.1 [futures.overview], header <tt>&lt;future&gt;</tt> synopsis:
 </p>
-<blockquote>
+
+<blockquote><pre><del>extern</del> const error_category<ins>&amp;</ins><del>* const</del> future_category<ins>()</ins>;
+</pre></blockquote>
+</li>
+
+<li>
 <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>:
+Change in 30.6.2 [futures.errors]:
 </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>
+
+<blockquote><pre><del>extern</del> const error_category<ins>&amp;</ins><del>* const</del> future_category<ins>()</ins>;
+</pre>
+
+<blockquote>
 <p>
-The numeric value to be stored can be one of:
+<del>1- <tt>future_category</tt> shall point to a statically initialized object
+of a type derived from class <tt>error_category</tt>.</del>
 </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>
+<ins>1- <i>Returns:</i> A reference to an object of a type
+derived from class <tt>error_category</tt>.</ins>
 </p>
 </blockquote>
 
+<pre>constexpr error_code make_error_code(future_errc e);
+</pre>
+
+<blockquote>
+3 <i>Returns:</i> <tt>error_code(static_cast&lt;int&gt;(e),
+<del>*</del>future_category<ins>()</ins>)</tt>.
+</blockquote>
+
+<pre>constexpr error_code make_error_condition(future_errc e);
+</pre>
+
+<blockquote>
+4 <i>Returns:</i> <tt>error_condition(static_cast&lt;int&gt;(e),
+<del>*</del>future_category<ins>()</ins>)</tt>.
+</blockquote>
+</blockquote>
+</li>
+</ol>
 
 
 
 
 
 <hr>
-<h3><a name="1170"></a>1170. String <i>char-like types</i> no longer PODs</h3>
-<p><b>Section:</b> 21.1 [strings.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-06-22  <b>Last modified:</b> 2009-07-28</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="1227"></a>1227. <tt>&lt;bitset&gt;</tt> synopsis overspecified</h3>
+<p><b>Section:</b> 20.3.7 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Bo Persson <b>Opened:</b> 2009-10-05  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p>Prior to the introduction of constant expressions into the library, 
-<tt>basic_string</tt> elements had to be POD types, and thus had to be both trivially 
-copyable and standard-layout. This ensured that they could be memcpy'ed and 
-would be compatible with other libraries and languages, particularly the C 
-language and its library.</p>
 <p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>,
-Constant Expressions in the Standard Library Revision 2, changed the 
-requirement in 21/1 from "POD type" to "literal type". That change had the 
-effect of removing the trivially copyable and standard-layout requirements from 
-<tt>basic_string</tt> elements.</p>
-<p>This means that <tt>basic_string</tt> elements no longer are guaranteed to be 
-memcpy'able, and are no longer guaranteed to be standard-layout types:</p>
-<blockquote>
-  <p>3.9/p2 and 3.9/p3 both make it clear that a "trivially copyable type" is 
-  required for memcpy to be guaranteed to work.</p>
-  <p>Literal types (3.9p12) may have a non-trivial copy assignment operator, and 
-  that violates the trivially copyable requirements given in 9/p 6, bullet item 
-  2. </p>
-  <p>Literal types (3.9p12) have no standard-layout requirement, either.</p>
-</blockquote>
-<p>This situation probably arose because the wording for "Constant Expressions 
-in the Standard Library" was in process at the same time the C++ POD 
-deconstruction wording was in process. </p>
-<p>Since trivially copyable types meet the C++0x requirements for literal types, 
-and thus work with constant expressions, it seems an easy fix to revert the 
-<tt>basic_string</tt> element wording to its original state.</p>
+The resolutions to some library defect reports, like <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>
+requires that <tt>#includes</tt> in each synopsis should be taken
+literally. This means that the <tt>&lt;bitset&gt;</tt> header now
+<em>must</em> include <tt>&lt;stdexcept&gt;</tt>, even though none of the
+exceptions are mentioned in the <tt>&lt;bitset&gt;</tt> header.
+</p>
+<p>
+Many other classes are required to throw exceptions like
+<tt>invalid_argument</tt> and <tt>out_of_range</tt>, without explicitly
+including <tt>&lt;stdexcept&gt;</tt> in their synopsis. It is totally
+possible for implementations to throw the needed exceptions from utility
+functions, whose implementations are not visible in the headers.
+</p>
+<p>
+I propose that <tt>&lt;stdexcept&gt;</tt> is removed from the
+<tt>&lt;bitset&gt;</tt> header.
+</p>
+
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
 
- <p><i>[
- 2009-07-28 Alisdair adds:
- ]</i></p>
 
- 
 <blockquote>
-When looking for any resolution for this issue, consider the definition of
-"character container type" in 17.3.4 [defns.character.container].  This
-does require the character type to be a POD, and this term is used in a
-number of places through clause 21 and 28. This suggests the PODness
-constraint remains, but is much more subtle than before.  Meanwhile, I
-suspect the change from POD type to literal type was intentional with
-the assumption that trivially copyable types with
-non-trivial-but-constexpr constructors should serve as well.  I don't
-believe the current wording offers the right guarantees for either of
-the above designs.
+Moved to Ready.
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
+<p>
+Change 20.3.7 [template.bitset]:
+</p>
 
-<p><i>Change General 21.1 [strings.general] as indicated:</i></p>
-<blockquote>
-<p>This Clause describes components for manipulating sequences of any <del>literal</del> <ins>POD</ins> 
-(3.9) type. In this Clause
-such types are called <i>char-like types</i>, and objects of char-like types are 
-called <i>char-like objects</i> or simply <i>characters</i>.</p>
-</blockquote>
-
+<blockquote><pre>#include &lt;cstddef&gt;        // for size_t
+#include &lt;string&gt;
+<del>#include &lt;stdexcept&gt;      // for invalid_argument,</del>
+                          <del>// out_of_range, overflow_error</del>
+#include &lt;iosfwd&gt;         // for istream, ostream
+namespace std {
+...
+</pre></blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="1171"></a>1171. duration types shoud be literal</h3>
-<p><b>Section:</b> 20.9.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-06  <b>Last modified:</b> 2009-07-07</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.duration">active issues</a> in [time.duration].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration">issues</a> in [time.duration].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="1228"></a>1228. User-specialized nothrow type traits</h3>
+<p><b>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-10-07  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The <tt>duration</tt> types in 20.9.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><b>Proposed resolution:</b></p>
-<p>
-Add <tt>constexpr</tt> to declaration of following functions and constructors:
-</p>
-<p>
-p1 20.9 [time]
+According to p1 20.6.2 [meta.type.synop]:
 </p>
 
 <blockquote>
+The behavior of a program that adds specializations for any of the class
+templates defined in this subclause is undefined unless otherwise
+specified.
+</blockquote>
+
 <p>
-<b>Header <tt>&lt;chrono&gt;</tt> synopsis</b>
+I believe we should 'otherwise specify' for the nothrow traits, are
+these are exactly the use cases where the end user actually has more
+information than the compiler.
 </p>
 
-<p><i>[Draughting note - observe switch to pass-by-value to support constexpr]</i></p>
+<p><i>[
+2009-10 Santa Cruz:
+]</i></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+(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> 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-(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> 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*(<del>const</del> duration&lt;Rep1, Period&gt;<del>&amp;</del> d, <del>const</del> Rep2<del>&amp;</del> 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*(<del>const</del> Rep1<del>&amp;</del> s, <del>const</del> duration&lt;Rep2, Period&gt;<del>&amp;</del> 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/(<del>const</del> duration&lt;Rep1, Period&gt;<del>&amp;</del> d, <del>const</del> Rep2<del>&amp;</del> s);
-template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
-   typename common_type&lt;Rep1, Rep2&gt;::type
-   <ins>constexpr</ins> operator/(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
+<blockquote>
+Moved to Open.  Definitely need to give the users the ability to ensure
+that the traits give the right answers. Unsure we want to give them the
+ability to say this in more than one way. Believes the noexcept proposal
+already gives this.
+</blockquote>
 
-<i>// duration comparisons</i>
-template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
-   <ins>constexpr</ins> bool operator==(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
-template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
-   <ins>constexpr</ins> bool operator!=(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
-template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
-   <ins>constexpr</ins> bool operator&lt; (<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
-template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
-   <ins>constexpr</ins> bool operator&lt;=(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
-template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
-   <ins>constexpr</ins> bool operator&gt; (<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
-template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
-   <ins>constexpr</ins> bool operator&gt;=(<del>const</del>  duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
 
-<i>// duration_cast</i>
-template &lt;class ToDuration, class Rep, class Period&gt;
-   <ins>constexpr</ins> ToDuration duration_cast(<del>const</del> duration&lt;Rep, Period&gt;<del>&amp;</del> d);
-</pre>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-<b>20.9.3 [time.duration]</b>
+Add the following comment:
 </p>
 
-<pre>template &lt;class Rep, class Period = ratio&lt;1&gt;&gt;
-class duration {
-  ....
-public:
-  <i>// 20.9.3.1, construct/copy/destroy:</i>
- <ins>constexpr</ins> duration() = default;
-
- template &lt;class Rep2&gt;
-   <ins>constexpr</ins> explicit duration(const Rep2&amp; r);
- template &lt;class Rep2, class Period2&gt;
-   <ins>constexpr</ins> duration(const duration&lt;Rep2, Period2&gt;&amp; d);
-
-  <ins>constexpr</ins> duration(const duration&amp;) = default;
-
-  <i>// 20.9.3.2, observer:</i>
-  <ins>constexpr</ins> rep count() const;
+<blockquote>
+user specialization permitted to derive from <tt>std::true_type</tt> when the
+operation is known not to throw.
+</blockquote>
 
-  <i>// 20.9.3.3, arithmetic:</i>
-  <ins>constexpr</ins> duration operator+() const;
-  <ins>constexpr</ins> duration operator-() const;
-  ...
+<p>
+to the following traits in 20.6.4.3 [meta.unary.prop] Table 43 Type
+property predicates.
+</p>
 
-};
-</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.
+This may require a new Comments column
 ]</i></p>
 
 
+<blockquote><pre>has_nothrow_default_constructor
+has_nothrow_copy_constructor
+has_nothrow_assign
+</pre></blockquote>
+
 
 
 
 
 <hr>
-<h3><a name="1172"></a>1172. <tt>select_on_container_(copy|move)_construction</tt> over-constrained</h3>
-<p><b>Section:</b> 20.8.2.4 [allocator.concepts.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2009-07-08  <b>Last modified:</b> 2009-07-14</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="1231"></a>1231. <tt>weak_ptr</tt> comparisons incompletely resolved</h3>
+<p><b>Section:</b> 20.8.15.3.5 [util.smartptr.weak.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-10-10  <b>Last modified:</b> 2009-11-06</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-I believe the two functions
-<tt>select_on_container_(copy|move)_construction()</tt> are over-constrained. For
-example, the return value of the "copy" version is (see
-20.8.2.4 [allocator.concepts.members]/21):
+The
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2637.pdf">n2637</a>
+paper suggested several updates of the ordering semantics of
+<tt>shared_ptr</tt>
+and <tt>weak_ptr</tt>, among those the explicit comparison operators of <tt>weak_ptr</tt> were
+removed/deleted, instead a corresponding functor <tt>owner_less</tt> was added.
+The problem
+is that
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2637.pdf">n2637</a>
+did not clearly enough specify, how the previous wording
+parts describing
+the comparison semantics of <tt>weak_ptr</tt> should be removed.
 </p>
+
+<p><i>[
+2009-11-06 Howard adds:
+]</i></p>
+
+
 <blockquote>
-<i>Returns:</i> <tt>x</tt> if the allocator should propagate from the existing
-container to the new container on copy construction, otherwise <tt>X()</tt>.
+Moved to Tentatively Ready after 5 positive votes on c++std-lib.
 </blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
 <p>
-Consider the case where a user decides to provide an explicit concept
-map for Allocator to adapt some legacy allocator class, as he wishes to
-provide customizations that the <tt>LegacyAllocator</tt> concept map template
-does not provide.  Now, although it's true that the legacy class is
-required to have a default constructor, the user might have reasons to
-prefer a different constructor to implement
-<tt>select_on_container_copy_construction()</tt>. However, the current wording
-requires the use of the default constructor.
+Change 20.8.15.3 [util.smartptr.weak]/2 as described, the intention is to fix
+the now no longer valid
+requirement that <tt>weak_ptr</tt> is <tt>LessComparable</tt> [Note the deleted comma]:
 </p>
+
+<blockquote>
+Specializations of <tt>weak_ptr</tt> shall be <tt>CopyConstructible</tt><del>,</del>
+<ins>and</ins> <tt>CopyAssignable</tt>,
+<del>and <tt>LessThanComparable</tt>,</del> allowing their use in standard containers.
+</blockquote>
+</li>
+
+<li>
 <p>
-Moreover, it's not said explicitly that <tt>x</tt> is supposed to be the
-allocator of the existing container. A clarification would do no harm.
+In 20.8.15.3.5 [util.smartptr.weak.obs] remove the paragraphs 9-11 including prototype:
 </p>
 
+<blockquote>
+<del>template&lt;class T, class U&gt; bool operator&lt;(const weak_ptr&lt;T&gt;&amp; a, const weak_ptr&lt;U&gt;&amp; b);</del>
+
+<p>
+<del><i>Returns:</i> an unspecified value such that</del>
+</p>
+<ul>
+<li>
+<del><tt>operator&lt;</tt> is a strict weak ordering as described in 25.4;</del>
+</li>
+<li>
+<del>under the equivalence relation defined by <tt>operator&lt;</tt>, <tt>!(a
+&lt; b) &amp;&amp; !(b &lt; a)</tt>, two <tt>weak_ptr</tt> instances are
+equivalent if and only if they share ownership or are both empty.</del>
+</li>
+</ul>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Replace 20.8.2.4 [allocator.concepts.members]/21 with:
+<del><i>Throws:</i> nothing.</del>
 </p>
 
-<blockquote><pre>X select_on_container_copy_construction(const X&amp; x);
-</pre>
 <p>
--21- <i>Returns:</i> <del><tt>x</tt> if the allocator should propagate from the existing
-container to the new container on copy construction, otherwise <tt>X()</tt>.</del>
-<ins>an allocator object to be used by the new container on copy
-construction. [<i>Note:</i> <tt>x</tt> is the allocator of the existing container that
-is being copied. The most obvious choices for the return value are <tt>x</tt>, if
-the allocator should propagate from the existing container, and <tt>X()</tt>.
-<i>&#8212; end note</i>]</ins>
+<del>[<i>Note:</i> Allows <tt>weak_ptr</tt> objects to be used as keys in associative
+containers. &#8212; <i>end note</i>]</del>
 </p>
 </blockquote>
+</li>
+</ol>
+
+
+
 
+
+<hr>
+<h3><a name="1233"></a>1233. Missing <tt>unique_ptr</tt> signatures in synopsis</h3>
+<p><b>Section:</b> 20.8 [memory] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-10-11  <b>Last modified:</b> 2009-11-04</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#memory">issues</a> in [memory].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Replace 20.8.2.4 [allocator.concepts.members]/25 with:
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#296">296</a>.  Some <tt>unique_ptr</tt> signatures are missing
+from the synopsis in 20.8 [memory].
 </p>
 
-<blockquote><pre>X select_on_container_move_construction(X&amp;&amp; x);
-</pre>
+<p><i>[
+2009-11-04 Howard adds:
+]</i></p>
+
+
+<blockquote>
+Moved to Tentatively NAD Editorial.  The editor has adopted the fix.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
--25- <i>Returns:</i> <del><tt>move(x)</tt> if the allocator should propagate from the existing
-container to the new container on move construction, otherwise <tt>X()</tt>.</del>
-<ins>an allocator object to be used by the new container on move
-construction. [<i>Note:</i> <tt>x</tt> is the allocator of the existing container that
-is being moved. The most obvious choices for the return value are <tt>move(x)</tt>, if
-the allocator should propagate from the existing container, and <tt>X()</tt>.
-<i>&#8212; end note</i>]</ins>
+Add in 20.8 [memory], Header <tt>&lt;memory&gt;</tt> synopsis
+missing declarations as shown below:
 </p>
-</blockquote>
 
+<blockquote><pre>// 20.8.11 Class unique_ptr:
+template &lt;class X&gt; class default_delete;
+<ins>template&lt;class T&gt; struct default_delete&lt;T[]&gt;;</ins>
+template &lt;class X, class D = default_delete&lt;T&gt;&gt; class unique_ptr;
+<ins>template&lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt;;</ins>
+
+<ins>template&lt;class T, class D&gt; void swap(unique_ptr&lt;T, D&gt;&amp; x, unique_ptr&lt;T, D&gt;&amp; y);</ins>
+
+<ins>template&lt;class T1, class D1, class T2, class D2&gt;
+bool operator==(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);</ins>
+<ins>template&lt;class T1, class D1, class T2, class D2&gt;
+bool operator!=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);</ins>
+<ins>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);</ins>
+<ins>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);</ins>
+<ins>template&lt;class T1, class D1, class T2, class D2&gt;
+bool operator&gt;(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);</ins>
+<ins>template&lt;class T1, class D1, class T2, class D2&gt;
+bool operator&gt;=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);</ins>
+</pre></blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="1173"></a>1173. "Equivalence" wishy-washiness</h3>
-<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-07-14  <b>Last modified:</b> 2009-07-14</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2009-10-09  <b>Last modified:</b> 2009-10-13</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</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.
+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>
-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.
+Is this supposed to work? 
 </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.
+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]/11 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>
-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 ==.
+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>
 
 
@@ -30882,1197 +26680,1592 @@ referring to some ill-defined notion of equivalence when it uses ==.
 
 
 <hr>
-<h3><a name="1174"></a>1174.   type property predicates</h3>
-<p><b>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Jason Merrill <b>Opened:</b> 2009-07-16  <b>Last modified:</b> 2009-07-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="1237"></a>1237. Constrained error_code/error_condition members</h3>
+<p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-10-14  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-I've been implementing compiler support for <tt>is_standard_layout</tt>, and
-noticed a few nits about 20.6.4.3 [meta.unary.prop]:
+I'm just reflecting on the now SFINAE-constrained constructors
+and assignment operators of <tt>error_code</tt> and <tt>error_condition</tt>:
+</p>
+<p>
+These are the <em>only</em> library components that are pro-actively
+announcing that they are using <tt>std::enable_if</tt> as constraining tool,
+which has IMO several disadvantages:
 </p>
 
 <ol>
 <li>
-There's no trait for "trivially copyable type", which is now the
-property that lets you do bitwise copying of a type, and therefore seems
-useful to be able to query.  <tt>has_trivial_assign</tt> &amp;&amp;
-<tt>has_trivial_copy_constructor</tt> &amp;&amp; <tt>has_trivial_destructor</tt>
-is similar, but
-not identical, specifically with respect to const types.
+<p>
+With the availability of template default arguments and
+decltype, using <tt>enable_if</tt> in C++0x standard library, seems
+unnecessary restricting implementation freedom. E.g. there
+should be not need for a useless specification of a dummy
+default function argument, which only confuses the reader.
+A more reasonable implementation could e.g. be
+</p>
+
+<blockquote><pre>template &lt;class ErrorCodeEnum
+ class = typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type&gt;
+error_code(ErrorCodeEnum e);
+</pre></blockquote>
+
+<p>
+As currently specified, the function signatures are so unreadable,
+that errors quite easily happen, see e.g. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1229">1229</a>.
+</p>
+</li>
+
+<li>
+<p>
+We have a <em>lot</em> of constrained functions in other places, that
+now have a standard phrase that is easily understandable:
+</p>
+
+<blockquote>
+<i>Remarks:</i> This constructor/function shall participate in overload
+resolution if and only if X.
+</blockquote>
+
+<p>
+where X describes the condition. Why should these components deviate?
+</p>
 </li>
+
 <li>
-<tt>has_trivial_copy_constructor</tt> and <tt>has_trivial_assign</tt> lack the "or an
-array of such a class type" language that most other traits in that
-section, including <tt>has_nothrow_copy_constructor</tt> and <tt>has_nothrow_assign</tt>,
-have; this seems like an oversight.
+<p>
+If <tt>enable_if</tt> would <em>not</em> be explicitly specified, the standard library
+is much better prepared for the future. It would also be possible, that
+libraries with partial support for not-yet-standard-concepts could provide
+a much better diagnostic as is possible with <tt>enable_if</tt>. This again
+would allow for experimental concept implementations in the wild,
+which as a result would make concept standardization a much more
+natural thing, similar to the way as templates were standardized
+in C++.
+</p>
+
+<p>
+In summary: I consider it as a library defect that <tt>error_code</tt> and
+<tt>error_condition</tt> explicitly require a dependency to <tt>enable_if</tt> and
+do limit implementation freedom and I volunteer to prepare a
+corresponding resolution.
+</p>
 </li>
 </ol>
 
 <p><i>[
-See the thread starting with c++std-lib-24420 for further discussion.
+2009-10-18 Beman adds:
 ]</i></p>
 
 
+<blockquote>
+I support this proposed resolution, and thank Daniel for writing it up.
+</blockquote>
+
+<p><i>[
+2009-10 Santa Cruz:
+]</i></p>
+
+
+<blockquote>
+Moved to Ready.
+</blockquote>
+
 
 
 <p><b>Proposed resolution:</b></p>
-<p>
-</p>
+<p><i>[
+Should this resolution be accepted, I recommend to resolve <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1229">1229</a> as NAD
+]</i></p>
 
 
+<ol>
+<li>
+<p>
+In 19.5.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt>,
+change as indicated:
+</p>
 
+<blockquote><pre>// 19.5.2.2 constructors:
+error_code();
+error_code(int val, const error_category&amp; cat);
+template &lt;class ErrorCodeEnum&gt;
+  error_code(ErrorCodeEnum e<del>,
+    typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type * = 0</del>);
 
+// 19.5.2.3 modifiers:
+void assign(int val, const error_category&amp; cat);
+template &lt;class ErrorCodeEnum&gt;
+  <del>typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type</del><ins>error_code</ins>&amp;
+    operator=(ErrorCodeEnum e);
+void clear();
+</pre></blockquote>
+</li>
 
-<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-07-17  <b>Last modified:</b> 2009-07-19</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
+<li>
 <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.
+Change 19.5.2.2 [syserr.errcode.constructors] around the prototype before p. 7:
 </p>
 
+<blockquote><pre>template &lt;class ErrorCodeEnum&gt;
+error_code(ErrorCodeEnum e<del>,
+  typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type * = 0</del>);
+</pre>
+<blockquote>
 <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.
+<ins><i>Remarks:</i> This constructor shall not participate in overload
+resolution, unless
+<tt>is_error_code_enum&lt;ErrorCodeEnum&gt;::value == true</tt>.</ins>
 </p>
+</blockquote>
+</blockquote>
+</li>
 
+<li>
 <p>
-For the iterator-based constructor the complexity should be:
+Change 19.5.2.3 [syserr.errcode.modifiers] around the prototype before p. 3:
 </p>
 
+<blockquote><pre>template &lt;class ErrorCodeEnum&gt;
+  <del>typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type</del><ins>error_code</ins>&amp;
+    operator=(ErrorCodeEnum e);
+</pre>
+
 <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.
+<ins><i>Remarks:</i> This operator shall not participate in overload resolution, unless
+<tt>is_error_code_enum&lt;ErrorCodeEnum&gt;::value == true</tt>.</ins>
 </blockquote>
+</blockquote>
+</li>
 
-
-
-<p><b>Proposed resolution:</b></p>
+<li>
 <p>
+In 19.5.3.1 [syserr.errcondition.overview]/1, class <tt>error_condition</tt>, change
+as indicated:
 </p>
 
+<blockquote><pre>// 19.5.3.2 constructors:
+error_condition();
+error_condition(int val, const error_category&amp; cat);
+template &lt;class ErrorConditionEnum&gt;
+  error_condition(ErrorConditionEnum e<del>,
+    typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::type* = 0</del>);
 
+// 19.5.3.3 modifiers:
+void assign(int val, const error_category&amp; cat);
+template&lt;<del>typename</del><ins>class</ins> ErrorConditionEnum&gt;
+  <del>typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;, error_code&gt;::type</del><ins>error_condition</ins> &amp;
+    operator=( ErrorConditionEnum e );
+void clear();
+</pre></blockquote>
+</li>
 
+<li>
+<p>
+Change 19.5.3.2 [syserr.errcondition.constructors] around the
+prototype before p. 7:
+</p>
 
+<blockquote><pre>template &lt;class ErrorConditionEnum&gt;
+  error_condition(ErrorConditionEnum e<del>,
+    typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value&gt;::type* = 0</del>);
+</pre>
+<blockquote>
+<ins><i>Remarks:</i> This constructor shall not participate in overload
+resolution, unless
+<tt>is_error_condition_enum&lt;ErrorConditionEnum&gt;::value == true</tt>.</ins>
+</blockquote>
+</blockquote>
+</li>
 
-<hr>
-<h3><a name="1176"></a>1176. Make <tt>thread</tt> constructor non-variadic</h3>
-<p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-07-18  <b>Last modified:</b> 2009-07-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
+<li>
 <p>
-The variadic <tt>thread</tt> constructor is causing controversy, e.g.
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2901.pdf">N2901</a>.
-This issue has been created as a placeholder for this course of action.
+Change 19.5.3.3 [syserr.errcondition.modifiers] around the
+prototype before p. 3:
 </p>
 
-<blockquote><pre>template &lt;class F<del>, class ...Args</del>&gt; thread(F&amp;&amp; f<del>, Args&amp;&amp;... args</del>);
-</pre></blockquote>
+<blockquote><pre>template &lt;class ErrorConditionEnum&gt;
+  <del>typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value&gt;::type</del><ins>error_condition</ins>&amp;
+    operator=(ErrorConditionEnum e);
+</pre>
 
+<blockquote>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a> for wording which specifies an rvalue-ref signature but
-with "decay behavior", but using variadics.
+<ins><i>Remarks:</i> This operator shall not participate in overload resolution, unless
+<tt>is_error_condition_enum&lt;ErrorConditionEnum&gt;::value == true</tt>.</ins>
 </p>
 
+<p>
+<i>Postcondition:</i> <tt>*this == make_error_condition(e)</tt>.
+</p>
 
-<p><b>Proposed resolution:</b></p>
 <p>
+<ins><i>Returns:</i> <tt>*this</tt></ins>
 </p>
+</blockquote>
+</blockquote>
+
+</li>
+</ol>
+
 
 
 
 
 
 <hr>
-<h3><a name="1177"></a>1177. Improve "diagnostic required" wording</h3>
-<p><b>Section:</b> 20.9.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-07-18  <b>Last modified:</b> 2009-08-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.duration">active issues</a> in [time.duration].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration">issues</a> in [time.duration].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="1238"></a>1238. defining algorithms taking iterator for range</h3>
+<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">Tentatively NAD Future</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-10-15  <b>Last modified:</b> 2009-11-03</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#algorithms">active issues</a> in [algorithms].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Future">Tentatively NAD Future</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-"diagnostic required" has been used (by me) for code words meaning "use
-<tt>enable_if</tt> to constrain templated functions.  This needs to be
-improved by referring to the function signature as not participating in
-the overload set, and moving this wording to a <i>Remarks</i> paragraph.
+The library has many algorithms that take a source range represented by
+a pair of iterators, and the start of some second sequence given by a
+single iterator.  Internally, these algorithms will produce undefined
+behaviour if the second 'range' is not as large as the input range, but
+none of the algorithms spell this out in Requires clauses, and there is
+no catch-all wording to cover this in clause 17 or the front matter of
+25.
 </p>
 
-
-
-<p><b>Proposed resolution:</b></p>
-<p><i>[
-This proposed resolution addresses <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>. 
-]</i></p>
-
-
 <p>
-Change 20.9.3.1 [time.duration.cons]:
+There was an attempt to provide such wording in paper
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2944.pdf">n2944</a>
+but this
+seems incidental to the focus of the paper, and getting the wording of
+this issue right seems substantially more difficult than the simple
+approach taken in that paper.  Such wording will be removed from an
+updated paper, and hopefully tracked via the LWG issues list instead.
 </p>
 
-<blockquote>
-<pre>template &lt;class Rep2&gt; 
-  explicit duration(const Rep2&amp; r);
-</pre>
-<blockquote>
-<p>
-<i><del>Requires:</del> <ins>Remarks:</ins></i>
-<tt>Rep2</tt> shall be implicitly convertible to <tt>rep</tt> and
-</p>
-<ul>
-<li>
-<tt>treat_as_floating_point&lt;rep&gt;::value</tt> shall be <tt>true</tt> or
-</li>
-<li>
-<tt>treat_as_floating_point&lt;Rep2&gt;::value</tt> shall be <tt>false</tt>.
-</li>
-</ul>
 <p>
-<del>Diagnostic required</del> <ins>If these constraints are not met, this
-constructor shall not participate in overload resolution</ins>. [<i>Example:</i>
+It seems there are several classes of problems here and finding wording
+to solve all in one paragraph could be too much.  I suspect we need
+several overlapping requirements that should cover the desired range of
+behaviours.
 </p>
-<blockquote><pre>duration&lt;int, milli&gt; d(3); // OK 
-duration&lt;int, milli&gt; d(3.5); // error 
-</pre></blockquote>
 
 <p>
-&#8212; <i>end example</i>]
+Motivating examples:
 </p>
 
 <p>
-<i>Effects:</i> Constructs an object of type <tt>duration</tt>.
+A good initial example is the <tt>swap_ranges</tt> algorithm.  Here there is a
+clear requirement that <tt>first2</tt> refers to the start of a valid range at
+least as long as the range <tt>[first1, last1)</tt>.  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2944.pdf">n2944</a> tries to solve this
+by positing a hypothetical <tt>last2</tt> iterator that is implied by the
+signature, and requires <tt>distance(first2,last2) &lt; distance(first1,last1)</tt>.
+ This mostly works, although I am uncomfortable assuming that <tt>last2</tt> is
+clearly defined and well known without any description of how to obtain
+it (and I have no idea how to write that).
 </p>
 
 <p>
-<i>Postcondition:</i> <tt>count() == static_cast&lt;rep&gt;(r)</tt>.
+A second motivating example might be the <tt>copy</tt> algorithm.  Specifically,
+let us image a call like:
 </p>
 
-</blockquote>
+<blockquote><pre>copy(istream_iterator&lt;int&gt;(is),istream_iterator(),ostream_iterator&lt;int&gt;(os));
+</pre></blockquote>
 
-<pre>template &lt;class Rep2, class Period2&gt;
-  duration(const duration&lt;Rep2, Period2&gt;&amp; d);
-</pre>
-<blockquote>
 <p>
-<i><del>Requires:</del> <ins>Remarks:</ins></i> <tt>treat_as_floating_point&lt;rep&gt;::value</tt> shall be <tt>true</tt> or
-<tt>ratio_divide&lt;Period2, period&gt;::type::den</tt> shall be 1<del>. Diagnostic
-required</del><ins>, else this constructor shall not participate in overload
-resolution</ins>. [<i>Note:</i> This requirement prevents implicit truncation error
-when converting between integral-based duration types. Such a
-construction could easily lead to confusion about the value of the
-duration. &#8212; <i>end note</i>] [<i>Example:</i>
+In this case, our input iterators are literally simple <tt>InputIterators</tt>,
+and the destination is a simple <tt>OutputIterator</tt>.  In neither case am I
+happy referring to <tt>std::distance</tt>, in fact it is not possible for the
+<tt>ostream_iterator</tt> at all as it does not meet the requirements.  However,
+any wording we provide must cover both cases.  Perhaps we might deduce
+<tt>last2 == ostream_iterator&lt;int&gt;{}</tt>, but that might not always be valid for
+user-defined iterator types.  I can well imagine an 'infinite range'
+that writes to <tt>/dev/null</tt> and has no meaningful <tt>last2</tt>.
 </p>
 
-<blockquote><pre>duration&lt;int, milli&gt; ms(3); 
-duration&lt;int, micro&gt; us = ms; // OK 
-duration&lt;int, milli&gt; ms2 = us; // error 
-</pre></blockquote>
+<p>
+The motivating example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2944.pdf">n2944</a> is <tt>std::equal</tt>, and that seems to fall somewhere between the
+two.
+</p>
 
 <p>
-&#8212; <i>end example</i>]
+Outlying examples might be <tt>partition_copy</tt> that takes two output
+iterators, and the <tt>_n</tt> algorithms where a range is specified by a
+specific number of iterations, rather than traditional iterator pair. 
+We should also <em>not</em> accidentally apply inappropriate constraints to
+<tt>std::rotate</tt> which takes a third iterator that is not intended to be a
+separate range at all.
 </p>
 
 <p>
-<i>Eff&#65533;ects:</i> Constructs an object of type <tt>duration</tt>, constructing
-<tt>rep_</tt> from
-<tt>duration_cast&lt;duration&gt;(d).count()</tt>.
+I suspect we want some wording similar to:
 </p>
 
+<blockquote>
+For algorithms that operate on ranges where the end iterator of the
+second range is not specified, the second range shall contain at least
+as many elements as the first.
 </blockquote>
 
-
-</blockquote>
+<p>
+I don't think this quite captures the intent yet though.  I am not sure
+if 'range' is the right term here rather than sequence.  More awkwardly,
+I am not convinced we can describe an Output sequence such as produce by
+an <tt>ostream_iterator</tt> as "containing elements", at least not as a
+precondition to the call before they have been written.
+</p>
 
 <p>
-Change the following paragraphs in 20.9.3.5 [time.duration.nonmember]:
+Another idea was to describe require that the trailing iterator support
+at least distance(input range) applications of <tt>operator++</tt> and may be
+written through the same number of times if a mutable/output iterator.
 </p>
 
-<blockquote>
-<pre>template &lt;class Rep1, class Period, class Rep2&gt; 
-  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt; 
-  operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
-</pre>
-<blockquote>
-<i><del>Requires</del> <ins>Remarks</ins>:</i> <tt>Rep2</tt> shall be implicitly convertible to
-<tt>CR(Rep1, Rep2)</tt><ins>, else this signature shall not participate in
-overload resolution</ins>. <del>Diagnostic required.</del>
-</blockquote>
+<p>
+We might also consider handling the case of an output range vs. an input
+range in separate paragraphs, if that simplifies how we describe some of
+these constraints.
+</p>
 
-<pre>template &lt;class Rep1, class Period, class Rep2&gt; 
-  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt; 
-  operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
-</pre>
-<blockquote>
-<i><del>Requires</del> <ins>Remarks</ins>:</i> <tt>Rep1</tt> shall be implicitly convertible to
-<tt>CR(Rep1, Rep2)</tt><ins>, else this signature shall not participate in
-overload resolution</ins>. <del>Diagnostic required.</del>
-</blockquote>
+<p><i>[
+2009-11-03 Howard adds:
+]</i></p>
 
-<pre>template &lt;class Rep1, class Period, class Rep2&gt; 
-  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt; 
-  operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
-</pre>
-<blockquote>
-<i><del>Requires</del> <ins>Remarks</ins>:</i> <tt>Rep2</tt> shall be implicitly convertible to
-<tt>CR(Rep1, Rep2)</tt> and <tt>Rep2</tt> shall not be an instantiation of
-<tt>duration</tt><ins>, else this signature shall not participate in
-overload resolution</ins>. <del>Diagnostic required.</del>
-</blockquote>
 
-<pre>template &lt;class Rep1, class Period, class Rep2&gt; 
-  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt; 
-  operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
-</pre>
 <blockquote>
-<i><del>Requires</del> <ins>Remarks</ins>:</i> <tt>Rep2</tt> shall be implicitly convertible to
-<tt>CR(Rep1, Rep2)</tt> and <tt>Rep2</tt> shall not be an instantiation of
-<tt>duration</tt><ins>, else this signature shall not participate in
-overload resolution</ins>. <del>Diagnostic required.</del>
+Moved to Tentatively NAD Future after 5 positive votes on c++std-lib.
 </blockquote>
 
-</blockquote>
 
+<p><b>Proposed resolution:</b></p>
 
 
 
 
 
 <hr>
-<h3><a name="1178"></a>1178. Header dependencies</h3>
-<p><b>Section:</b> 17.6.4.2 [res.on.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-07-18  <b>Last modified:</b> 2009-07-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="1239"></a>1239. Defect report</h3>
+<p><b>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-10-16  <b>Last modified:</b> 2009-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-See Frankfurt notes of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>.
+Table 43 defines a number of traits that yield true for arrays of class
+types with the trait's property, but not arrays of other types with that
+property.  For example, <tt>has_trivial_default_constructor</tt>:
 </p>
 
+<blockquote>
+<tt>T</tt> is a trivial type (3.9) or a class type with a trivial default
+constructor (12.1) or an array of such a class type.
+</blockquote>
+
+<p><i>[
+2009-10 post-Santa Cruz:
+]</i></p>
 
-<p><b>Proposed resolution:</b></p>
-<p><i>Change 17.6.4.2 [res.on.headers], Headers, paragraph 1, as indicated:</i></p>
 
 <blockquote>
+<p>
+An array of a trivial type is a trivial type.
+</p>
+<p>
+Mark as Tentatively NAD Editorial. The wording is OK as is,
+since an array of a trivial type is a trivial type, but the wording as
+proposed might be clearer.
+</p>
+</blockquote>
+
+
 
+<p><b>Proposed resolution:</b></p>
 <p>
-A C++ header may include other C++
-headers.<del><sup>[footnote]</sup></del> <ins>A C++ header shall provide
-the declarations and definitions that appear in its synopsis
-(3.2 [basic.def.odr]). A C++ header shown in its synopsis as including 
-other C++ headers shall provide the declarations and definitions that appear in
-the synopses of those other headers.</ins>
+Change all the traits in question following this pattern:
 </p>
 
-  <p><del><sup>[footnote]</sup> C++ headers must include a C++ header that contains 
-  any needed definition (3.2).</del></p>
+<blockquote>
+<tt>T</tt> is a trivial type (3.9) or a class type with a trivial default
+ constructor (12.1)<ins>,</ins> or an array of such a <del>class</del> type.
 </blockquote>
 
+<p>
+i.e., add a comma and delete a "class."
+</p>
 
 
 
 
 
 <hr>
-<h3><a name="1179"></a>1179. Probably editorial in [structure.specifications]</h3>
-<p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2009-07-21  <b>Last modified:</b> 2009-07-22</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
+<h3><a name="1240"></a>1240. Deleted comparison functions of std::function not  needed</h3>
+<p><b>Section:</b> 20.7.15.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-10-18  <b>Last modified:</b> 2009-10-19</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-While reviewing <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a> I noted that 17.5.1.4 [structure.specifications]/7 says:
-</p>
-
-<blockquote>
--7- Error conditions specify conditions where a function may fail. The
-conditions are listed, together with a suitable explanation, as the <tt>enum
-class errc</tt> constants (19.5) that could be used as an argument to
-function <tt>make_error_condition</tt> (19.5.3.6).
-</blockquote>
-
-<p>
-This paragraph should mention <tt>make_error_code</tt> or the text "that
-could be used as an argument to function <tt>make_error_condition</tt>
-(19.5.3.6)" should be deleted.  I believe this is editorial.
+The class template <tt>std::function</tt> contains the following member
+declarations:
 </p>
 
-<p><i>[
-2009-07-21 Chris adds:
-]</i></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>
 
-<blockquote>
 <p>
-I'm not convinced there's a problem there, because as far as the "Error
-conditions" clauses are concerned, make_error_condition() is used by a
-user to test for the condition, whereas make_error_code is not. For
-example:
+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>void foobar(error_code&amp; ec = throws());
+<blockquote><pre>f1 == f2;
 </pre></blockquote>
 
 <p>
- Error conditions:
+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>
-<blockquote>
-permission_denied - Insufficient privilege to perform operation.
-</blockquote>
 
 <p>
-When a user writes:
+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>
 
-<blockquote><pre>error_code ec;
-foobar(ec);
-if (ec == errc::permission_denied)
-   ...
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-the implicit conversion <tt>errc-&gt;error_condition</tt> makes the if-test
-equivalent to:
+In 20.7.15.2 [func.wrap.func]/1, class function change as indicated:
 </p>
 
-<blockquote><pre>if (ec == make_error_condition(errc::permission_denied))
+<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="1241"></a>1241. unique_copy needs to require EquivalenceRelation</h3>
+<p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-10-17  <b>Last modified:</b> 2009-10-31</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-On the other hand, if the user had written:
+A lot of fixes were silently applied during concept-time and we should
+not lose them again. The Requires clause of 25.3.9 [alg.unique]/5
+doesn't mention that <tt>==</tt> and the predicate need to satisfy an
+<tt>EquivalenceRelation</tt>, as it is correctly said for
+<tt>unique</tt>. This was intentionally fixed during conceptification,
+were we had:
 </p>
 
-<blockquote><pre>if (ec == make_error_code(errc::permission_denied))
+<blockquote><pre>template&lt;InputIterator InIter, class OutIter&gt;
+  requires OutputIterator&lt;OutIter, RvalueOf&lt;InIter::value_type&gt;::type&gt;
+        &amp;&amp; EqualityComparable&lt;InIter::value_type&gt;
+        &amp;&amp; HasAssign&lt;InIter::value_type, InIter::reference&gt;
+        &amp;&amp; Constructible&lt;InIter::value_type, InIter::reference&gt;
+  OutIter unique_copy(InIter first, InIter last, OutIter result);
+
+template&lt;InputIterator InIter, class OutIter,
+         EquivalenceRelation&lt;auto, InIter::value_type&gt; Pred&gt;
+  requires OutputIterator&lt;OutIter, RvalueOf&lt;InIter::value_type&gt;::type&gt;
+        &amp;&amp; HasAssign&lt;InIter::value_type, InIter::reference&gt;
+        &amp;&amp; Constructible&lt;InIter::value_type, InIter::reference&gt;
+        &amp;&amp; CopyConstructible&lt;Pred&gt;
+  OutIter unique_copy(InIter first, InIter last, OutIter result, Pred pred);
 </pre></blockquote>
 
 <p>
-the test is now checking for a specific error code. The test may
-evaluate to <tt>false</tt> even though <tt>foobar()</tt> failed due to the documented
-error condition "Insufficient privilege".
+Note that EqualityComparable implied an equivalence relation.
 </p>
+
+<p><i>[
+N.B. <tt>adjacent_find</tt> was also specified to require
+<tt>EquivalenceRelation</tt>, but that was considered as a defect in
+concepts, see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1000">1000</a>
+]</i></p>
+
+
+<p><i>[
+2009-10-31 Howard adds:
+]</i></p>
+
+
+<blockquote>
+Moved to Tentatively Ready after 5 positive votes on c++std-lib.
 </blockquote>
 
 
+
 <p><b>Proposed resolution:</b></p>
 <p>
+Change 25.3.9 [alg.unique]/5 as indicated:
 </p>
 
+<blockquote><pre>template&lt;class InputIterator, class OutputIterator&gt;
+  OutputIterator
+    unique_copy(InputIterator first, InputIterator last, OutputIterator result);
+
+template&lt;class InputIterator, class OutputIterator, class BinaryPredicate&gt;
+  OutputIterator
+    unique_copy(InputIterator first, InputIterator last,
+                OutputIterator result, BinaryPredicate pred);
+</pre>
+<blockquote>
+<i>Requires:</i> <ins>The comparison function shall be an equivalence
+relation.</ins> The ranges <tt>[first,last)</tt> and
+<tt>[result,result+(last-first))</tt> shall not overlap. The expression
+<tt>*result = *first</tt> shall be valid. If neither
+<tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
+requirements of forward iterator then the value type of
+<tt>InputIterator</tt> shall be <tt>CopyConstructible</tt> (34) and
+<tt>CopyAssignable</tt> (table 36). Otherwise <tt>CopyConstructible</tt>
+is not required.
+</blockquote>
+</blockquote>
+
 
 
 
 
 <hr>
-<h3><a name="1180"></a>1180. Missing string_type member typedef in class <tt>sub_match</tt></h3>
-<p><b>Section:</b> 28.9.1 [re.submatch.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-07-25  <b>Last modified:</b> 2009-07-26</p>
+<h3><a name="1244"></a>1244. wait_*() in *future for synchronous functions</h3>
+<p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2009-10-22  <b>Last modified:</b> 2009-10-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures">issues</a> in [futures].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The definition of class template <tt>sub_match</tt> is strongly dependent
-on the type <tt>basic_string&lt;value_type&gt;</tt>, both in interface and effects,
-but does not provide a corresponding typedef <tt>string_type</tt>, as e.g.
-class <tt>match_results</tt> does, which looks like an oversight to me that
-should be fixed.
+With the addition of <tt>async()</tt>, a <tt>future</tt> might be
+associated with a function that is not running in a different thread but
+is stored to by run synchronously on the <tt>get()</tt> call. It's not
+clear what the <tt>wait()</tt> functions should do in this case.
 </p>
 
+<p>
+Suggested resolution:
+</p>
 
-<p><b>Proposed resolution:</b></p>
-
-<ol>
-<li>
 <p>
-In the class template <tt>sub_match</tt> synopsis 28.9 [re.submatch]/1
-change as indicated:
+Throw an exception.
 </p>
 
-<blockquote><pre>template &lt;class BidirectionalIterator&gt;
-class sub_match : public std::pair&lt;BidirectionalIterator, BidirectionalIterator&gt; {
-public:
-  typedef typename iterator_traits&lt;BidirectionalIterator&gt;::value_type value_type;
-  typedef typename iterator_traits&lt;BidirectionalIterator&gt;::difference_type difference_type;
-  typedef BidirectionalIterator iterator;
-  <ins>typedef basic_string&lt;value_type&gt; string_type;</ins>
 
-  bool matched;
+<p><b>Proposed resolution:</b></p>
 
-  difference_type length() const;
-  operator <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>() const;
-  <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins> str() const;
-  int compare(const sub_match&amp; s) const;
-  int compare(const <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>&amp; s) const;
-  int compare(const value_type* s) const;
-};
-</pre></blockquote>
-</li>
 
-<li>
+
+
+
+<hr>
+<h3><a name="1245"></a>1245. <tt>std::hash&lt;string&gt;</tt> &amp; co</h3>
+<p><b>Section:</b> 20.7.16 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2009-10-22  <b>Last modified:</b> 2009-10-25</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-In 28.9.1 [re.submatch.members]/2 change as indicated:
+In 20.7.16 [unord.hash], <tt>operator()</tt> is specified as
+taking the argument by value. Moreover, it is said that <tt>operator()</tt> shall
+not throw exceptions.
 </p>
 
-<blockquote><pre>operator <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>() const;
-</pre>
+<p>
+However, for the specializations for class types, like <tt>string</tt>, <tt>wstring</tt>,
+etc, the former requirement seems suboptimal from the performance point
+of view (a specific PR has been filed about this in the GCC Bugzilla)
+and, together with the latter requirement, hard if not impossible to
+fulfill. It looks like pass by const reference should be allowed in such
+cases.
+</p>
 
-<blockquote>
-<i>Returns:</i> <tt>matched ? <del>basic_string&lt;value_type&gt;</del>
-<ins>string_type</ins>(first, second) : <del>basic_string&lt;value_type&gt;</del>
-<ins>string_type</ins>()</tt>.
-</blockquote>
-</blockquote>
-</li>
 
-<li>
+<p><b>Proposed resolution:</b></p>
 <p>
-In 28.9.1 [re.submatch.members]/3 change as indicated:
+Add to 20.7.16 [unord.hash]/2:
 </p>
 
-<blockquote><pre><del>basic_string&lt;value_type&gt;</del><ins>string_type</ins> str() const;
+<blockquote>
+<pre>namespace std {
+  template &lt;class T&gt;
+  struct hash : public std::unary_function&lt;T, std::size_t&gt; {
+    std::size_t operator()(T val) const;
+  };
+}
 </pre>
 
-<blockquote>
-<i>Returns:</i> <tt>matched ? <del>basic_string&lt;value_type&gt;</del>
-<ins>string_type</ins>(first, second) : <del>basic_string&lt;value_type&gt;</del>
-<ins>string_type</ins>()</tt>.
-</blockquote>
+<p>
+The return value of <tt>operator()</tt> is unspecified, except that
+equal arguments shall yield the same result. <tt>operator()</tt> shall
+not throw exceptions. <ins>It is also unspecified whether
+<tt>operator()</tt> of <tt>std::hash</tt> specializations for class
+types takes its argument by value or const reference.</ins>
+</p>
 </blockquote>
-</li>
-</ol>
-
 
 
 
 
 
 <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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-07-25  <b>Last modified:</b> 2009-07-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.submatch.op">issues</a> in [re.submatch.op].</p>
+<h3><a name="1246"></a>1246. <tt>vector::resize()</tt> missing efficiency guarantee</h3>
+<p><b>Section:</b> 23.3.6.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-10-24  <b>Last modified:</b> 2009-10-25</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/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:
+If <tt>v</tt> is a <tt>vector</tt>, I think repeated calls to
+<tt>v.resize( v.size() + 1 )</tt> should be amortized O(1), but it's not
+clear that's true from the text of the standard:
 </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);
+<blockquote><pre>void resize(size_type sz);
 </pre>
 <blockquote>
-<i>Returns:</i> <tt>lhs == rhs.str()</tt>.
+<i>Effects:</i> If <tt>sz &lt; size()</tt>, equivalent to <tt>erase(begin() + sz, end());</tt>. If
+<tt>size() &lt; sz</tt>, appends <tt>sz - size()</tt> default constructed elements to the
+sequence.
 </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
+Seems to me if we used <tt>push_back</tt> instead of appends, we might be giving
+the guarantee I'd like.  Thoughts?
 </p>
 
-<blockquote><pre>std::char_traits&lt;iterator_traits&lt;BiIter&gt;::value_type&gt;
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-which is essentially identical to
+In 23.3.6.2 [vector.capacity]/10, change
 </p>
 
-<blockquote><pre>std::char_traits&lt;sub_match&lt;BiIter&gt;::value_type&gt;
-</pre></blockquote>
+<blockquote><pre>void resize(size_type sz);
+</pre>
+<blockquote>
+<i>Effects:</i> If <tt>sz &lt; size()</tt>, equivalent to <tt>erase(begin() + sz, end());</tt>. If
+<tt>size() &lt; sz</tt>, <del>appends <tt>sz - size()</tt> default constructed elements to the
+sequence</del>
+<ins>equivalent to <tt>sz - size()</tt> consecutive evaluations of <tt>push_back(T())</tt></ins>.
+</blockquote>
+</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>
+
+
+
+<hr>
+<h3><a name="1247"></a>1247. <tt>auto_ptr</tt> is overspecified</h3>
+<p><b>Section:</b> D.10.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-10-24  <b>Last modified:</b> 2009-11-06</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-In 28.9.2 [re.submatch.op] change as indicated:
+This issue is extracted as the ongoing point-of-interest from earlier
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>.
 </p>
 
-<ol type="a">
-<li>
+<p>
+<tt>auto_ptr</tt> is overspecified as the <tt>auto_ptr_ref</tt>
+implementation detail is formally specified, and the technique is
+observable so workarounds for compiler defects can  cause a working
+implementation of the primary <tt>auto_ptr</tt> template become
+non-conforming.
+</p>
 
 <p>
-If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1180">1180</a> is accepted:
+<tt>auto_ptr_ref</tt> is a documentation aid to describe a possible
+mechanism to implement the class.  It should be marked exposition only,
+as per similar classes, e.g., <tt>istreambuf_iterator::proxy</tt>
 </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>
+<p><i>[
+2009-10-25 Daniel adds:
+]</i></p>
 
-<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><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&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>
+<p>
+I wonder, whether the revised wording shouldn't be as straight as
+for <tt>istream_buf</tt> by adding one further sentence:
+</p>
 
 <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>.
+An implementation is permitted to provide equivalent functionality without
+providing a class with this name.
+</blockquote>
 </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>
+<p><i>[
+2009-11-06 Alisdair adds Daniel's suggestion to the proposed wording.
+]</i></p>
 
-<blockquote>
-10 <i>Returns:</i> <tt><del>lhs</del><ins>typename
-sub_match&lt;BiIter&gt;::string_type(lhs.begin(), lhs.end())</ins> &gt;
-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>
+<p><i>[
+2009-11-06 Howard moves issue to Review.
+]</i></p>
 
-<blockquote>
-11 <i>Returns:</i> <tt><del>lhs</del><ins>typename
-sub_match&lt;BiIter&gt;::string_type(lhs.begin(), lhs.end())</ins> &gt;=
-rhs.str()</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><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==(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>
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the term "exposition only" in the following two places:
+</p>
+
+<p>
+Ammend D.10.1 [auto.ptr]p2:
+</p>
 
 <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>.
+<p>
+<ins>The exposition only class </ins> <del>T</del><ins>t</ins>emplate <tt>auto_ptr_ref</tt>
+holds a reference to an <tt>auto_ptr</tt>. It is used by the
+<tt>auto_ptr</tt> conversions to allow <tt>auto_ptr</tt> objects to be
+passed to and returned from functions.
+<ins>An implementation is permitted to provide equivalent functionality
+without providing a class with this name.</ins>
+</p>
+
+<blockquote><pre>namespace std {
+ template &lt;class Y&gt; struct auto_ptr_ref { }; <ins>// exposition only</ins>
+</pre></blockquote>
 </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>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&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>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/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>
 
-<blockquote>
-16 <i>Returns:</i> <tt>lhs.str() &gt; <del>rhs</del><ins>typename
-sub_match&lt;BiIter&gt;::string_type(rhs.begin(), rhs.end())</ins></tt>.
-</blockquote>
+<p><i>[
+2009-10-25 Daniel adds:
+]</i></p>
 
-<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>lhs.str() &gt;= <del>rhs</del><ins>typename
-sub_match&lt;BiIter&gt;::string_type(rhs.begin(), rhs.end())</ins></tt>.
-</blockquote>
+<p>
+I agree, that your wording makes that clearer, but suggest to write
+</p>
 
-<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>
+... 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>
-18 <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>.
+<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>
 
-</li>
 
-<li>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1180">1180</a> is <em>not</em> accepted:
+Change 27.5.2.7 [ios.base.cons] p1:
 </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);
+<blockquote><pre>ios_base();
 </pre>
 <blockquote>
-7 <i>Returns:</i> <tt><del>lhs</del><ins>basic_string&lt;typename
-sub_match&lt;BiIter&gt;::value_type&gt;(lhs.begin(), lhs.end())</ins> ==
-rhs.str()</tt>.
+<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>
 
-<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>
+<p>
+Change 27.5.4.1 [basic.ios.cons] p2:
+</p>
 
+<blockquote><pre>basic_ios();
+</pre>
 <blockquote>
-8 <i>Returns:</i> <tt><del>lhs</del><ins>basic_string&lt;typename
-sub_match&lt;BiIter&gt;::value_type&gt;(lhs.begin(), lhs.end())</ins> !=
-rhs.str()</tt>.
+<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>
 
-<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>basic_string&lt;typename
-sub_match&lt;BiIter&gt;::value_type&gt;(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><del>lhs</del><ins>basic_string&lt;typename
-sub_match&lt;BiIter&gt;::value_type&gt;(lhs.begin(), lhs.end())</ins> &gt;
-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>
+<hr>
+<h3><a name="1250"></a>1250. <tt>&lt;bitset&gt;</tt> still overspecified</h3>
+<p><b>Section:</b> 20.3.7 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2009-10-29  <b>Last modified:</b> 2009-10-29</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1227">1227</a> &#8212; <tt>&lt;bitset&gt;</tt> synopsis overspecified makes the observation
+that <tt>std::bitset</tt>, and in fact the whole library, may be implemented
+without needing to <tt>#include &lt;stdexcept&gt;</tt> in any library header. The
+proposed resolution removes the <tt>#include &lt;stdexcept&gt;</tt> directive from
+the header.
+</p>
 
-<blockquote>
-11 <i>Returns:</i> <tt><del>lhs</del><ins>basic_string&lt;typename
-sub_match&lt;BiIter&gt;::value_type&gt;(lhs.begin(), lhs.end())</ins> &gt;=
-rhs.str()</tt>.
-</blockquote>
+<p>
+I'd like to add that the <tt>&lt;bitset&gt;</tt> header (as well as the rest of
+the library) has also been implemented without #including the
+<tt>&lt;cstddef&gt;</tt> header in any library header. In the case of <tt>std::bitset</tt>,
+the template is fully usable (i.e., it may be instantiated and all
+its member functions may be used) without ever mentioning <tt>size_t</tt>.
+In addition, just like no library header except for <tt>&lt;bitset&gt;</tt>
+<tt>#includes &lt;stdexcept&gt;</tt> in its synopsis, no header but <tt>&lt;bitset&gt;</tt>
+<tt>#includes &lt;cstddef&gt;</tt> either.
+</p>
 
-<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>
+<p>
+Thus I suggest that the <tt>#include &lt;cstddef&gt;</tt> directive be similarly
+removed from the synopsis of <tt>&lt;bitset&gt;</tt>.
+</p>
 
-<blockquote>
-12 <i>Returns:</i> <tt><del>lhs</del><ins>basic_string&lt;typename
-sub_match&lt;BiIter&gt;::value_type&gt;(lhs.begin(), lhs.end())</ins> &lt;=
-rhs.str()</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>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.3.7 [template.bitset]:
+</p>
 
-<blockquote>
-13 <i>Returns:</i> <tt>lhs.str() == <del>rhs</del><ins>basic_string&lt;typename
-sub_match&lt;BiIter&gt;::value_type&gt;(rhs.begin(), rhs.end())</ins></tt>.
-</blockquote>
+<blockquote><pre><del>#include &lt;cstddef&gt;        // for size_t</del>
+#include &lt;string&gt;
+#include &lt;iosfwd&gt;         // for istream, ostream
+namespace std {
+...
+</pre></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>lhs.str() != <del>rhs</del><ins>basic_string&lt;typename
-sub_match&lt;BiIter&gt;::value_type&gt;(rhs.begin(), rhs.end())</ins></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>basic_string&lt;typename
-sub_match&lt;BiIter&gt;::value_type&gt;(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>
+<hr>
+<h3><a name="1251"></a>1251. move constructing <tt>basic_stringbuf</tt></h3>
+<p><b>Section:</b> 27.8.1.1 [stringbuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2009-10-29  <b>Last modified:</b> 2009-10-29</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.cons">issues</a> in [stringbuf.cons].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I just came across issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1204">1204</a> -- Global permission to move, which
+seems to address the concern raised by the example in c++std-lib-25030.
+</p>
+<p>
+IIUC, the example violates the permission to assume that arguments
+bound to rvalue references are unnamed temporaries granted to
+implementations by the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1204">1204</a> - Global permission
+to move.
+</p>
 
-<blockquote>
-16 <i>Returns:</i> <tt>lhs.str() &gt; <del>rhs</del><ins>basic_string&lt;typename
-sub_match&lt;BiIter&gt;::value_type&gt;(rhs.begin(), rhs.end())</ins></tt>.
-</blockquote>
+<p>
+I.e., the <tt>ostringstream(ostringstream &amp;&amp;rhs)</tt> ctor can leave the <tt>rhs</tt>
+pointers pointing to the newly constructed object's buffer just as
+long as the dtor doesn't change or invalidate the buffer. The caller
+may not make any assumptions about rhs after the move beyond it being
+safe to destroy or reassign.
+</p>
 
-<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>
+<p>
+So unless I misunderstood something, I still think the <tt>basic_stringbuf</tt>
+move ctor is overspecified. Specifically, I think the third sentence
+in the Effects clause and the last 6 bullets in the Postconditions
+clause can, and IMO should, be stricken.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Strike from 27.8.1.1 [stringbuf.cons]:
+</p>
 
+<blockquote><pre>basic_stringbuf(basic_stringbuf&amp;&amp; rhs);
+</pre>
 <blockquote>
-17 <i>Returns:</i> <tt>lhs.str() &gt;= <del>rhs</del><ins>basic_string&lt;typename
-sub_match&lt;BiIter&gt;::value_type&gt;(rhs.begin(), rhs.end())</ins></tt>.
+<p>
+<i>Effects:</i> Move constructs from the rvalue <tt>rhs</tt>. It is
+implementation-defined whether the sequence pointers in <tt>*this</tt>
+(<tt>eback()</tt>, <tt>gptr()</tt>, <tt>egptr()</tt>, <tt>pbase()</tt>,
+<tt>pptr()</tt>, <tt>epptr()</tt>) obtain the values which <tt>rhs</tt>
+had. <del>Whether they do or not, <tt>*this</tt> and <tt>rhs</tt> reference
+separate buffers (if any at all) after the construction.</del> The openmode,
+locale and any other state of <tt>rhs</tt> is also copied.
+</p>
+
+<p>
+<i>Postconditions:</i> Let <tt>rhs_p</tt> refer to the state of
+<tt>rhs</tt> just prior to this construction and let <tt>rhs_a</tt>
+referto the state of <tt>rhs</tt> just after this construction.
+</p>
+<ul>
+<li>
+<tt>str() == rhs_p.str()</tt>
+</li>
+<li>
+<tt>gptr() - eback() == rhs_p.gptr() - rhs_p.eback()</tt>
+</li>
+<li>
+<tt>egptr() - eback() == rhs_p.egptr() - rhs_p.eback()</tt>
+</li>
+<li>
+<tt>pptr() - pbase() == rhs_p.pptr() - rhs_p.pbase()</tt>
+</li>
+<li>
+<tt>epptr() - pbase() == rhs_p.epptr() - rhs_p.pbase()</tt>
+</li>
+<li><del>
+if <tt>(eback()) eback() != rhs_a.eback()</tt>
+</del></li>
+<li><del>
+if <tt>(gptr()) gptr() != rhs_a.gptr()</tt>
+</del></li>
+<li><del>
+if <tt>(egptr()) egptr() != rhs_a.egptr()</tt>
+</del></li>
+<li><del>
+if <tt>(pbase()) pbase() != rhs_a.pbase()</tt>
+</del></li>
+<li><del>
+if <tt>(pptr()) pptr() != rhs_a.pptr()</tt>
+</del></li>
+<li><del>
+if <tt>(epptr()) epptr() != rhs_a.epptr()</tt>
+</del></li>
+</ul>
+</blockquote>
 </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);
+
+
+
+
+
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/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="http://www.open-std.org/jtc1/sc22/wg21/docs/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>
-18 <i>Returns:</i> <tt>lhs.str() &lt;= <del>rhs</del><ins>basic_string&lt;typename
-sub_match&lt;BiIter&gt;::value_type&gt;(rhs.begin(), rhs.end())</ins></tt>.
+The type shall be a synonym for <tt>Codecvt::state_type</tt>.
 </blockquote>
 </blockquote>
 
-</li>
+<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>
 
-</ol>
 
-</li>
-</ol>
+<p><b>Proposed resolution:</b></p>
 
 
 
 
 
 <hr>
-<h3><a name="1182"></a>1182. Unfortunate hash dependencies</h3>
-<p><b>Section:</b> 20.7.17 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-28  <b>Last modified:</b> 2009-07-30</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
+<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Boris Du&#353;ek <b>Opened:</b> 2009-10-24  <b>Last modified:</b> 2009-10-31</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The implied library dependencies created by spelling out all the <tt>hash</tt>
-template specializations in the <tt>&lt;functional&gt;</tt> synopsis are unfortunate. 
-The potential coupling is greatly reduced if the <tt>hash</tt> specialization is
-declared in the appropriate header for each library type, as it is much
-simpler to forward declare the primary template and provide a single
-specialization than it is to implement a <tt>hash</tt> function for a <tt>string</tt> or
-<tt>vector</tt> without providing a definition for the whole <tt>string/vector</tt>
-template in order to access the necessary bits.
+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><b>Proposed resolution:</b></p>
 <p>
-Note that the proposed resolution purely involves moving the
-declarations of a few specializations, it specifically does not make any
-changes to 20.7.17 [unord.hash].
 </p>
 
 
-<p><b>Proposed resolution:</b></p>
+
+
+
+<hr>
+<h3><a name="1254"></a>1254. Misleading sentence in <tt>vector&lt;bool&gt;::flip</tt></h3>
+<p><b>Section:</b> 23.3.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Christopher Jefferson <b>Opened:</b> 2009-11-01  <b>Last modified:</b> 2009-11-01</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Strike the following specializations declared in the <tt>&lt;functional&gt;</tt>
-synopsis p2 20.7 [function.objects]
+The effects of <tt>vector&lt;bool&gt;::flip</tt> has the line:
 </p>
 
-<blockquote><pre><del>template &lt;&gt; struct hash&lt;std::string&gt;;</del>
-<del>template &lt;&gt; struct hash&lt;std::u16string&gt;;</del>
-<del>template &lt;&gt; struct hash&lt;std::u32string&gt;;</del>
-<del>template &lt;&gt; struct hash&lt;std::wstring&gt;;</del>
+<blockquote>
+It is unspecified whether the function has any effect on allocated but
+unused bits.
+</blockquote>
 
-<del>template &lt;class Allocator&gt; struct hash&lt;std::vector&lt;bool, Allocator&gt; &gt;;</del>
-<del>template &lt;std::size_t N&gt; struct hash&lt;std::bitset&lt;N&gt; &gt;;</del>
-</pre></blockquote>
+<p>
+While this is technically true, it is misleading, as any member function
+in any standard container may change unused but allocated memory. Users
+can never observe such changes as it would also be undefined behaviour
+to read such memory.
+</p>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-Add the following declarations to the synopsis of <tt>&lt;string&gt;</tt> in
-21.3 [string.classes]
+Strike second sentence from the definition of <tt>vector&lt;bool&gt;::flip()</tt>,
+23.3.7 [vector.bool], paragraph 5.
 </p>
 
-<blockquote><pre><ins>// 21.4.x hash support
-template &lt;class T&gt; struct hash;
-template &lt;&gt; struct hash&lt;string&gt;;
-template &lt;&gt; struct hash&lt;u16string&gt;;
-template &lt;&gt; struct hash&lt;u32string&gt;;
-template &lt;&gt; struct hash&lt;wstring&gt;;</ins>
-</pre></blockquote>
+<blockquote>
+<i>Effects:</i> Replaces each element in the container with its complement.
+<del>It is unspecified whether the function has any effect on allocated
+but unused bits.</del>
+</blockquote>
+
+
+
 
+
+<hr>
+<h3><a name="1255"></a>1255. <tt>declval</tt> should be added to the library</h3>
+<p><b>Section:</b> 20.3 [utility] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-11-03  <b>Last modified:</b> 2009-11-04</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Add a new clause 21.4.X
+During the Santa Cruz meeting it was decided to split off the provision
+of the library utility <tt>value()</tt> proposed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2979.html">N2979</a>
+from the concrete request of the
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2939.html#uk300">UK 300</a>
+comment.
+The provision of a new library component that allows the production of
+values in unevaluated expressions is considered as important
+to realize constrained templates in C++0x where concepts are not
+available.
 </p>
 
-<blockquote>
 <p>
-21.4.X Hash support [basic.string.hash]
+The following proposed resolution is an improvement over that suggested in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2958.html">N2958</a>,
+because the proposed component can now be defined without loss of
+general usefulness and any <i>use</i> by user-code will make the program ill-formed.
+A possible prototype implementation that satisfies the core language
+requirements
+can be written as:
 </p>
 
-<pre>template &lt;&gt; struct hash&lt;string&gt;;
-template &lt;&gt; struct hash&lt;u16string&gt;;
-template &lt;&gt; struct hash&lt;u32string&gt;;
-template &lt;&gt; struct hash&lt;wstring&gt;;
-</pre>
+<blockquote><pre>template&lt;class T&gt;
+  struct declval_protector {
+    static const bool stop = false;
+    static typename std::add_rvalue_reference&lt;T&gt;::type delegate(); <font color="#c80000">// undefined</font>
+  };
 
-<blockquote>
-Explicit specializations of the class template hash (20.7.17 [unord.hash])
-shall be provided for the types <tt>string</tt>, <tt>u16string</tt>,
-<tt>u32string</tt> and <tt>wstring</tt> suitable for using these types as keys in
-unordered associative containers (23.5 [unord]).
-</blockquote>
-</blockquote>
+template&lt;class T&gt;
+typename std::add_rvalue_reference&lt;T&gt;::type declval() {
+  static_assert(declval_protector&lt;T&gt;::stop, "declval() must not be used!");
+  return declval_protector&lt;T&gt;::delegate();
+}
+</pre></blockquote>
 
 <p>
-Add the following declarations to the synopsis of <tt>&lt;vector&gt;</tt> in 
-23.3 [sequences]
+Further-on the earlier suggested name <tt>value()</tt> has been changed to <tt>declval()</tt>
+after discussions with committee members.
 </p>
 
-<blockquote><pre><ins>
-// 21.4.x hash support
-template &lt;class T&gt; struct hash;
-template &lt;class Allocator&gt; struct hash&lt;vector&lt;bool, Allocator&gt;&gt;;
-</ins></pre></blockquote>
-
 <p>
-Add a new paragraph to the end of 23.3.7 [vector.bool]
+Finally the suggestion shown below demonstrates that it can simplify
+existing standard wording by directly using it in the library
+specification, and that it also improves an overlooked corner case for
+<tt>common_type</tt> by adding support for <tt>cv void</tt>.
 </p>
 
-<blockquote><pre>template &lt;class Allocator&gt; struct hash&lt;vector&lt;bool, Allocator&gt;&gt;;
-</pre>
-<blockquote>
-A partial specialization of the class template hash (20.7.17 [unord.hash])
-shall be provided for vectors of boolean values suitable for use as a key
-in unordered associative containers (23.5 [unord]).
-</blockquote>
-</blockquote>
 
+<p><b>Proposed resolution:</b></p>
+<p><i>[
+The following edit assumes that the earlier component identity
+has been removed as part of applying the solution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2951.html">N2951</a>,
+and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2984.html">N2984</a>.
+Note that the proposal does not depend on this application,
+but it just simplifies the editorial representation
+]</i></p>
+
+
+<ol>
+<li>
 <p>
-Add the following declarations to the synopsis of <tt>&lt;bitset&gt;</tt>
-in 20.3.6 [template.bitset]
+Change 20.3 [utility], header <tt>&lt;utility&gt;</tt> synopsis
+as indicated:
 </p>
 
-<blockquote><pre><ins>
-// 20.3.6.X hash support
-template &lt;class T&gt; struct hash;
-template &lt;size_t N&gt; struct hash&lt;bitset&lt;N&gt; &gt;;
-</ins></pre></blockquote>
+<blockquote><pre>// 20.3.2, forward/move:
+template &lt;class T, class U&gt; T&amp;&amp; forward(U&amp;&amp; u);;
+template &lt;class T&gt; typename remove_reference&lt;T&gt;::type&amp;&amp; move(T&amp;&amp;);
+
+<ins>// 20.3.3, declval:</ins>
+<ins>template &lt;class T&gt; typename add_rvalue_reference&lt;T&gt;::type declval(); // for unused context</ins>
+</pre></blockquote>
+</li>
 
+<li>
 <p>
-Add a new subclause 20.3.6.X [bitset.hash]
+Immediately after the current section 20.3.3 [forward] insert a
+new section:
 </p>
-
-<blockquote>
 <p>
-20.3.6.X bitset hash support [bitset.hash]
+<ins>20.3.3 Function template declval [declval]</ins>
+</p>
+<p>
+<ins>The library provides the function template <tt>declval</tt> to simplify
+the definition of expressions in
+unevaluated and unused contexts (3.2 [basic.def.odr], 5 [expr]). The
+template parameter <tt>T</tt> of <tt>declval</tt> may
+be an incomplete type.</ins>
 </p>
 
-<pre>template &lt;size_t N&gt; struct hash&lt;bitset&lt;N&gt; &gt;;
+<pre><ins>template &lt;class T&gt; typename add_rvalue_reference&lt;T&gt;::type declval(); // for unused context</ins>
 </pre>
 
 <blockquote>
-A partial specialization of the class template hash
-(20.7.17 [unord.hash]) shall be provided for bitsets suitable for use as a key in
-unordered associative containers (23.5 [unord]).
-</blockquote>
-</blockquote>
+<p>
+<ins><i>Remarks:</i> If this function is used according to 3.2 [basic.def.odr],
+the program shall be ill-formed.</ins>
+</p>
 
+<p>
+<ins>[<i>Example:</i></ins>
+</p>
 
+<blockquote><pre><ins>
+template&lt;class To, class From&gt;
+decltype(static_cast&lt;To&gt;(declval&lt;From&gt;())) convert(From&amp;&amp;);
+</ins></pre></blockquote>
 
+<p>
+<ins>
+declares a function template <tt>convert</tt>, which does only participate in
+overloading, if the type <tt>From</tt> can be
+explicitly casted to type <tt>To</tt> &#8212; <i>end example</i>]</ins>
+</p>
+</blockquote>
 
+</li>
 
+<li>
+<p>
+This bullet just makes clear that after applying <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2984.html">N2984</a>, the changes in 20.6.4.3 [meta.unary.prop], before
+table Type property queries should <em>not</em> use <tt>declval</tt>,
+because the well-formedness requirement of the specification of
+<tt>is_constructible</tt> would become more complicated, because we
+would need to make sure that the expression <i>CE</i> is checked in an
+unevaluated context.
+</p>
+</li>
 
-<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-07-28  <b>Last modified:</b> 2009-07-28</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
+<li>
 <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:
+Also 20.6.5 [meta.rel]/4 is not modified similar to the previous bullet,
+because with
+the stricter requirements of not using <tt>declval()</tt> the well-formedness condition
+would be harder to specify. The following changes are only editorial ones (e.g.
+the removal of the duplicate declaration of <tt>create()</tt>):
 </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
+Given the following function prototype:
 </p>
 
-<blockquote><pre>void init(basic_streambuf&lt;charT,traits&gt;* sb);
+<blockquote><pre>template &lt;class T&gt;
+  typename add_rvalue_reference&lt;T&gt;::type create();
 </pre></blockquote>
 
 <p>
-or by calling
+the predicate condition for a template specialization
+<tt>is_convertible&lt;From, To&gt;</tt> shall be satisfied if and only
+if the return expression in the following code would be well-formed,
+including any
+im<del>m</del>plicit conversions to the return type of the function:
 </p>
 
-<blockquote><pre>basic_streambuf&lt;charT,traits&gt;* rdbuf(basic_streambuf&lt;charT,traits&gt;* sb);
+<blockquote><pre><del>template &lt;class T&gt;
+typename add_rvalue_reference&lt;T&gt;::type create();</del>
+To test() {
+  return create&lt;From&gt;();
+}
 </pre></blockquote>
+</blockquote>
+</li>
 
+<li>
 <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.
+Change the entry in column "Comments" for <tt>common_type</tt> in Table 51 &#8212;
+Other transformations (20.6.7 [meta.trans.other]):
 </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>[
+NB: This wording change extends the type domain of <tt>common_type</tt> for <tt>cv
+void =&gt; cv void</tt> transformations and thus makes <tt>common_type</tt> usable for
+all binary type combinations that are supported by <tt>is_convertible</tt>
+]</i></p>
 
 
-<p><b>Proposed resolution:</b></p>
+<blockquote>
+The member typedef <tt>type</tt> shall be defined as set out below. All
+types in the parameter pack <tt>T</tt> shall be complete <ins>or
+(possibly cv-qualified) <tt>void</tt></ins>. A program may specialize
+this trait if at least one template parameter in the specialization is a
+user-defined type. [<i>Note:</i> Such specializations are needed when
+only explicit conversions are desired among the template arguments.
+&#8212; <i>end note</i>]
+</blockquote>
+</li>
+
+<li>
 <p>
-Change 27.5.4.2 [basic.ios.members] around p. 19 as indicated (The proposed
-resolution fixes also two editorial problems: Some wrong letters in "<tt>clear()</tt>"
-and moving the post conditions into a separate paragraph):
+Change 20.6.7 [meta.trans.other]/3 as indicated:
 </p>
 
-<blockquote><pre>void set_rdbuf(basic_streambuf&lt;charT, traits&gt;* sb);
-</pre>
+<p><i>[
+NB: This wording change is more than an editorial simplification of
+the definition of <tt>common_type</tt>: It also extends its usefulness for <tt>cv
+void</tt> types as outlined above
+]</i></p>
+
 
 <blockquote>
 <p>
-<ins><i>Requires:</i> <tt>sb != nullptr</tt>.</ins>
+The nested typedef <tt>common_type::type</tt> shall be defined as follows:
 </p>
 
+<blockquote>
 <p>
-<i>Effects:</i> Associates the <tt>basic_streambuf</tt> object pointed to by <tt>sb</tt> with
-this stream without
-calling <tt>clear()</tt>. <del>Postconditions: rdbuf() == sb.</del>
+[..]
 </p>
+<pre>template &lt;class T, class U&gt;
+struct common_type&lt;T, U&gt; {
+<del>private:
+  static T&amp;&amp; __t();
+  static U&amp;&amp; __u();
+public:</del>
+  typedef decltype(true ? <del>__t</del><ins>declval&lt;T&gt;</ins>() : <del>__u</del><ins>declval&lt;U&gt;</ins>()) type;
+};
+</pre>
+</blockquote>
+</blockquote>
+</li>
+</ol>
+
+
 
+
+
+
+<hr>
+<h3><a name="1256"></a>1256. <tt>weak_ptr</tt> comparison functions should be removed</h3>
+<p><b>Section:</b> 20.8.15.3 [util.smartptr.weak] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-11-04  <b>Last modified:</b> 2009-11-04</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-<ins><i>Postconditions:</i> <tt>rdbuf() == sb</tt>.</ins>
+Additional to the necessary cleanup of the description of the the
+<tt>weak_ptr</tt> component from 20.8.15.3 [util.smartptr.weak]
+described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1231">1231</a> it turns out that the currently deleted
+comparison functions of <tt>weak_ptr</tt> are not needed at all: There
+is no safe-bool conversion from <tt>weak_ptr</tt>, and it won't silently
+chose a conversion to <tt>shared_ptr</tt>.
 </p>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-<i>Throws:</i> Nothing.
+Change 20.8.15.3 [util.smartptr.weak]/1 as indicated:
 </p>
 
-</blockquote>
-</blockquote>
+<blockquote><pre>namespace std {
+template&lt;class T&gt; class weak_ptr {
+public:
+...
+  <del>// comparisons</del>
+  <del>template&lt;class Y&gt; bool operator&lt;(weak_ptr&lt;Y&gt; const&amp;) const = delete;</del>
+  <del>template&lt;class Y&gt; bool operator&lt;=(weak_ptr&lt;Y&gt; const&amp;) const = delete;</del>
+  <del>template&lt;class Y&gt; bool operator&gt;(weak_ptr&lt;Y&gt; const&amp;) const = delete;</del>
+  <del>template&lt;class Y&gt; bool operator&gt;=(weak_ptr&lt;Y&gt; const&amp;) const = delete;</del>
+};
+...
+</pre></blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="1184"></a>1184. Feature request: dynamic bitset</h3>
-<p><b>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-29  <b>Last modified:</b> 2009-07-29</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector">active issues</a> in [vector].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
+<h3><a name="1257"></a>1257. Header &lt;ios&gt; still contains a <code>concept_map</code></h3>
+<p><b>Section:</b> 27.5 [iostreams.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-11-04  <b>Last modified:</b> 2009-11-04</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostreams.base">issues</a> in [iostreams.base].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Opened at Alisdair's request, steming from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>.
-Alisdair recommends NAD Future.
+The current WP still contains a <tt>concept_map</tt>.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
+<p>
+Change Iostreams base classes 27.5 [iostreams.base], Header &lt;ios&gt; synopsis, 
+as indicated:
+</p>
+
+<blockquote><pre><del>concept_map ErrorCodeEnum&lt;io_errc&gt; { };</del>
+<ins>template &lt;&gt; struct is_error_code_enum&lt;io_errc&gt; : true_type { }</ins>
+error_code make_error_code(io_errc e);
+error_condition make_error_condition(io_errc e);
+const error_category&amp; iostream_category();
+</pre></blockquote>
+
 
 
 
 
 
 <hr>
-<h3><a name="1185"></a>1185. iterator categories and output iterators</h3>
-<p><b>Section:</b> X [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-31  <b>Last modified:</b> 2009-07-31</p>
+<h3><a name="1258"></a>1258. std::function Effects clause impossible to satisfy</h3>
+<p><b>Section:</b> 20.7.15.2.2 [func.wrap.func.mod] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-11-05  <b>Last modified:</b> 2009-11-05</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-(wording relative to
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
-pending new working paper)
+As of 20.7.15.2.2 [func.wrap.func.mod]/2+ we have the following
+prototype description:
 </p>
 
+<blockquote><pre>template&lt;class F, Allocator Alloc&gt;
+  requires Callable&lt;F, ArgTypes...&gt;
+    &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt;
+  void assign(F, const Alloc&amp;);
+</pre>
+<blockquote>
+<i>Effects:</i> <tt>function(f, a).swap(*this)</tt>
+</blockquote>
+</blockquote>
+
 <p>
-According to p3 X [iterator.requirements], Forward iterators,
-Bidirectional iterators and Random Access iterators all satisfy the
-requirements for an Output iterator:
+Two things: First the concept debris needs to be removed, second and
+much more importantly, the effects clause is now impossible to satisfy,
+because there is no constructor that would match the parameter sequence
+(<tt>FunctionObject</tt>, <tt>Allocator</tt>) [plus the fact that no
+<tt>f</tt> and no <tt>a</tt> is part of the signature]. The most
+probable candidate is
 </p>
 
-<blockquote>
-XXX iterators satisfy all the requirements of the input and output iterators
-and can be used whenever either kind is specified ...
-</blockquote>
+<blockquote><pre>template&lt;class F, class A&gt; function(allocator_arg_t, const A&amp;, F);
+</pre></blockquote>
 
 <p>
-Meanwhile, p4 goes on to contradict this:
+and the effects clause needs to be adapted to use this signature.
 </p>
 
-<blockquote>
-Besides its category, a forward, bidirectional, or random access
-iterator can also be mutable or constant...
-</blockquote>
 
+<p><b>Proposed resolution:</b></p>
+<p>
+Change in 20.7.15.2.2 [func.wrap.func.mod] the complete prototype description as
+indicated
+</p>
+<p><i>[
+Question to
+the editor: Shouldn't there a paragraph number in front of the Effects clause?
+]</i></p>
+
+
+<blockquote><pre><del>template&lt;class F, Allocator Alloc&gt;
+  requires Callable&lt;F, ArgTypes...&gt;
+    &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt;
+  void assign(F, const Alloc&amp;);</del>
+<ins>template&lt;class F, class A&gt; void assign(F f, const A&amp; a);</ins>
+</pre>
 <blockquote>
-... Constant iterators do not satisfy the requirements for output iterators
+<ins>3</ins> <i>Effects:</i> <tt>function(<del>f, a</del><ins>allocator_arg, a,
+f</ins>).swap(*this)</tt>
+</blockquote>
 </blockquote>
 
-<p>
-The latter seems to be the overriding concern, as the iterator tag
-hierarchy does not define <tt>forward_iterator_tag</tt> as multiply derived from
-both <tt>input_iterator_tag</tt> and <tt>output_iterator_tag</tt>.
-</p>
 
+
+
+
+<hr>
+<h3><a name="1259"></a>1259. Should initializer-list constructors move elements?</h3>
+<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Sean Hunt <b>Opened:</b> 2009-11-05  <b>Last modified:</b> 2009-11-06</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-The work on concepts for iterators showed us that output iterator really
-is fundamentally a second dimension to the iterator categories, rather
-than part of the linear input -&gt; forward -&gt; bidirectional -&gt;
-random-access sequence.  It would be good to clear up these words to
-reflect that, and separately list output iterator requirements in the
-requires clauses for the appropriate algorithms and operations.
+According to 23.2.3 [sequence.reqmts], <tt>X(il)</tt> is
+equivalent to <tt>X(il.begin(), il.end())</tt>. Should it instead be
+equivalent to <tt>X(move_iterator(il.begin()),
+move_iterator(il.end()))</tt> so that needless copies are not made? This
+doesn't seem ideal either - it may make more sense to provide two
+overloads for the constructor, one for move and one for copy.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
+<p>
+</p>
 
 
 
 
 
 <hr>
-<h3><a name="1186"></a>1186. Forward list could model a stack</h3>
-<p><b>Section:</b> 23.3.5.3 [stack] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-31  <b>Last modified:</b> 2009-08-01</p>
+<h3><a name="1260"></a>1260. <tt>is_constructible&lt;int*,void*&gt;</tt> reports true</h3>
+<p><b>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/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 other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The library template <tt>forward_list</tt> could easily model the idea of a
-<tt>stack</tt>, where the operations work on the front of the list rather than
-the back.  However, the standard library <tt>stack</tt> adaptor cannot support
-this.
+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>
-It would be relatively easy to write a partial specialization for <tt>stack</tt>
-to support <tt>forward_list</tt>, but that opens the question of which header to
-place it in.  A much better solution would be to add a <tt>concept_map</tt> for
-the <tt>StackLikeContainer</tt> concept to the <tt>&lt;forward_list&gt;</tt> header and then
-everything just works, including a user's own further uses in a
-stack-like context.
+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>
-Therefore while I am submitting the issue now so that it is on record, I
-<em>strongly recommend</em> we resolve as "NAD Concepts" as any non-concepts
-based solution will be inferior to the final goal, and the feature is
-not so compelling it must be supported ahead of the concepts-based
-library.
+Change 20.6.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>
 
-<p><b>Proposed resolution:</b></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>