projects / platform / upstream / linaro-gcc.git / commitdiff
? search:
summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 924a2ae)
2008-09-22 Paolo Carlini <paolo.carlini@oracle.com>
authorpaolo <paolo@138bc75d-0d04-0410-961f-82ee72b054a4>
Mon, 22 Sep 2008 15:17:09 +0000 (15:17 +0000)
committerpaolo <paolo@138bc75d-0d04-0410-961f-82ee72b054a4>
Mon, 22 Sep 2008 15:17:09 +0000 (15:17 +0000)
* doc/html/ext/lwg-closed.html: Update to Revision R59.
* doc/html/ext/lwg-active.html: Likewise.
* doc/html/ext/lwg-defects.html: Likewise.
* doc/xml/manual/intro.xml: Adjust.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@140552 138bc75d-0d04-0410-961f-82ee72b054a4

libstdc++-v3/ChangeLog patch | blob | history
libstdc++-v3/doc/html/ext/lwg-active.html patch | blob | history
libstdc++-v3/doc/html/ext/lwg-closed.html patch | blob | history
libstdc++-v3/doc/html/ext/lwg-defects.html patch | blob | history
libstdc++-v3/doc/xml/manual/intro.xml patch | blob | history

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index cbb6671..c4a4926 100644 (file)
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,10 @@
+2008-09-22  Paolo Carlini  <paolo.carlini@oracle.com>
+
+       * doc/html/ext/lwg-closed.html: Update to Revision R59.
+       * doc/html/ext/lwg-active.html: Likewise.
+       * doc/html/ext/lwg-defects.html: Likewise.
+       * doc/xml/manual/intro.xml: Adjust.
+
 2008-09-21  Paolo Carlini  <paolo.carlini@oracle.com>
 
        * include/bits/stl_algo.h (minmax(initializer_list<>): Use make_pair,
diff --git a/libstdc++-v3/doc/html/ext/lwg-active.html b/libstdc++-v3/doc/html/ext/lwg-active.html
index 27e0ed2..94b57c0 100644 (file)
--- a/libstdc++-v3/doc/html/ext/lwg-active.html
+++ b/libstdc++-v3/doc/html/ext/lwg-active.html
@@ -1,22 +1,24 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
-<html><head><title>C++ Standard Library Active Issues List</title>
-
+<html><head>
+<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
 
 
+<title>C++ Standard Library Active Issues List</title>
 <style type="text/css">
 p {text-align:justify}
 li {text-align:justify}
 ins {background-color:#A0FFA0}
 del {background-color:#FFA0A0}
-</style></head><body>
+</style>
+</head><body>
 <table>
 <tbody><tr>
 <td align="left">Doc. no.</td>
-<td align="left">N2612=08-0122</td>
+<td align="left">N2727=08-0237</td>
 </tr>
 <tr>
 <td align="left">Date:</td>
-<td align="left">2008-05-18</td>
+<td align="left">2008-08-24</td>
 </tr>
 <tr>
 <td align="left">Project:</td>
@@ -27,7 +29,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 R56)</h1>
+<h1>C++ Standard Library Active Issues List (Revision R59)</h1>
 
   <p>Reference ISO/IEC IS 14882:1998(E)</p>
   <p>Also see:</p>
@@ -94,6 +96,67 @@ del {background-color:#FFA0A0}
 
 <h2>Revision History</h2>
 <ul>
+<li>R59: 
+2008-08-22 pre-San Francisco mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>192 open issues, up by 9.</li>
+<li>686 closed issues, up by 0.</li>
+<li>878 issues total, up by 9.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="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-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R58: 
+2008-07-28 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>183 open issues, up by 12.</li>
+<li>686 closed issues, down by 4.</li>
+<li>869 issues total, up by 8.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#864">864</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#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</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#869">869</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#393">393</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#592">592</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 Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
+<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>.</li>
+<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R57: 
+2008-06-27 post-Sophia Antipolis mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>171 open issues, down by 20.</li>
+<li>690 closed issues, up by 43.</li>
+<li>861 issues total, up by 23.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following NAD issues: <a href="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-active.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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 Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li>
+<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>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-active.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-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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 New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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>
+</ul></li>
+</ul>
+</li>
 <li>R56: 
 2008-05-16 pre-Sophia Antipolis mailing.
 <ul>
@@ -103,7 +166,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-active.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-active.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-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
@@ -121,7 +184,7 @@ del {background-color:#FFA0A0}
 <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-active.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-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>.</li>
 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#803">803</a>.</li>
-<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#798">798</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>
 <li>Changed the following issues from NAD Future to NAD: <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#323">323</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#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</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>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li>
@@ -130,13 +193,13 @@ 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-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-closed.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 New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-closed.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#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</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-active.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-active.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-active.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-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
@@ -153,7 +216,7 @@ del {background-color:#FFA0A0}
 <li>787 issues total, up by 23.</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#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <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#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</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-closed.html#767">767</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-active.html#769">769</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-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</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-active.html#776">776</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-active.html#779">779</a>, <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-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-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <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-active.html#787">787</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#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</li>
 <li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</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#697">697</a>.</li>
@@ -171,7 +234,7 @@ del {background-color:#FFA0A0}
 <li>764 issues total, up by 10.</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#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>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-active.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-active.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-active.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 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>
@@ -186,16 +249,16 @@ del {background-color:#FFA0A0}
 <li>754 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#724">724</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-active.html#726">726</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#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</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#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</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#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li>
+<li>Added the following New issues: <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#725">725</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-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</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#739">739</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-closed.html#741">741</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-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-closed.html#745">745</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-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</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-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</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#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-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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#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-active.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-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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#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-active.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-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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-active.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>
+<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-active.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-active.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>
 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</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#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</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-active.html#672">672</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-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</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#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-closed.html#645">645</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-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-active.html#691">691</a>.</li>
 <li>Changed the following issues from New to WP: <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#634">634</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#678">678</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#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>.</li>
 <li>Changed the following issues from Open to WP: <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#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</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#488">488</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#660">660</a>.</li>
@@ -211,7 +274,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-closed.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
 </ul></li>
 </ul>
 </li>
@@ -232,10 +295,10 @@ 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#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-closed.html#633">633</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#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-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-closed.html#656">656</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#579">579</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-defects.html#680">680</a>.</li>
 <li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
-<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#644">644</a>.</li>
+<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</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#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</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#488">488</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#518">518</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#518">518</a>.</li>
 <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
 <li>Changed the following issues from DR to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</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#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#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-defects.html#646">646</a>.</li>
@@ -251,7 +314,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-active.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-active.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-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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 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>
@@ -268,7 +331,7 @@ 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-active.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-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-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-active.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-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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 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>
@@ -278,7 +341,7 @@ del {background-color:#FFA0A0}
 <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-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-closed.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-defects.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 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-active.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>
 <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</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#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>.</li>
@@ -295,9 +358,9 @@ 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-active.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-active.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-active.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-defects.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-active.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-active.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-active.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-closed.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-active.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-active.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-active.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-closed.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-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>
@@ -329,7 +392,7 @@ del {background-color:#FFA0A0}
 <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#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#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> to WP.</li>
 <li>Moved issues <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#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#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-closed.html#558">558</a> to NAD.</li>
 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</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#542">542</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-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
+<li>Moved issues <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-active.html#523">523</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#542">542</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-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
 <li>Moved issues <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-closed.html#549">549</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#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a> to Ready.</li>
 <li>Moved issues <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> to Review.</li>
 <li>Added new issues <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#609">609</a>.</li>
@@ -418,7 +481,7 @@ Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.ht
 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#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-active.html#518">518</a> from New to Review.
+Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
 </li>
 <li>R38: 
 2005-07-03 pre-Mont Tremblant mailing.
@@ -753,11 +816,11 @@ format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64
 <h2>Active Issues</h2>
 <hr>
 <h3><a name="23"></a>23. Num_get overflow result</h3>
-<p><b>Section:</b> 22.2.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>
+<p><b>Section:</b> 22.2.2.1.2 [facet.num.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> Nathan Myers <b>Date:</b> 1998-08-06</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>
+<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 current description of numeric input does not account for the
 possibility of overflow. This is an implicit result of changing the
@@ -1107,11 +1170,11 @@ retained for future reference.</p>
 
 <hr>
 <h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</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>
+<p><b>Section:</b> 21.3 [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> Dave Abrahams <b>Date:</b> 1999-07-01</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>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</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>It is the constness of the container which should control whether
 it can be modified through a member function such as erase(), not the
@@ -1149,22 +1212,81 @@ single container?
 </p>
 </blockquote>
 
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+This was a fix that was intended for all standard library containers,
+and has been done for other containers, but string was missed.
+</p>
+<p>
+The wording updated.
+</p>
+<p>
+We did not make the change in <tt>replace</tt>, because this change would affect
+the implementation because the string may be written into. This is an
+issue that should be taken up by concepts.
+</p>
+<p>
+We note that the supplied wording addresses the initializer list provided in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2679.pdf">N2679</a>.
+</p>
+</blockquote>
+
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Change all non-const iterator parameters of standard library
-container member functions to accept const_iterator parameters.
-Note that this change applies to all library clauses, including
-strings.</p>
+<p>
+Update the following signature in the <tt>basic_string</tt> class template definition in
+21.3 [basic.string], p5:
+</p>
+<blockquote><pre>namespace std {
+  template&lt;class charT, class traits = char_traits&lt;charT&gt;,
+    class Allocator = allocator&lt;charT&gt; &gt;
+  class basic_string {
 
-<p>For example, in   21.3.5.5  change:<br>
-<br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>iterator erase(iterator p);</tt><br>
-<br>
-to:<br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>iterator erase(const_iterator p);</tt>
+    ...
+
+    iterator insert(<ins>const_</ins>iterator p, charT c);
+    void insert(<ins>const_</ins>iterator p, size_type n, charT c);
+    template&lt;class InputIterator&gt;
+      void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
+    void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list&lt;charT&gt;);
+
+    ...
+
+    iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
+    iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
+
+    ...
+
+  };
+}
+</pre></blockquote>
+
+<p>
+Update the following signatures in 21.3.6.4 [string::insert]:
 </p>
 
+<blockquote><pre>iterator insert(<ins>const_</ins>iterator p, charT c);
+void insert(<ins>const_</ins>iterator p, size_type n, charT c);
+template&lt;class InputIterator&gt;
+  void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
+void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list&lt;charT&gt;);
+</pre></blockquote>
+
+<p>
+Update the following signatures in 21.3.6.5 [string::erase]:
+</p>
+
+<blockquote><pre>iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
+iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
+</pre></blockquote>
+
+
 
 <p><b>Rationale:</b></p>
 <p>The issue was discussed at length. It was generally agreed that 1)
@@ -1186,7 +1308,6 @@ standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lw
 <h3><a name="190"></a>190. min() and max() functions should be std::binary_functions</h3>
 <p><b>Section:</b> 25.3.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> Mark Rintoul <b>Date:</b> 1999-08-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</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>
@@ -1294,7 +1415,7 @@ signature.</p>
 
 <hr>
 <h3><a name="290"></a>290. Requirements to for_each and its function object</h3>
-<p><b>Section:</b> 25.1.1 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+<p><b>Section:</b> 25.1.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> Angelika Langer <b>Date:</b> 2001-01-03</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>
@@ -2309,7 +2430,8 @@ imaginary part of a[i].</li>
 </blockquote>
 
 <p>
-In 26.3.2 [complex] Add the member functions
+In 26.3.2 [complex] and 26.3.3 [complex.special] add the following member functions
+(changing <tt>T</tt> to concrete types as appropriate for the specializations).
 </p>
 
 <blockquote><pre>void real(T);
@@ -2367,6 +2489,26 @@ Bellevue:
 Second half of proposed wording replaced and moved to Ready.
 </blockquote>
 
+<p><i>[
+Pre-Sophia Antipolis, Howard adds:
+]</i></p>
+
+
+<blockquote>
+Added the members to 26.3.3 [complex.special] and changed from Ready to Review.
+</blockquote>
+
+<p><i>[
+Post-Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+Moved from WP back to Ready so that the "and 26.3.3 [complex.special]" in the proposed
+resolution can be officially applied.
+</blockquote>
+
+
 
 <p><b>Rationale:</b></p>
 <p>The LWG believes that C99 compatibility would be enough
@@ -2484,11 +2626,10 @@ functions should be changed as proposed below.
 
 <hr>
 <h3><a name="396"></a>396. what are characters zero and one</h3>
-<p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+<p><b>Section:</b> 23.3.5.1 [bitset.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>Date:</b> 2003-01-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#bitset.cons">active issues</a> in [bitset.cons].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</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>
 23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
@@ -2521,6 +2662,25 @@ http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
 Also note the typo in 23.3.5.1, p6: the object under construction
 is a bitset, not a string.
     </p>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+We note that <tt>bitset</tt> has been moved from section 23 to section 20, by
+another issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>) previously resolved at this meeting.
+</p>
+<p>
+Disposition: move to ready.
+</p>
+<p>
+We request that Howard submit a separate issue regarding the three to_string overloads.
+</p>
+</blockquote>
+
   
 
 <p><b>Proposed resolution:</b></p>
@@ -2586,6 +2746,15 @@ post Bellevue:
 We are happy with the resolution as proposed, and we move this to Ready.
 </blockquote>
 
+<p><i>[
+Howard adds:
+]</i></p>
+
+
+<blockquote>
+The proposed wording neglects the 3 newer to_string overloads.
+</blockquote>
+
 
 
 
@@ -3655,7 +3824,6 @@ reachability.
 <h3><a name="454"></a>454. basic_filebuf::open should accept wchar_t names</h3>
 <p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#filebuf.members">active issues</a> in [filebuf.members].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.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>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a></p>
@@ -3703,6 +3871,38 @@ Implementors are free to add specific overloads for non-char character
 types.
 </p>
 
+<p><i>[
+Martin adds pre-Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+Please see <a href="http://wiki.dinkumware.com/twiki/pub/Wg21sophiaAntipolis/LibraryWorkingGroup/issue-454.html">issue 454: problems and solutions</a>.
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Beman is concerned that making these changes to <tt>basic_filebuf</tt> is not
+usefully changed unless <tt>fstream</tt> is also changed; this also only handles
+<tt>wchar_t</tt> and not other character types.
+</p>
+<p>
+The TR2 filesystem library is a more complete solution, but is not available soon.
+</p>
+</blockquote>
+
+<p><i>[
+Martin adds:  please reference
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2683.html">N2683</a> for
+problems and solutions.
+]</i></p>
+
+
 
 
 <p><b>Proposed resolution:</b></p>
@@ -4341,10 +4541,10 @@ The expression <tt>delete get()</tt> is well formed.
 
 <hr>
 <h3><a name="471"></a>471. result of what() implementation-defined</h3>
-<p><b>Section:</b> 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+<p><b>Section:</b> 18.6.1 [type.info] <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>Date:</b> 2004-06-28</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#type.info">issues</a> in [type.info].</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>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>
@@ -4418,6 +4618,17 @@ 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 dervied to a base.
+</blockquote>
+
+
 
 
 <p><b>Proposed resolution:</b></p>
@@ -5059,80 +5270,12 @@ Berlin: Bill to provide wording.
 
 
 <hr>
-<h3><a name="518"></a>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3>
-<p><b>Section:</b> 23.1.3 [unord.req], TR1 6.3.1 [tr.unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2005-07-03</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#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Issue 371 deals with stability of multiset/multimap under insert and erase
-(i.e. do they preserve the relative order in ranges of equal elements).
-The same issue applies to unordered_multiset and unordered_multimap.
-</p>
-<p><i>[
-Moved to open (from review):  There is no resolution.
-]</i></p>
-
-
-<p><i>[
-Toronto:  We have a resolution now.  Moved to Review.  Some concern was noted
-as to whether this conflicted with existing practice or not.  An additional
-concern was in specifying (partial) ordering for an unordered container.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Wording for the proposed resolution is taken from the equivalent text for associative containers.
-</p>
-
-<p>
-Change 23.1.3 [unord.req], Unordered associative containers, paragraph 6 to:
-</p>
-
-<blockquote><p>
-An unordered associative container supports <i>unique</i> keys if it may 
-contain at most one element for each key. Otherwise, it supports <i>equivalent 
-keys</i>. <tt>unordered_set</tt> and <tt>unordered_map</tt> support 
-unique keys. <tt>unordered_multiset</tt> and <tt>unordered_multimap</tt> 
-support equivalent keys. In containers that support equivalent keys, elements 
-with equivalent keys are adjacent to each other. <ins>For
-<tt>unordered_multiset</tt> 
-and <tt>unordered_multimap</tt>,<tt> insert</tt> and <tt>erase</tt> 
-preserve the relative ordering of equivalent elements.</ins>
-</p></blockquote>
-
-<p>
-Change 23.1.3 [unord.req], Unordered associative containers, paragraph 8 to:
-</p>
-
-<blockquote>
-<p>The elements of an unordered associative container are organized into <i>
-buckets</i>. Keys with the same hash code appear in the same bucket. The number 
-of buckets is automatically increased as elements are added to an unordered 
-associative container, so that the average number of elements per bucket is kept 
-below a bound. Rehashing invalidates iterators, changes ordering between 
-elements, and changes which buckets elements appear in, but does not invalidate 
-pointers or references to elements. <ins>For <tt>unordered_multiset</tt> 
-and <tt>unordered_multimap</tt>, rehashing 
-preserves the relative ordering of equivalent elements.</ins></p>
-</blockquote>
-
-
-
-
-
-
-<hr>
 <h3><a name="522"></a>522. Tuple doesn't define swap</h3>
-<p><b>Section:</b> 20.3 [tuple], TR1 6.1 [tr.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+<p><b>Section:</b> 20.4 [tuple], TR1 6.1 [tr.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
  <b>Submitter:</b> Andy Koenig <b>Date:</b> 2005-07-03</p>
 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</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>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>
 Tuple doesn't define swap().  It should.
@@ -5160,7 +5303,7 @@ Bellevue:  Alisdair provided wording.
 <p><b>Proposed resolution:</b></p>
 
 <p>
-Add these signatures to 20.3 [tuple]
+Add these signatures to 20.4 [tuple]
 </p>
 
 <blockquote><pre>template &lt;class... Types&gt;
@@ -5172,7 +5315,7 @@ template &lt;class... Types&gt;
 </pre></blockquote>
 
 <p>
-Add this signature to 20.3.1 [tuple.tuple]
+Add this signature to 20.4.1 [tuple.tuple]
 </p>
 
 <blockquote><pre>void swap(tuple&amp;&amp;);
@@ -5363,9 +5506,9 @@ Pete: Possible general problem with case insensitive ranges.
 
 <hr>
 <h3><a name="539"></a>539. partial_sum and adjacent_difference should mention requirements</h3>
-<p><b>Section:</b> 26.6.3 [partial.sum] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+<p><b>Section:</b> 26.6.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>Date:</b> 2006-02-06</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>
 There are some problems in the definition of partial_sum and
@@ -5521,6 +5664,21 @@ The intent of the algorithms is to perform their calculations using the type of
 Proposed wording provided.
 </blockquote>
 
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+We did not agree that the proposed resolution was correct. For example,
+when the arguments are types <tt>(float*, float*, double*)</tt>, the
+highest-quality solution would use double as the type of the
+accumulator. If the intent of the wording is to require that the type of
+the accumulator must be the <tt>input_iterator</tt>'s <tt>value_type</tt>, the wording
+should specify it.
+</blockquote>
+
+
 
 <p><b>Proposed resolution:</b></p>
 <p>
@@ -5575,199 +5733,60 @@ list, so that people may use long long as a hash key.
 
 
 <hr>
-<h3><a name="550"></a>550. What should the return type of pow(float,int) be?</h3>
-<p><b>Section:</b> 26.7 [c.math] <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>Date:</b> 2006-01-12</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</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="556"></a>556. is Compare a BinaryPredicate?</h3>
+<p><b>Section:</b> 25.3 [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>Date:</b> 2006-02-05</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>Discussion:</b></p>
 <p>
-Assuming we adopt the
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">C
-compatibility package from C99</a>  what should be the return type of the
-following signature be:
-</p>
-<blockquote><pre>?  pow(float, int);
-</pre></blockquote>
-<p>
-C++03 says that the return type should be <tt>float</tt>. 
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
-TR1</a> and C90/99 say the return type should be <tt>double</tt>.  This can put
-clients into a situation where C++03 provides answers that are not as high
-quality as C90/C99/TR1.  For example:
+In 25, p8 we allow BinaryPredicates to return a type that's convertible
+to bool but need not actually be bool. That allows predicates to return
+things like proxies and requires that implementations be careful about
+what kinds of expressions they use the result of the predicate in (e.g.,
+the expression in if (!pred(a, b)) need not be well-formed since the
+negation operator may be inaccessible or return a type that's not
+convertible to bool).
 </p>
-<blockquote><pre>#include &lt;math.h&gt;
-
-int main()
-{
-    float x = 2080703.375F;
-    double y = pow(x, 2);
-}
-</pre></blockquote>
 <p>
-Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest:
+Here's the text for reference:
 </p>
-
-<blockquote><pre>y = 4329326534736.390625
-</pre></blockquote>
+<blockquote><p>
+  ...if an algorithm takes BinaryPredicate binary_pred as its argument
+ and first1 and first2 as its iterator arguments, it should work
+ correctly in the construct if (binary_pred(*first1, first2)){...}.
+</p></blockquote>
 
 <p>
-which is exactly right.  While C++98/C++03 demands:
+In 25.3, p2 we require that the Compare function object return true
+of false, which would seem to preclude such proxies. The relevant text
+is here:
 </p>
+<blockquote><p>
+  Compare is used as a function object which returns true if the first
+  argument is less than the second, and false otherwise...
+</p></blockquote>
 
-<blockquote><pre>y = 4329326510080.
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-which is only approximately right.
+I think we could fix this by rewording 25.3, p2 to read somthing like:
 </p>
+<blockquote><p>
+-2- <tt>Compare</tt> is <del>used as a function object which returns
+<tt>true</tt> if the first argument</del> <ins>a <tt>BinaryPredicate</tt>. The
+return value of the function call operator applied to an object of type
+<tt>Compare</tt>, when converted to type <tt>bool</tt>, yields <tt>true</tt>
+if the first argument of the call</ins> is less than the second, and
+<tt>false</tt> otherwise. <tt>Compare <i>comp</i></tt> is used throughout for
+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>
 
-<p>
-I recommend that C++0X adopt the mixed mode arithmetic already adopted by
-Fortran, C and TR1 and make the return type of <tt>pow(float,int)</tt> be
-<tt>double</tt>.
-</p>
 
 <p><i>[
-Kona (2007): Other functions that are affected by this issue include
-<tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt>. We also believe that there is a typo in
-26.7/10: <tt>float nexttoward(float, long double);</tt> [sic] should be <tt>float
-nexttoward(float, float);</tt> Proposed Disposition: Review (the proposed
-resolution appears above, rather than below, the heading "Proposed
-resolution")
-]</i></p>
-
-
-<p><i>[
-<p>
-Howard, post Kona:
-</p>
-<blockquote>
-<p>
-Unfortunately I strongly disagree with a part of the resolution
-from Kona.  I am moving from New to Open instead of to Review because I do not believe
-we have consensus on the intent of the resolution.
-</p>
-<p>
-This issue does not include <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt> because
-the second integral parameter in each of these signatures (from C99) is <b>not</b> a
-<i>generic parameter</i> according to C99 7.22p2.  The corresponding C++ overloads are
-intended (as far as I know) to correspond directly to C99's definition of <i>generic parameter</i>.
-</p>
-<p>
-For similar reasons, I do not believe that the second <tt>long double</tt> parameter of
-<tt>nexttoward</tt>, nor the return type of this function, is in error.  I believe the
-correct signature is:
-</p>
-<blockquote>
-<pre>float nexttoward(float, long double);
-</pre>
-</blockquote>
-<p>
-which is what both the C++0X working paper and C99 state (as far as I currently understand).
-</p>
-<p>
-This is really <b>only</b> about <tt>pow(float, int)</tt>.  And this is because C++98 took one
-route (with <tt>pow</tt> only) and C99 took another (with many math functions in <tt>&lt;tgmath.h&gt;</tt>.
-The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99.
-</p>
-</blockquote>
-]</i></p>
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-This signature was not picked up from C99. Instead, if one types
-pow(2.0f,2), the promotion rules will invoke "double pow(double,
-double)", which generally gives special treatment for integral
-exponents, preserving full accuracy of the result.  New proposed
-wording provided.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.7 [c.math] p10:
-</p>
-
-<blockquote>
-<p>
-The added signatures are:
-</p>
-<blockquote><pre>...
-<del>float pow(float, int);</del>
-...
-<del>double pow(double, int);</del>
-...
-<del>long double pow(long double, int);</del>
-</pre></blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3>
-<p><b>Section:</b> 25.3 [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>Date:</b> 2006-02-05</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>Discussion:</b></p>
-<p>
-In 25, p8 we allow BinaryPredicates to return a type that's convertible
-to bool but need not actually be bool. That allows predicates to return
-things like proxies and requires that implementations be careful about
-what kinds of expressions they use the result of the predicate in (e.g.,
-the expression in if (!pred(a, b)) need not be well-formed since the
-negation operator may be inaccessible or return a type that's not
-convertible to bool).
-</p>
-<p>
-Here's the text for reference:
-</p>
-<blockquote><p>
-  ...if an algorithm takes BinaryPredicate binary_pred as its argument
- and first1 and first2 as its iterator arguments, it should work
- correctly in the construct if (binary_pred(*first1, first2)){...}.
-</p></blockquote>
-
-<p>
-In 25.3, p2 we require that the Compare function object return true
-of false, which would seem to preclude such proxies. The relevant text
-is here:
-</p>
-<blockquote><p>
-  Compare is used as a function object which returns true if the first
-  argument is less than the second, and false otherwise...
-</p></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-I think we could fix this by rewording 25.3, p2 to read somthing like:
-</p>
-<blockquote><p>
--2- <tt>Compare</tt> is <del>used as a function object which returns
-<tt>true</tt> if the first argument</del> <ins>a <tt>BinaryPredicate</tt>. The
-return value of the function call operator applied to an object of type
-<tt>Compare</tt>, when converted to type <tt>bool</tt>, yields <tt>true</tt>
-if the first argument of the call</ins> is less than the second, and
-<tt>false</tt> otherwise. <tt>Compare <i>comp</i></tt> is used throughout for
-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>
-
-
-<p><i>[
-Portland:  Jack to define "convertible to bool" such that short circuiting isn't
-destroyed.
+Portland:  Jack to define "convertible to bool" such that short circuiting isn't
+destroyed.
 ]</i></p>
 
 
@@ -5933,66 +5952,6 @@ Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
 
 
 <hr>
-<h3><a name="570"></a>570. Request adding additional explicit specializations of char_traits</h3>
-<p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Jack Reeves <b>Date:</b> 2006-04-06</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#char.traits">active issues</a> in [char.traits].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</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>
-Currently, the Standard Library specifies only a declaration for template class
-char_traits&lt;&gt; and requires the implementation provide two explicit
-specializations: char_traits&lt;char&gt; and char_traits&lt;wchar_t&gt;. I feel the Standard
-should require explicit specializations for all built-in character types, i.e.
-char, wchar_t, unsigned char, and signed char.
-</p>
-<p>
-I have put together a paper
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>)
-that describes this in more detail and
-includes all the necessary wording.
-</p>
-<p><i>[
-Portland: Jack will rewrite
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>
-to propose a primary template that will work with other integral types.
-]</i></p>
-
-<p><i>[
-Toronto: issue has grown with addition of <tt>char16_t</tt> and <tt>char32_t</tt>.
-]</i></p>
-
-
-<p><i>[
-post Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-We suggest that Jack be asked about the status of his paper, and if it
-is not forthcoming, the work-item be assigned to someone else. If no one
-steps forward to do the paper before the next meeting, we propose to
-make this NAD without further discussion. We leave this Open for now,
-but our recommendation is NAD.
-</p>
-<p>
-Note: the issue statement should be updated, as the Toronto comment has
-already been resolved. E.g., char_traits specializations for char16_t
-and char32_t are now in the working paper.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
 <h3><a name="573"></a>573. C++0x file positioning should handle modern file sizes</h3>
 <p><b>Section:</b> 27.4.3 [fpos] <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>Date:</b> 2006-04-12</p>
@@ -6047,58 +6006,6 @@ these definitions are horrible. Proposed Disposition: Open
 
 
 <hr>
-<h3><a name="574"></a>574. DR 369 Contradicts Text</h3>
-<p><b>Section:</b> 27.3 [iostream.objects] <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>Date:</b> 2006-04-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</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>
-lib.iostream.objects requires that the standard stream objects are never
-destroyed, and it requires that they be destroyed.
-</p>
-<p>
-DR 369 adds words to say that we really mean for ios_base::Init objects to force
-construction of standard stream objects. It ends, though, with the phrase "these
-stream objects shall be destroyed after the destruction of dynamically ...".
-However, the rule for destruction is stated in the standard: "The objects are
-not destroyed during program execution."
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 27.3 [iostream.objects]/1:
-</p>
-
-<blockquote>
-<p>
--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>290)</sup> The objects are not destroyed during program
-execution.<sup>291)</sup> If a translation unit includes <tt>&lt;iostream&amp;t;</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>, and these stream objects shall be
-destroyed after the destruction of dynamically initialized non-local
-objects defined later in that translation unit</del>.
-</p>
-</blockquote>
-
-
-<p><i>[
-Kona (2007): From 27.3 [iostream.objects]/2, strike the words "...and these stream objects
-shall be destroyed after the destruction of dynamically initialized
-non-local objects defined later in that translation unit." Proposed
-Disposition: Review
-]</i></p>
-
-
-
-
-
-<hr>
 <h3><a name="580"></a>580. unused allocator members</h3>
 <p><b>Section:</b> 20.1.2 [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> Martin Sebor <b>Date:</b> 2006-06-14</p>
@@ -6239,7 +6146,7 @@ post Oxford:  This would be rendered NAD Editorial by acceptance of
 
 <hr>
 <h3><a name="582"></a>582. specialized algorithms and volatile storage</h3>
-<p><b>Section:</b> 20.6.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+<p><b>Section:</b> 20.7.10.1 [uninitialized.copy] <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>Date:</b> 2006-06-14</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</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>
@@ -6637,396 +6544,104 @@ requirements? Alisdair will prepare a paper. Proposed Disposition: Open
 
 
 <hr>
-<h3><a name="595"></a>595. TR1/C++0x: fabs(complex&lt;T&gt;) redundant / wrongly specified</h3>
-<p><b>Section:</b> 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Stefan Große Pawig <b>Date:</b> 2006-09-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#complex.value.ops">active issues</a> in [complex.value.ops].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</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="597"></a>597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.</h3>
+<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daveed Vandevoorde <b>Date:</b> 2006-04-05</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.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>
-TR1 introduced, in the C compatibility chapter, the function
-fabs(complex&lt;T&gt;):
+In a private email, Daveed writes:
 </p>
-<blockquote><pre>----- SNIP -----
-8.1.1 Synopsis                                [tr.c99.cmplx.syn]
-
-  namespace std {
-  namespace tr1 {
-[...]
-  template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp; x);
-  } // namespace tr1
-  } // namespace std
-
-[...]
-
-8.1.8 Function fabs                          [tr.c99.cmplx.fabs]
-
-1 Effects: Behaves the same as C99 function cabs, defined in
-  subclause 7.3.8.1.
------ SNIP -----
-</pre></blockquote>
-
+<blockquote>
 <p>
-The current C++0X draft document (n2009.pdf) adopted this
-definition in chapter 26.3.1 (under the comment // 26.3.7 values)
-and 26.3.7/7.
+I am not familiar with the C TR, but my guess is that the
+class type approach still won't match a built-in type
+approach because the notion of "promotion" cannot be
+emulated by user-defined types.
 </p>
 <p>
-But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
-n1124), the referenced subclause reads
+Here is an example:
 </p>
+</blockquote>
+<pre>
+                struct S {
+                  S(_Decimal32 const&amp;);  // Converting constructor
+                };
+                void f(S);
 
-<blockquote><pre>----- SNIP -----
-7.3.8.1 The cabs functions
-
-  Synopsis
-
-1 #include &lt;complex.h&gt;
-  double cabs(double complex z);
-  float cabsf(float complex z);
-  long double cabsl(long double z);
-
-  Description
-
-2 The cabs functions compute the complex absolute value (also called
-  norm, modulus, or magnitude) of z.
-
-  Returns
+                void f(_Decimal64);
 
-3 The cabs functions return the complex absolute value.
------ SNIP -----
-</pre></blockquote>
+                void g(_Decimal32 d) {
+                  f(d);
+                }
+</pre>
 
+<blockquote>
 <p>
-Note that the return type of the cabs*() functions is not a complex
-type.  Thus, they are equivalent to the already well established
-  template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp; x);
-(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft
-document n2009.pdf).
+If _Decimal32 is a built-in type, the call f(d) will likely
+resolve to f(_Decimal64) because that requires only a
+promotion, whereas f(S) requires a user-defined conversion.
 </p>
 <p>
-So either the return value of fabs() is specified wrongly, or fabs()
-does not behave the same as C99's cabs*().
+If _Decimal32 is a class type, I think the call f(d) will be
+ambiguous because both the conversion to _Decimal64 and the
+conversion to S will be user-defined conversions with neither
+better than the other.
 </p>
-
-<b>Possible Resolutions</b>
-
+</blockquote>
 <p>
-This depends on the intention behind the introduction of fabs().
+Robert comments:
 </p>
 <p>
-If the intention was to provide a /complex/ valued function that
-calculates the magnitude of its argument, this should be
-explicitly specified.  In TR1, the categorization under "C
-compatibility" is definitely wrong, since C99 does not provide
-such a complex valued function.
+In general, a library of arithmetic types cannot exactly emulate the
+behavior of the intrinsic numeric types. There are several ways to tell
+whether an implementation of the decimal types uses compiler
+intrinisics or a library. For example:
 </p>
+<pre>                 _Decimal32 d1;
+                 d1.operator+=(5);  // If d1 is a builtin type, this won't compile.
+</pre>
 <p>
-Also, it remains questionable if such a complex valued function
-is really needed, since complex&lt;T&gt; supports construction and
-assignment from real valued arguments.  There is no difference
-in observable behaviour between
+In preparing the decimal TR, we have three options:
 </p>
-<blockquote><pre>  complex&lt;double&gt; x, y;
-  y = fabs(x);
-  complex&lt;double&gt; z(fabs(x));
-</pre></blockquote>
+<ol>
+<li>require that the decimal types be class types</li>
+<li>require that the decimal types be builtin types, like float and double</li>
+<li>specify a library of class types, but allow enough implementor
+latitude that a conforming implementation could instead provide builtin
+types</li>
+</ol>
 <p>
-and
+We decided as a group to pursue option #3, but that approach implies
+that implementations may not agree on the semantics of certain use
+cases (first example, above), or on whether certain other cases are
+well-formed (second example). Another potentially important problem is
+that, under the present definition of POD, the decimal classes are not
+POD types, but builtins will be.
 </p>
-<blockquote><pre>  complex&lt;double&gt; x, y;
-  y = abs(x);
-  complex&lt;double&gt; z(abs(x));
-</pre></blockquote>
-<p>
-If on the other hand the intention was to provide the intended
-functionality of C99, fabs() should be either declared deprecated
-or (for C++0X) removed from the standard, since the functionality
-is already provided by the corresponding overloads of abs().
+<p>Note that neither example above implies any problems with respect to
+C-to-C++ compatibility, since neither example can be expressed in C.
 </p>
 
-<p><i>[
-Bellevue:
-]</i></p>
-
 
-<blockquote>
-Bill believes that abs() is a suitable overload. We should remove fabs().
-</blockquote>
+<p><b>Proposed resolution:</b></p>
 
 
-<p><b>Proposed resolution:</b></p>
 
-<p>
-Change the synopsis in 26.3.1 [complex.synopsis]:
-</p>
 
-<blockquote><pre><del>template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp;);</del>
-</pre></blockquote>
 
+<hr>
+<h3><a name="606"></a>606. Decimal: allow narrowing conversions</h3>
+<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <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>Date:</b> 2006-06-15</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.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>
-Remove 26.3.7 [complex.value.ops], p7:
-</p>
-
-<blockquote>
-<pre><del>template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp; <i>x</i>);</del>
-</pre>
-<blockquote>
-<p>
-<del>-7- <i>Effects:</i> Behaves the same as C99 function <tt>cabs</tt>, defined in subclause 7.3.8.1.</del>
-</p>
-</blockquote>
-</blockquote>
-
-
-
-<p><i>[
-Kona (2007): Change the return type of <tt>fabs(complex)</tt> to <tt>T</tt>. 
-Proposed Disposition: Ready
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="596"></a>596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes</h3>
-<p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2006-09-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#filebuf.members">active issues</a> in [filebuf.members].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.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>
-In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke  
-</p>
-<blockquote><pre>   ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
-</pre></blockquote>
-<p>
-and we expect the open to fail, because out|in|app is not listed in
-Table 92, and just before the table we see very specific words:
-</p>
-<blockquote><p>
-  If mode is not some combination of flags shown in the table 
-  then the open fails.
-</p></blockquote>
-<p>
-But the corresponding table in the C standard, 7.19.5.3, provides two
-modes "a+" and "a+b", to which the C++ modes out|in|app and
-out|in|app|binary would presumably apply.
-</p>
-<p>
-We would like to argue that the intent of Table 112 was to match the
-semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was
-unintentional.  (Otherwise there would be valid and useful behaviors
-available in C file I/O which are unavailable using C++, for no
-valid functional reason.)
-</p>
-<p>
-We further request that the missing modes be explicitly restored to
-the WP, for inclusion in C++0x.
-</p>
-
-<p><i>[
-Martin adds:
-]</i></p>
-
-
-<p>
-...besides "a+" and "a+b" the C++ table is also missing a row
-for a lone app bit which in at least two current implementation
-as well as in Classic Iostreams corresponds to the C stdio "a"
-mode and has been traditionally documented as implying ios::out.
-Which means the table should also have a row for in|app meaning
-the same thing as "a+" already proposed in the issue.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:
-</p>
-
-<blockquote>
-<table border="1">
-<caption> File open modes</caption>
-<tbody><tr>
-<th colspan="5"><tt>ios_base</tt> Flag combination</th>
-<th><tt>stdio</tt> equivalent</th>
-</tr>
-<tr>
-<th><tt>binary</tt></th><th><tt>in</tt></th><th><tt>out</tt></th><th><tt>trunc</tt></th><th><tt>app</tt></th><th><tt>&nbsp;</tt></th>
-</tr>
-
-<tr>
-<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
-</tr>
-<tr>
-<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"a"</tt></td>
-</tr>
-<tr>
-<td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a"</tt></ins></td>
-</tr>
-<tr>
-<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
-</tr>
-<tr>
-<td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r"</tt></td>
-</tr>
-<tr>
-<td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+"</tt></td>
-</tr>
-<tr>
-<td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+"</tt></td>
-</tr>
-<tr>
-<td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
-</tr>
-<tr>
-<td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
-</tr>
-
-<tr>
-<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
-</tr>
-<tr>
-<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"ab"</tt></td>
-</tr>
-<tr>
-<td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"ab"</tt></ins></td>
-</tr>
-<tr>
-<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
-</tr>
-<tr>
-<td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"rb"</tt></td>
-</tr>
-<tr>
-<td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+b"</tt></td>
-</tr>
-<tr>
-<td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+b"</tt></td>
-</tr><tr>
-<td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
-</tr>
-<tr>
-<td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
-</tr>
-
-
-</tbody></table>
-</blockquote>
-
-
-
-<p><i>[
-Kona (2007) Added proposed wording and moved to Review.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="597"></a>597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.</h3>
-<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daveed Vandevoorde <b>Date:</b> 2006-04-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.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>
-In a private email, Daveed writes:
-</p>
-<blockquote>
-<p>
-I am not familiar with the C TR, but my guess is that the
-class type approach still won't match a built-in type
-approach because the notion of "promotion" cannot be
-emulated by user-defined types.
-</p>
-<p>
-Here is an example:
-</p>
-</blockquote>
-<pre>
-                struct S {
-                  S(_Decimal32 const&amp;);  // Converting constructor
-                };
-                void f(S);
-
-                void f(_Decimal64);
-
-                void g(_Decimal32 d) {
-                  f(d);
-                }
-</pre>
-
-<blockquote>
-<p>
-If _Decimal32 is a built-in type, the call f(d) will likely
-resolve to f(_Decimal64) because that requires only a
-promotion, whereas f(S) requires a user-defined conversion.
-</p>
-<p>
-If _Decimal32 is a class type, I think the call f(d) will be
-ambiguous because both the conversion to _Decimal64 and the
-conversion to S will be user-defined conversions with neither
-better than the other.
-</p>
-</blockquote>
-<p>
-Robert comments:
-</p>
-<p>
-In general, a library of arithmetic types cannot exactly emulate the
-behavior of the intrinsic numeric types. There are several ways to tell
-whether an implementation of the decimal types uses compiler
-intrinisics or a library. For example:
-</p>
-<pre>                 _Decimal32 d1;
-                 d1.operator+=(5);  // If d1 is a builtin type, this won't compile.
-</pre>
-<p>
-In preparing the decimal TR, we have three options:
-</p>
-<ol>
-<li>require that the decimal types be class types</li>
-<li>require that the decimal types be builtin types, like float and double</li>
-<li>specify a library of class types, but allow enough implementor
-latitude that a conforming implementation could instead provide builtin
-types</li>
-</ol>
-<p>
-We decided as a group to pursue option #3, but that approach implies
-that implementations may not agree on the semantics of certain use
-cases (first example, above), or on whether certain other cases are
-well-formed (second example). Another potentially important problem is
-that, under the present definition of POD, the decimal classes are not
-POD types, but builtins will be.
-</p>
-<p>Note that neither example above implies any problems with respect to
-C-to-C++ compatibility, since neither example can be expressed in C.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="606"></a>606. Decimal: allow narrowing conversions</h3>
-<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <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>Date:</b> 2006-06-15</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.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>
-In c++std-lib-17205, Martin writes:
+In c++std-lib-17205, Martin writes:
 </p>
 <blockquote><p>...was it a deliberate design choice to make narrowing
 assignments ill-formed while permitting narrowing compound assignments?
@@ -7078,61 +6693,6 @@ Redmond: We prefer explicit conversions for narrowing and implicit for widening.
 
 
 <hr>
-<h3><a name="612"></a>612. numeric_limits::is_modulo insufficiently defined</h3>
-<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <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>Date:</b> 2006-11-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.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>
-18.2.1.2 55 states that "A type is modulo if it is possible to add two
-positive numbers together and have a result that wraps around to a
-third number that is less".
-This seems insufficient for the following reasons:
-</p>
-
-<ol>
-<li>Doesn't define what that value received is.</li>
-<li>Doesn't state the result is repeatable</li>
-<li> Doesn't require that doing addition, subtraction and other
-operations on all values is defined behaviour.</li>
-</ol>
-
-<p><i>[
-Batavia: Related to
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2144.pdf">N2144</a>.
-Pete: is there an ISO definition of modulo?  Underflow on signed behavior is undefined.
-]</i></p>
-
-
-<p><i>[
-Bellevue:  accept resolution, move to ready status.
-Does this mandate that is_modulo be true on platforms for which int
-happens to b modulo? A: the standard already seems to require that.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Suggest 18.2.1.2 [numeric.limits.members[numeric.limits.members], paragraph 57 is amended to:
-</p>
-
-<blockquote><p>
-A type is modulo if<ins>,</ins> <del>it is possible to add two positive numbers
-and have a result that wraps around to a third number that is less.</del>
-<ins>given any operation involving +,- or * on values of that type whose value
-would fall outside the range <tt>[min(), max()]</tt>, then the value returned
-differs from the true value by an integer multiple of <tt>(max() - min() +
-1)</tt>.</ins>
-</p></blockquote>
-
-
-
-
-
-
-<hr>
 <h3><a name="614"></a>614. std::string allocator requirements still inconsistent</h3>
 <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
  <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-05</p>
@@ -7240,86 +6800,29 @@ std::array does have, but array isn't mentioned.
 
 
 <hr>
-<h3><a name="618"></a>618. valarray::cshift() effects on empty array</h3>
-<p><b>Section:</b> 26.5.2.7 [valarray.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-10</p>
+<h3><a name="629"></a>629. complex<t> insertion and locale dependence</t></h3>
+<p><b>Section:</b> 26.3.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-28</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.ops">issues</a> in [complex.ops].</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 would respectfully request an issue be opened with the intention to
-clarify the wording for <tt>size() == 0</tt> for <tt>cshift</tt>.
+is there an issue opened for (0,3) as complex number with
+the French local?  With the English local, the above parses as an
+imaginery complex number.  With the French locale it parses as a
+real complex number.
 </p>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 26.5.2.7 [valarray.members], paragraph 10:
+Further notes/ideas from the lib-reflector, messages 17982-17984:
 </p>
 
 <blockquote>
-
-<pre>valarray&lt;T&gt; cshift(int <i>n</i>) const;
-</pre>
-
-<blockquote>
 <p>
-This function returns an object of class <tt>valarray&lt;T&gt;</tt>, of
-length <tt>size()</tt>, <del>each of whose elements <tt>I</tt> is
-<tt>(*this)[(I + n ) % size()]</tt>. Thus, if element zero is taken as
-the leftmost element, a positive value of <i>n</i> shifts the elements
-circularly left <i>n</i> places.</del> <ins>that is a circular shift of <tt>*this</tt>. If
-element zero is taken as the leftmost element, a non-negative value of
-<i>n</i> shifts the elements circularly left <i>n</i> places and a
-negative value of <i>n</i> shifts the elements circularly right
--<i>n</i> places.</ins>
+Add additional entries in num_punct to cover the complex separator (French would be ';').
 </p>
-</blockquote>
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
 <p>
-We do not believe that there is any real ambiguity about what happens
-when <tt>size() == 0</tt>, but we do believe that spelling this out as a C++
-expression causes more trouble that it solves. The expression is
-certainly wrong when <tt>n &lt; 0</tt>, since the sign of % with negative arguments
-is implementation defined.
-</p>
-
-
-<p><i>[
-Kona (2007) Changed proposed wording, added rationale and set to Review.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="629"></a>629. complex<t> insertion and locale dependence</t></h3>
-<p><b>Section:</b> 26.3.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.ops">issues</a> in [complex.ops].</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>
-is there an issue opened for (0,3) as complex number with
-the French local?  With the English local, the above parses as an
-imaginery complex number.  With the French locale it parses as a
-real complex number.
-</p>
-
-<p>
-Further notes/ideas from the lib-reflector, messages 17982-17984:
-</p>
-
-<blockquote>
-<p>
-Add additional entries in num_punct to cover the complex separator (French would be ';').
-</p>
-<p>
-Insert a space before the comma, which should eliminate the ambiguity.
+Insert a space before the comma, which should eliminate the ambiguity.
 </p>
 <p>
 Solve the problem for ordered sequences in general, perhaps with a
@@ -7347,6 +6850,32 @@ And move this to READY status.
 </p>
 </blockquote>
 
+<p><i>[
+Pre-Sophia Antipolis, Howard adds:
+]</i></p>
+
+
+<blockquote>
+Changed "showbase" to "showpoint" and changed from Ready to Review.
+</blockquote>
+
+<p><i>[
+Post-Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+I neglected to pull this issue from the formal motions page after the "showbase" to "showpoint" change.
+In Sophia Antipolis this change was reviewed by the LWG and the issue was set to Ready.  We subsequently
+voted the footnote into the WP with "showbase".
+</p>
+<p>
+I'm changing from WP back to Ready to pick up the "showbase" to "showpoint" change.
+</p>
+</blockquote>
+
+
 
 <p><b>Proposed resolution:</b></p>
 <p>
@@ -7355,7 +6884,7 @@ Add a footnote to 26.3.6 [complex.ops] p16:
 
 <blockquote>
 [In a locale in which comma is being used as a decimal point character,
-inserting "showbase" into the output stream forces all outputs to show
+inserting <tt>showpoint</tt> into the output stream forces all outputs to show
 an explicit decimal point character; then all inserted complex sequences
 will extract unambiguously.]
 </blockquote>
@@ -7368,6 +6897,7 @@ will extract unambiguously.]
 <h3><a name="630"></a>630. arrays of valarray</h3>
 <p><b>Section:</b> 26.5.2.1 [valarray.cons] <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>Date:</b> 2007-01-28</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</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#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -7505,6 +7035,46 @@ 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>
+Change 26.5.2.2 [valarray.assign], p1 as follows:
+</p>
+
+<blockquote>
+<p>
+ -1- <i>Requires:</i> <tt>size() == 0 || size() == x.size()</tt>.
+</p>
+<p>
+ -2- <i>Effects:</i> If <tt>size() == 0</tt> calls <tt>x.resize(x.size())</tt> first.
+     Each element of the <tt>*this</tt> array is assigned the value of the
+     corresponding element of the argument array.
+</p>
+<p>
+ -3- <i>Postcondition:</i> <tt>size() == x.size()</tt>.
+</p>
+</blockquote>
+
+<p>
+Add the following paragraph to 26.5.2.2 [valarray.assign], immediately after
+p4:
+</p>
+
+<blockquote>
+<p>
+ -?- When <tt>size() == 0</tt> and the length, <tt>N</tt> of the array referred to by
+     the argument is not equal to the length of <tt>*this</tt>, the operator
+     resizes <tt>*this</tt> to make the two arrays the same length, as if by
+     calling <tt>resize(N)</tt>, before performing the assignment. Otherwise,
+     when <tt>size() &gt; 0</tt> and <tt>size() != N</tt>, the behavior is undefined.
+</p>
+</blockquote>
+
+
 
 <p><i>[
 Kona (2007): Gaby to propose wording for an alternative resolution in
@@ -7764,97 +7334,53 @@ no resolution to this issue was recorded.  Moved to Open.
 
 
 <hr>
-<h3><a name="638"></a>638. deque end invalidation during erase</h3>
-<p><b>Section:</b> 23.2.2.3 [deque.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Steve LoBasso <b>Date:</b> 2007-02-17</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="644"></a>644. Possible typos in 'function' description</h3>
+<p><b>Section:</b> X [func.wrap.func.undef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-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>
-The standard states at 23.2.2.3 [deque.modifiers]/4:
-</p>
-<blockquote><pre>deque erase(...)
-</pre>
- <p>
-<i>Effects:</i> ... An erase at either end of the deque invalidates only
-the iterators and the references to the erased elements.
-</p>
-</blockquote>
-<p>
-This does not state that iterators to end will be invalidated.
-It needs to be amended in such a way as to account for end invalidation.
-</p>
-<p>
-Something like:
+X [func.wrap.func.undef]
 </p>
-<blockquote><p>
-Any time the last element is erased, iterators to end are invalidated.
-</p></blockquote>
-
 <p>
-This would handle situations like:
+The note in paragraph 2 refers to 'undefined void operators', while the 
+section declares a pair of operators returning bool.
 </p>
-<blockquote><pre>erase(begin(), end())
-erase(end() - 1)
-pop_back()
-resize(n, ...) where n &lt; size()
-pop_front() with size() == 1
-
-</pre></blockquote>
 
 <p><i>[
-Post Kona, Steve LoBasso notes:
+Post-Sophia Antipolis:
 ]</i></p>
 
 
 <blockquote>
-My only issue with the proposed resolution is that it might not be clear
-that <tt>pop_front()</tt> [where <tt>size() == 1</tt>] can invalidate past-the-end
-iterators.
+Changed from Pending WP to Open.  This issue was voted to WP at the same time the operators were
+changed from private to deleted.  The two issues stepped on each other.  What do we want the return
+type of these deleted functions to be?
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change 23.2.2.3 [deque.modifiers], p4:
+Change 20.6.15.2 [func.wrap.func]
 </p>
 
-<blockquote>
-<pre>iterator erase(const_iterator position); 
-iterator erase(const_iterator first, const_iterator last);
-</pre>
+<blockquote><pre>...
+private:
+   // X [func.wrap.func.undef], undefined operators:
+   template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
+   template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
+};
+</pre></blockquote>
 
-<blockquote>
 <p>
--4- <i>Effects:</i> An erase in the middle of the <tt>deque</tt>
-invalidates all the iterators and references to elements of the
-<tt>deque</tt> <ins>and the past-the-end iterator</ins>. An erase at
-either end of the <tt>deque</tt> invalidates only the iterators and the
-references to the erased elements<ins>, except that erasing at the end
-also invalidates the past-the-end iterator</ins>.
+Change X [func.wrap.func.undef]
 </p>
-</blockquote>
-</blockquote>
-
-
-
-<p><i>[
-Kona (2007): Proposed wording added and moved to Review.
-]</i></p>
-
-
-<p><i>[
-Bellevue:
-]</i></p>
 
+<blockquote><pre>template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
+template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
+</pre></blockquote>
 
-<blockquote>
-Note that there is existing code that relies on iterators not being
-invalidated, but there are also existing implementations that do
-invalidate iterators. Thus, such code is not portable in any case. There
-is a pop_front() note, which should possibly be a separate issue. Mike
-Spertus to evaluate and, if need be, file an issue.
-</blockquote>
 
 
 
@@ -8144,7 +7670,10 @@ Bill to provide proposed wording and interpretation of existing wording.
 <p><b>Section:</b> 22.2.6.3 [locale.moneypunct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</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-active.html#836">836</a></p>
 <p><b>Discussion:</b></p>
+
+
 <p>
 22.2.6.3 [locale.moneypunct], para 2 says:
 </p>
@@ -8259,159 +7788,109 @@ Kona (2007): Robert volunteers to propose wording.
 
 
 <hr>
-<h3><a name="672"></a>672. Swappable requirements need updating</h3>
-<p><b>Section:</b> 20.1.1 [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> Howard Hinnant <b>Date:</b> 2007-05-04</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#Ready">Ready</a> status.</p>
+<h3><a name="675"></a>675. Move assignment of containers</h3>
+<p><b>Section:</b> 23.1 [container.requirements] <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>Date:</b> 2007-05-05</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#Review">Review</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The current <tt>Swappable</tt> is:
+James Hopkin pointed out to me that if <tt>vector&lt;T&gt;</tt> move assignment is O(1)
+(just a <tt>swap</tt>) then containers such as <tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> might have
+the wrong semantics under move assignment when the source is not truly an rvalue, but a
+moved-from lvalue (destructors could run late).
 </p>
 
-<blockquote>
-<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(s,t)</tt></td><td><tt>void</tt></td><td><tt>t</tt> has the value originally held by <tt>u</tt>, and <tt>u</tt> has the value originally 
-held by <tt>t</tt></td></tr>
-<tr><td colspan="3">
-<p>
-The Swappable requirement is met by satisfying one or more of the following conditions:
-</p>
-<ul>
-<li>
-<tt>T</tt> is Swappable if <tt>T</tt> satisfies the <tt>CopyConstructible</tt> requirements (Table 34) 
-and the <tt>CopyAssignable</tt> requirements (Table 36);
-</li>
-<li>
-<tt>T</tt> is Swappable if a namespace scope function named <tt>swap</tt> exists in the same 
-namespace as the definition of <tt>T</tt>, such that the expression <tt>swap(t,u)</tt> is valid 
-and has the semantics described in this table.
-</li>
-</ul>
-</td></tr>
-</tbody></table>
-</blockquote>
+<blockquote><pre><tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v1;
+<tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v2;
+...
+v1 = v2;               // #1
+v1 = std::move(v2);    // #2
+</pre></blockquote>
 
 <p>
-With the passage of rvalue reference into the language, <tt>Swappable</tt> needs to be updated to
-require only <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.  This is a minimum.
+Move semantics means not caring what happens to the source (<tt>v2</tt> in this example).
+It doesn't mean not caring what happens to the target (<tt>v1</tt>).  In the above example
+both assignments should have the same effect on <tt>v1</tt>.  Any non-shared <tt>ostream</tt>'s
+<tt>v1</tt> owns before the assignment should be closed, whether <tt>v1</tt> is undergoing
+copy assignment or move assignment.
 </p>
 
 <p>
-Additionally we may want to support proxy references such that the following code is acceptable:
+This implies that the semantics of move assignment of a generic container should be
+<tt>clear, swap</tt> instead of just swap.  An alternative which could achieve the same
+effect would be to move assign each element.  In either case, the complexity of move
+assignment needs to be relaxed to <tt>O(v1.size())</tt>.
 </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;);
-
-}  // Mine
-
-...
-
-Mine::proxied_iterator&lt;Mine::A&gt; i(...)
-Mine::A a;
-swap(*i1, a);
-</pre></blockquote>
-
 <p>
-I.e. here is a call to <tt>swap</tt> which the user enables swapping between a proxy to a class and the class
-itself.  We do not need to anything in terms of implementation except not block their way with overly
-constrained concepts.  That is, the <tt>Swappable</tt> concept should be expanded to allow swapping
-between two different types for the case that one is binding to a user-defined <tt>swap</tt>.
+The performance hit of this change is not nearly as drastic as it sounds. 
+In practice, the target of a move assignment has always just been move constructed
+or move assigned <i>from</i>.  Therefore under <tt>clear, swap</tt> semantics (in
+this common use case) we are still achieving O(1) complexity.
 </p>
 
 
 
 <p><b>Proposed resolution:</b></p>
-
 <p>
-Change 20.1.1 [utility.arg.requirements]:
+Change 23.1 [container.requirements]:
 </p>
 
 <blockquote>
+<table border="1">
+<caption>Table 89: Container requirements</caption>
+<tbody><tr>
+<th>expression</th><th>return type</th><th>operational semantics</th>
+<th>assertion/note pre/post-condition</th><th>complexity</th>
+</tr>
+<tr>
+<td><tt>a = rv;</tt></td><td><tt>X&amp;</tt></td>
+<td>All existing elements of <tt>a</tt> are either move assigned or destructed</td>
+<td><tt>a</tt> shall be equal to the 
+value that <tt>rv</tt> had 
+before this construction
+</td>
+<td><del>(Note C)</del> <ins>linear</ins></td>
+</tr>
+</tbody></table>
 
 <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> is a type to be supplied by a C++ program
-instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
-values of type <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>; and <tt>rv</tt> is a non-<tt>const</tt>
-rvalue of type <tt>T</tt>.
+Notes: the algorithms <tt>swap()</tt>, <tt>equal()</tt> and
+<tt>lexicographical_compare()</tt> are defined in clause 25. Those
+entries marked "(Note A)" should have constant complexity. Those entries
+marked "(Note B)" have constant complexity unless
+<tt>allocator_propagate_never&lt;X::allocator_type&gt;::value</tt> is
+<tt>true</tt>, in which case they have linear complexity.
+<del>Those entries
+marked "(Note C)" have constant complexity if <tt>a.get_allocator() ==
+rv.get_allocator()</tt> or if either
+<tt>allocator_propagate_on_move_assignment&lt;X::allocator_type&gt;::value</tt>
+is <tt>true</tt> or
+<tt>allocator_propagate_on_copy_assignment&lt;X::allocator_type&gt;::value</tt>
+is <tt>true</tt> and linear complexity otherwise.</del>
 </p>
+</blockquote>
 
-<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(s,t)</tt></td><td><tt>void</tt></td>
-<td><tt>t</tt> has the value originally
-held by <tt>u</tt>, and
-<tt>u</tt> has the value originally held
-by <tt>t</tt></td></tr>
-<tr><td colspan="3">
+
+
+<p><i>[
+post Bellevue Howard adds:
+]</i></p>
+
+
+<blockquote>
 <p>
-The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
+This issue was voted to WP in Bellevue, but accidently got stepped on by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
+which was voted to WP simulataneously.  Moving back to Open for the purpose of getting
+the wording right.  The intent of this issue and N2525 are not in conflict.
 </p>
-<ul>
-<li>
-<tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> satisfies the
-<del><tt>CopyConstructible</tt></del> <ins>MoveConstructible</ins>
-requirements (Table <del>34</del> <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del> <ins>MoveAssignable</ins>
-requirements (Table <del>36</del> <ins>35</ins>);
-</li>
-<li>
-<tt>T</tt> is <tt>Swappable</tt> if a namespace scope function named
-<tt>swap</tt> exists in the same namespace as the definition of
-<tt>T</tt>, such that the expression
-<tt>swap(t,u)</tt> is valid and has the
-semantics described in this table.
-</li>
-</ul>
-</td></tr>
-</tbody></table>
 </blockquote>
 
-
-
 <p><i>[
-Kona (2007): We like the change to the <tt>Swappable</tt> requirements to use
-move semantics. The issue relating to the support of proxies is
-separable from the one relating to move semantics, and it's bigger than
-just swap. We'd like to address only the move semantics changes under
-this issue, and open a separated issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>) to handle proxies. Also, there
-may be a third issue, in that the current definition of <tt>Swappable</tt> does
-not permit rvalues to be operands to a swap operation, and Howard's
-proposed resolution would allow the right-most operand to be an rvalue,
-but it would not allow the left-most operand to be an rvalue (some swap
-functions in the library have been overloaded to permit left operands to
-swap to be rvalues).
+post Sophia Antipolis Howard updated proposed wording:
 ]</i></p>
 
 
@@ -8419,592 +7898,302 @@ swap to be rvalues).
 
 
 <hr>
-<h3><a name="673"></a>673. <tt>unique_ptr</tt> update</h3>
-<p><b>Section:</b> 20.6.11 [unique.ptr] <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>Date:</b> 2007-05-04</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr">active issues</a> in [unique.ptr].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr">issues</a> in [unique.ptr].</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.4 [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>Date:</b> 2007-05-05</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</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#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Since the publication of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
-there have been a few small but significant advances which should be included into
-<tt>unique_ptr</tt>.  There exists a
-<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">example implmenation</a>
-for all of these changes.
+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>
 
-<ul>
-
-<li>
 <p>
-Even though <tt>unique_ptr&lt;void&gt;</tt> is not a valid use case (unlike for <tt>shared_ptr&lt;void&gt;</tt>),
-unexpected cases to crop up which require the instantiation of the interface of <tt>unique_ptr&lt;void&gt;</tt>
-even if it is never used.  For example see
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidently
-happened to <tt>auto_ptr</tt>.  I believe the most robust way to protect <tt>unique_ptr</tt> against this
-type of failure is to augment the return type of <tt>unique_ptr&lt;T&gt;:operator*()</tt> with
-<tt>add_lvalue_reference&lt;T&gt;::type</tt>.  This means that given an instantiated <tt>unique_ptr&lt;void&gt;</tt>
-the act of dereferencing it will simply return <tt>void</tt> instead of causing a compile time failure.
-This is simpler than creating a <tt>unique_ptr&lt;void&gt;</tt> specialization which isn't robust in the
-face of <tt><i>cv-</i></tt>qualified <tt>void</tt> types.
+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>
-This resolution also supports instantiations such as <tt>unique_ptr&lt;void, free_deleter&gt;</tt>
-which could be very useful to the client.
-</p>
 
-</li>
 
-<li>
-<p>
-Efforts have been made to better support containers and smart pointers in shared
-memory contexts.  One of the key hurdles in such support is not assuming that a
-pointer type is actually a <tt>T*</tt>.  This can easily be accomplished
-for <tt>unique_ptr</tt> by having the deleter define the pointer type:
-<tt>D::pointer</tt>.  Furthermore this type can easily be defaulted to
-<tt>T*</tt> should the deleter <tt>D</tt> choose not to define a pointer
-type (example implementation
-<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">here</a>).
-This change has no run time overhead.  It has no interface overhead on
-authors of custom delter types.  It simply allows (but not requires)
-authors of custom deleter types to define a smart pointer for the
-storage type of <tt>unique_ptr</tt> if they find such functionality
-useful.  <tt>std::default_delete</tt> is an example of a deleter which
-defaults <tt>pointer</tt> to <tt>T*</tt> by simply ignoring this issue
-and not including a <tt>pointer typedef</tt>.
-</p>
-</li>
+<p><b>Proposed resolution:</b></p>
 
-<li>
 <p>
-When the deleter type is a function pointer then it is unsafe to construct
-a <tt>unique_ptr</tt> without specifying the function pointer in the constructor.
-This case is easy to check for with a <tt>static_assert</tt> assuring that the
-deleter is not a pointer type in those constructors which do not accept deleters.
+Add to 23.4 [unord]:
 </p>
 
-<blockquote><pre>unique_ptr&lt;A, void(*)(void*)&gt; p(new A);  // error, no function given to delete the pointer!
-</pre></blockquote>
-
-</li>
-
-</ul>
-
-<p><i>[
-Kona (2007): We don't like the solution given to the first bullet in
-light of concepts. The second bullet solves the problem of supporting
-fancy pointers for one library component only. The full LWG needs to
-decide whether to solve the problem of supporting fancy pointers
-piecemeal, or whether a paper addressing the whole library is needed. We
-think that the third bullet is correct.
-]</i></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>
 
-<p><i>[
-Post Kona: Howard adds example user code related to the first bullet:
-]</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>
 
+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);
 
-<blockquote>
-<pre>void legacy_code(void*, std::size_t);
+<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>
 
-void foo(std::size_t N)
-{
-    std::unique_ptr&lt;void, void(*)(void*)&gt; ptr(std::malloc(N), std::free);
-    legacy_code(ptr.get(), N);
-}   // unique_ptr used for exception safety purposes
-</pre>
-</blockquote>
+<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>
-I.e. <tt>unique_ptr&lt;void&gt;</tt> <i>is</i> a useful tool that we don't want
-to disable with concepts.  The only part of <tt>unique_ptr&lt;void&gt;</tt> we
-want to disable (with concepts or by other means) are the two member functions:
-</p>
+...
 
-<blockquote><pre>T&amp; operator*() const;
-T* operator-&gt;() const;
-</pre></blockquote>
+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); 
 
+<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>
 
+<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><b>Proposed resolution:</b></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);
 
-<p><i>[
-I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review
-the proposed resolutions below.
-]</i></p>
+<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>
 
+<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>
 
-<ul>
-<li>
+<p><b><tt>unordered_map</tt></b></p>
 
 <p>
-Change 20.6.11.2 [unique.ptr.single]:
+Change 23.4.1 [unord.map]:
 </p>
 
-<blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
-   ...
-   <del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
-   ...
+<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>
+    ...
 };
-</pre></blockquote>
 
-<p>
-Change 20.6.11.2.4 [unique.ptr.single.observers]:
-</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);
 
-<blockquote><pre><del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
-</pre></blockquote>
+<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>
 
-</li>
+<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>
 
-<li>
 <p>
-Change 20.6.11.2 [unique.ptr.single]:
+Add to 23.4.1.1 [unord.map.cnstr]:
 </p>
 
-<blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
-public:
-  <ins>typedef <i>implementation (see description below)</i> pointer;</ins>
-   ...
-   explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
-   ...
-   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
-   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
-   ...
-   <del>T*</del> <ins>pointer</ins> operator-&gt;() const;
-   <del>T*</del> <ins>pointer</ins> get() const;
-   ...
-   <del>T*</del> <ins>pointer</ins> release();
-   void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
-};
-</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>
 
-<p>
+<blockquote><p>
 <ins>
--3- If the type <tt>remove_reference&lt;D&gt;::type::pointer</tt>
-exists, then <tt>unique_ptr&lt;T, D&gt;::pointer</tt> is a typedef to
-<tt>remove_reference&lt;D&gt;::type::pointer</tt>.  Otherwise
-<tt>unique_ptr&lt;T, D&gt;::pointer</tt> is a typedef to <tt>T*</tt>.
-The type <tt>unique_ptr&lt;T, D&gt;::pointer</tt> shall be <tt>CopyConstructible</tt>
-and <tt>CopyAssignable</tt>.
+<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>
-
-<p>
-Change 20.6.11.2.1 [unique.ptr.single.ctor]:
-</p>
-
-<blockquote><pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
-...
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); 
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); 
-...
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp; d);
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp;&amp; d);
-...
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp; d); 
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp;&amp; d);
-...
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp; d); 
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp;&amp; d);
-...
-</pre></blockquote>
+</p></blockquote>
+</blockquote>
 
 <p>
--23- <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>
-<del>must</del> <ins>shall</ins> be well formed and not throw an exception. If <tt>D</tt> is a
-reference type, then <tt>E</tt> <del>must</del> <ins>shall</ins> be the same type as <tt>D</tt>
-(diagnostic required). <del><tt>U*</tt></del> <ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins>
-<del>must</del> <ins>shall</ins> be implicitly convertible to <del><tt>T*</tt></del>
-<ins>pointer</ins>.
+Add to 23.4.1.2 [unord.map.elem]:
 </p>
 
-<p>
--25- <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before
-the construction, modulo any required offset adjustments resulting from
-the cast from <del><tt>U*</tt></del>
-<ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> to <del><tt>T*</tt></del>
-<ins>pointer</ins>. <tt>get_deleter()</tt> returns a reference to the
-internally stored deleter which was constructed from
-<tt>u.get_deleter()</tt>.
-</p>
+<blockquote>
 
-<p>
-Change 20.6.11.2.3 [unique.ptr.single.asgn]:
-</p>
+<pre>mapped_type&amp; operator[](const key_type&amp; k);</pre>
 
 <blockquote>
-<p>
--8- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
-<tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception. <del><tt>U*</tt></del>
-<ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> <del>must</del> <ins>shall</ins> be implicitly
-convertible to <del><tt>T*</tt></del> <ins>pointer</ins>.
-</p>
+<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>
 
-<p>
-Change 20.6.11.2.4 [unique.ptr.single.observers]:
-</p>
+<pre><ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins></pre>
 
 <blockquote>
-<pre><del>T*</del> <ins>pointer</ins> operator-&gt;() const;</pre>
-...
-<pre><del>T*</del> <ins>pointer</ins> get() const;</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>
-Change 20.6.11.2.5 [unique.ptr.single.modifiers]:
-</p>
+<p><ins>
+<i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
+</ins></p>
 
-<blockquote>
-<pre><del>T*</del> <ins>pointer</ins> release();</pre>
-...
-<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);</pre>
-</blockquote>
+<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>
 
-<p>
-Change 20.6.11.3 [unique.ptr.runtime]:
-</p>
+</blockquote>
 
-<blockquote><pre>template &lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt; {
-public:
-  <ins>typedef <i>implementation</i> pointer;</ins>
-   ...
-   explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
-   ...
-   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
-   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
-   ...
-   <del>T*</del> <ins>pointer</ins> get() const;
-   ...
-   <del>T*</del> <ins>pointer</ins> release();
-   void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
-};
-</pre></blockquote>
+</blockquote>
 
 <p>
-Change 20.6.11.3.1 [unique.ptr.runtime.ctor]:
+Add new section [unord.map.modifiers]:
 </p>
 
 <blockquote>
-<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
+<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>
 
-<p>
-These constructors behave the same as in the primary template except
-that they do not accept pointer types which are convertible to
-<del><tt>T*</tt></del> <ins><tt>pointer</tt></ins>. [<i>Note:</i> One
-implementation technique is to create private templated overloads of
-these members. <i>-- end note</i>]
-</p>
-</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>
-Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]:
-</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>
 
-<blockquote>
-<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
-</pre>
+<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>
--1- <i>Requires:</i> Does not accept pointer types which are convertible
-to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
-required). [<i>Note:</i> One implementation technique is to create a private
-templated overload. <i>-- end note</i>]
-</p>
 </blockquote>
 
-</li>
+</blockquote>
 
-<li>
-
-<p>
-Change 20.6.11.2.1 [unique.ptr.single.ctor]:
-</p>
-
-<blockquote>
-<pre>unique_ptr();</pre>
-<blockquote>
-<p>
-<i>Requires:</i> <tt>D</tt> <del>must</del> <ins>shall</ins> be default constructible, and that
-construction <del>must</del> <ins>shall</ins> not throw an exception. <tt>D</tt> <del>must</del> <ins>shall</ins> not be a
-reference type <ins>or pointer type (diagnostic required)</ins>.
-</p>
-</blockquote>
-<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
-<blockquote>
-<p>
-<i>Requires:</i>  The expression <tt>D()(p)</tt> <del>must</del> <ins>shall</ins> be well formed.
-The default constructor of <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception.
-<tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type <ins>or pointer type (diagnostic
-required)</ins>.
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-Change 20.6.11.2.1 [unique.ptr.single.ctor]:
-</p>
-
-<blockquote>
-<pre>unique_ptr();</pre>
-<blockquote>
-<p>
-<i>Requires:</i> <tt>D</tt> <del>must</del> <ins>shall</ins> be default constructible, and that
-construction <del>must</del> <ins>shall</ins> not throw an exception. <tt>D</tt> <del>must</del> <ins>shall</ins> not be a
-reference type <ins>or pointer type (diagnostic required)</ins>.
-</p>
-</blockquote>
-<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
-<blockquote>
-<p>
-<i>Requires:</i>  The expression <tt>D()(p)</tt> <del>must</del> <ins>shall</ins> be well formed.
-The default constructor of <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception.
-<tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type <ins>or pointer type (diagnostic
-required)</ins>.
-</p>
-</blockquote>
-</blockquote>
-
-</li>
-
-</ul>
-
-
-
-
-
-
-<hr>
-<h3><a name="675"></a>675. Move assignment of containers</h3>
-<p><b>Section:</b> 23.1 [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>Date:</b> 2007-05-05</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>
-James Hopkin pointed out to me that if <tt>vector&lt;T&gt;</tt> move assignment is O(1)
-(just a <tt>swap</tt>) then containers such as <tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> might have
-the wrong semantics under move assignment when the source is not truly an rvalue, but a
-moved-from lvalue (destructors could run late).
-</p>
-
-<blockquote><pre><tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v1;
-<tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v2;
-...
-v1 = v2;               // #1
-v1 = std::move(v2);    // #2
-</pre></blockquote>
-
-<p>
-Move semantics means not caring what happens to the source (<tt>v2</tt> in this example).
-It doesn't mean not caring what happens to the target (<tt>v1</tt>).  In the above example
-both assignments should have the same effect on <tt>v1</tt>.  Any non-shared <tt>ostream</tt>'s
-<tt>v1</tt> owns before the assignment should be closed, whether <tt>v1</tt> is undergoing
-copy assignment or move assignment.
-</p>
-
-<p>
-This implies that the semantics of move assignment of a generic container should be
-<tt>clear, swap</tt> instead of just swap.  An alternative which could achieve the same
-effect would be to move assign each element.  In either case, the complexity of move
-assignment needs to be relaxed to <tt>O(v1.size())</tt>.
-</p>
-
-<p>
-The performance hit of this change is not nearly as drastic as it sounds. 
-In practice, the target of a move assignment has always just been move constructed
-or move assigned <i>from</i>.  Therefore under <tt>clear, swap</tt> semantics (in
-this common use case) we are still achieving O(1) complexity.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 23.1 [container.requirements]:
+Add to 23.4.1.3 [unord.map.swap]:
 </p>
 
 <blockquote>
-<table border="1">
-<caption>Table 86: Container requirements</caption>
-<tbody><tr>
-<th>expression</th><th>return type</th><th>operational semantics</th>
-<th>assertion/note pre/post-condition</th><th>complexity</th>
-</tr>
-<tr>
-<td><tt>a = rv;</tt></td><td><tt>X&amp;</tt></td>
-<td><ins>All existing elements of <tt>a</tt> are either move assigned or destructed</ins></td>
-<td><tt>a</tt> shall be equal to the 
-value that <tt>rv</tt> had 
-before this construction
-</td>
-<td><del>constant</del> <ins>linear in <tt>a.size()</tt></ins></td>
-</tr>
-</tbody></table>
-</blockquote>
-
-
-
-<p><i>[
-post Bellevute Howard adds:
-]</i></p>
-
-
-<blockquote>
-<p>
-This issue was voted to WP in Bellevue, but accidently got stepped on by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
-which was voted to WP simulataneously.  Moving back to Open for the purpose of getting
-the wording right.  The intent of this issue and N2525 are not in conflict.
-</p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="676"></a>676. Moving the unordered containers</h3>
-<p><b>Section:</b> 23.4 [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>Date:</b> 2007-05-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</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#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".
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Add to 23.4 [unord]:
-</p>
-
-<blockquote><pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
+<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); 
-
+            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>
 
-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>
-
-...
-
-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); 
-
-<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>
-
-<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>
-
-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);
-
-<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>
-
-<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>
-
-<p><b><tt>unordered_map</tt></b></p>
+<p><b><tt>unordered_multimap</tt></b></p>
 
 <p>
-Change 23.4.1 [unord.map]:
+Change 23.4.2 [unord.multimap]:
 </p>
 
-<blockquote><pre>class unordered_map
+<blockquote><pre>class unordered_multimap
 {
     ...
-    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>
+    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 
-    <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 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_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>
+    void swap(unordered_multimap&amp;<ins>&amp;</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; y);
+  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_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
+  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_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
+  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>
-Add to 23.4.1.1 [unord.map.cnstr]:
+Add to 23.4.2.1 [unord.multimap.cnstr]:
 </p>
 
 <blockquote>
 <pre>template &lt;class InputIterator&gt;
-  unordered_map(InputIterator f, InputIterator l, 
+  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(), 
@@ -9022,184 +8211,19 @@ then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
 </blockquote>
 
 <p>
-Add to 23.4.1.2 [unord.map.elem]:
+Add new section [unord.multimap.modifiers]:
 </p>
 
 <blockquote>
-
-<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>
-</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>
-
-<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>
-
-<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>
-
-<p>
-Add to 23.4.1.3 [unord.map.swap]:
-</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><b><tt>unordered_multimap</tt></b></p>
-
-<p>
-Change 23.4.2 [unord.multimap]:
-</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(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);
-
-<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>
-Add to 23.4.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>
-
-<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>
-Add new section [unord.multimap.modifiers]:
-</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>
+<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>
@@ -9512,117 +8536,8 @@ that it requires. Please put it back into Open status.
 
 
 <hr>
-<h3><a name="685"></a>685. reverse_iterator/move_iterator difference has invalid signatures</h3>
-<p><b>Section:</b> 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] <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>Date:</b> 2007-06-10</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 C++03 the difference between two <tt>reverse_iterators</tt>
-</p>
-<blockquote><pre>ri1 - ri2
-</pre></blockquote>
-<p>
-is possible to compute only if both iterators have the same base 
-iterator. The result type is the <tt>difference_type</tt> of the base iterator. 
-</p>
-<p>
-In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff] 
-</p>
-<blockquote><pre>template&lt;class Iterator1, class Iterator2&gt; 
-typename reverse_iterator&lt;Iterator&gt;::difference_type 
-   operator-(const reverse_iterator&lt;Iterator1&gt;&amp; x, 
-                    const reverse_iterator&lt;Iterator2&gt;&amp; y);
-</pre></blockquote>
-<p>
-The return type is the same as the C++03 one, based on the no longer 
-present <tt>Iterator</tt> template parameter. 
-</p>
-<p>
-Besides being slightly invalid, should this operator work only when 
-<tt>Iterator1</tt> and <tt>Iterator2</tt> has the same <tt>difference_type</tt>? Or should the 
-implementation choose one of them? Which one? 
-</p>
-<p>
-The same problem now also appears in <tt>operator-()</tt> for <tt>move_iterator</tt>
-24.4.3.3.14 [move.iter.nonmember]. 
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis in 24.4.1.1 [reverse.iterator]:
-</p>
-
-<blockquote>
-<pre>template &lt;class Iterator1, class Iterator2&gt; 
-  <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
-    const reverse_iterator&lt;Iterator1&gt;&amp; x, 
-    const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(y.current - x.current)</ins>;
-</pre>
-</blockquote>
-
-<p>
-Change 24.4.1.3.19 [reverse.iter.opdiff]:
-</p>
-
-<blockquote>
-<pre>template &lt;class Iterator1, class Iterator2&gt; 
-  <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
-    const reverse_iterator&lt;Iterator1&gt;&amp; x, 
-    const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(y.current - x.current)</ins>;
-</pre>
-<blockquote>
-<p>
-<i>Returns:</i> <tt>y.current - x.current</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-
-<p>
-Change the synopsis in 24.4.3.1 [move.iterator]:
-</p>
-
-<blockquote>
-<pre>template &lt;class Iterator1, class Iterator2&gt; 
-  <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
-    const move_iterator&lt;Iterator1&gt;&amp; x, 
-    const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(x.base() - y.base())</ins>;
-</pre>
-</blockquote>
-
-<p>
-Change 24.4.3.3.14 [move.iter.nonmember]:
-</p>
-
-<blockquote>
-<pre>template &lt;class Iterator1, class Iterator2&gt; 
-  <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
-    const move_iterator&lt;Iterator1&gt;&amp; x, 
-    const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(x.base() - y.base())</ins>;
-</pre>
-<blockquote>
-<p>
-<i>Returns:</i> <tt>x.base() - y.base()</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-<p><i>[
-Pre Bellevue:  This issue needs to wait until the <tt>auto -&gt; return</tt> language feature
-goes in.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
 <h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3>
-<p><b>Section:</b> 20.5.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+<p><b>Section:</b> 20.6.5.1 [refwrap.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>Date:</b> 2007-05-10</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.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>
@@ -9643,7 +8558,7 @@ Also please see the thread starting at c++std-lib-17398 for some good discussion
 
 <p><b>Proposed resolution:</b></p>
 <p>
-In 20.5 [function.objects], add the following two signatures to the synopsis:
+In 20.6 [function.objects], add the following two signatures to the synopsis:
 </p>
 
 <blockquote><pre>template &lt;class T&gt; void ref(const T&amp;&amp; t) = delete;
@@ -9679,11 +8594,11 @@ the "special deduction rule" is disabled with the const T&amp;&amp; pattern.
 
 <hr>
 <h3><a name="691"></a>691. const_local_iterator cbegin, cend missing from TR1</h3>
-<p><b>Section:</b> 23.4 [unord], TR1 6.3 [tr.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+<p><b>Section:</b> 23.4 [unord], TR1 6.3 [tr.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
  <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2007-06-14</p>
 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</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>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 last version of TR1 does not include the following member
@@ -9709,7 +8624,7 @@ Is this really an oversight, or am I missing something?
 <p><b>Proposed resolution:</b></p>
 <p>
 Add the following two rows to table 93 (unordered associative container
-requirements) in section 23.1.3 [unord.req]:
+requirements) in section 23.1.5 [unord.req]:
 </p>
 
 <blockquote>
@@ -9766,11 +8681,11 @@ const_local_iterator cend(size_type n) const;</ins>
 
 <hr>
 <h3><a name="692"></a>692. <code>get_money</code> and <code>put_money</code> should be formatted I/O functions</h3>
-<p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 27.6.4 [ext.manip] <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>Date:</b> 2007-06-22</p>
 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</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>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 a private email Bill Plauger notes:
@@ -9891,10 +8806,10 @@ prevent the facet from storing the value.
 
 
 <hr>
-<h3><a name="698"></a>698. Some system_error issues</h3>
-<p><b>Section:</b> 19.4.5.1 [syserr.syserr.overview] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<h3><a name="698"></a>698. <tt>system_error</tt> needs <tt>const char*</tt> constructors</h3>
+<p><b>Section:</b> 19.4.5.1 [syserr.syserr.overview] <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>Date:</b> 2007-06-24</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>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 19.4.5.1 [syserr.syserr.overview] we have the class definition of
@@ -9916,13 +8831,59 @@ accepting a <tt>const char*</tt>.
 
 <p><b>Proposed resolution:</b></p>
 <p>
+This proposed wording assumes issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a> has been accepted and applied to the working paper.
 </p>
 
+<p>
+Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview, as indicated:
+</p>
 
+<blockquote><pre>public:
+  system_error(error_code ec, const string&amp; what_arg);
+  <ins>system_error(error_code ec, const char* what_arg);</ins>
+  system_error(error_code ec);
+  system_error(int ev, const error_category* ecat,
+      const string&amp; what_arg);
+  <ins>system_error(int ev, const error_category* ecat,
+      const char* what_arg);</ins>
+  system_error(int ev, const error_category* ecat);
+</pre></blockquote>
 
+<p>
+To 19.4.5.2 [syserr.syserr.members] Class system_error members add:
+</p>
 
+<blockquote>
+<pre>system_error(error_code ec, const char* what_arg);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
+</p>
+</blockquote>
 
-<hr>
+<pre>system_error(int ev, const error_category* ecat, const char* what_arg);
+</pre>
+
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
 <h3><a name="701"></a>701. assoc laguerre poly's</h3>
 <p><b>Section:</b> TR1 5.2.1.1 [tr.num.sf.Lnm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
  <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p>
@@ -10009,15 +8970,13 @@ not omitted by mistake.
 <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> requires <tt>value_type</tt> to be <tt>MoveConstructible</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 with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
-                                Associative containers with non-<tt>Swappable</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> requires <tt>value_type</tt> to be <tt>Swappable</tt>.
-                                Sequences with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>Swappable</tt>, <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
-                                Associative containers with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
+                                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>
 
 <p>
@@ -10046,7 +9005,7 @@ not omitted by mistake.
                                         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 sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
+                                     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>
 
@@ -10182,151 +9141,77 @@ Kona (2007): Bill and Nick to provide wording.
 
 
 <hr>
-<h3><a name="710"></a>710. Missing postconditions</h3>
-<p><b>Section:</b> 20.6.12.2 [util.smartptr.shared] <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>Date:</b> 2007-08-24</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#Ready">Ready</a> status.</p>
+<h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3>
+<p><b>Section:</b> 21.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-13</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</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 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 <tt>shared_ptr</tt> move constructor and the cast functions are
-missing postconditions for the <tt>get()</tt> accessor.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Move to "ready", adopting the first (Peter's) proposed resolution.
+The changes made for <tt>constexpr</tt> in 21.1.3 [char.traits.specializations] have 
+not only changed the <tt>not_eof</tt> function from pass by const reference to 
+pass by value, it has also changed the parameter type from <tt>int_type</tt> to 
+<tt>char_type</tt>.
 </p>
 <p>
-Note to the project editor: there is an editorial issue here. The
-wording for the postconditions of the casts is slightly awkward, and the
-editor should consider rewording "If w is the return value...", e. g. as
-"For a return value w...".
+This doesn't work for type <tt>char</tt>, and is inconsistent with the 
+requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require].
 </p>
-</blockquote>
-
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Add to 20.6.12.2.1 [util.smartptr.shared.const]:
+Pete adds:
 </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>
-<p>
-<i>Postconditions:</i>  <tt>*this</tt> shall contain the old value of <tt>r</tt>. <tt>r</tt>
-shall be empty. <ins><tt>r.get() == 0</tt>.</ins>
-</p>
-</blockquote>
-</blockquote>
+<blockquote><p>
+For what it's worth, that may not have been an intentional change. 
+N2349, which detailed the changes for adding constant expressions to 
+the library, has strikeout bars through the <tt>const</tt> and the <tt>&amp;</tt> that 
+surround the <tt>char_type</tt> argument, but none through <tt>char_type</tt> itself. 
+So the intention may have been just to change to pass by value, with 
+text incorrectly copied from the standard.
+</p></blockquote>
 
-<p>
-Add to 20.6.12.2.10 [util.smartptr.shared.cast]:
-</p>
 
-<blockquote>
-<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; static_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
-</pre>
-<blockquote>
-<p>
-<ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
-<tt>w.get() == static_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
-</p>
-</blockquote>
-</blockquote>
 
-<blockquote>
-<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; dynamic_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
-</pre>
-<blockquote>
+<p><b>Proposed resolution:</b></p>
 <p>
-<ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast&lt;T*&gt;(r.get())</tt>.</ins>
+Change the signature in 21.1.3.1 [char.traits.specializations.char],
+21.1.3.2 [char.traits.specializations.char16_t], 21.1.3.3 [char.traits.specializations.char32_t],
+and 21.1.3.4 [char.traits.specializations.wchar.t] to
 </p>
-</blockquote>
-</blockquote>
 
-<blockquote>
-<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; const_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
-</pre>
-<blockquote>
-<p>
-<ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
-<tt>w.get() == const_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
-</p>
-</blockquote>
-</blockquote>
+<blockquote><pre>static constexpr int_type not_eof(<del>char_type</del> <ins>int_type</ins> c);
+</pre></blockquote>
 
-<p>
-Alberto Ganesh Barbati has written an
-<a href="http://barbati.net/c++/shared_ptr.pdf">alternative proposal</a>
-where he suggests (among other things) that the casts be respecified in terms of
-the aliasing constructor as follows:
-</p>
 
-<p>
-Change 20.6.12.2.10 [util.smartptr.shared.cast]:
-</p>
 
-<blockquote>
-<p>
--2- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
-shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
-object that stores <tt>static_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
-<tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, static_cast&lt;T*&gt;(r.get())</tt>.</ins>
-</p>
-</blockquote>
+<p><i>[
+Bellevue:
+]</i></p>
 
-<blockquote>
-<p>
--6- <i>Returns:</i>
-</p>
-<ul>
-<li><del>When <tt>dynamic_cast&lt;T*&gt;(r.get())</tt> returns a nonzero value,
-a <tt>shared_ptr&lt;T&gt;</tt> object that stores a copy 
-of it and <i>shares ownership</i> with <tt>r</tt>;</del></li>
-<li><del>Otherwise, an <i>empty</i> <tt>shared_ptr&lt;T&gt;</tt> object.</del></li>
-<li><ins>If <tt>p = dynamic_cast&lt;T*&gt;(r.get())</tt> is a non-null pointer, <tt>shared_ptr&lt;T&gt;(r, p);</tt></ins></li>
-<li><ins>Otherwise, <tt>shared_ptr&lt;T&gt;()</tt>.</ins></li>
-</ul>
-</blockquote>
 
 <blockquote>
-<p>
--10- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
-shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
-object that stores <tt>const_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
-<tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, const_cast&lt;T*&gt;(r.get())</tt>.</ins>
-</p>
+Resolution: NAD editorial - up to Pete's judgment
 </blockquote>
 
-<p>
-This takes care of the missing postconditions for the casts by bringing
-in the aliasing constructor postcondition "by reference".
-</p>
+<p><i>[
+Post Sophia Antipolis
+]</i></p>
 
 
+<blockquote>
+Moved from Pending NAD Editorial to Review.  The proposed wording appears to be correct but non-editorial.
+</blockquote>
 
 
 
 
 <hr>
 <h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
-<p><b>Section:</b> 20.6.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+<p><b>Section:</b> 20.7.12.2.5 [util.smartptr.shared.obs] <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>Date:</b> 2007-08-24</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#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>
 A discussion on
@@ -10355,7 +9240,7 @@ with a non-NULL stored pointer.
 </p>
 
 <p>
-This is contradicted by the second sentence in the Returns clause of 20.6.12.2.5 [util.smartptr.shared.obs]:
+This is contradicted by the second sentence in the Returns clause of 20.7.12.2.5 [util.smartptr.shared.obs]:
 </p>
 
 <blockquote>
@@ -10390,10 +9275,48 @@ on it, but there isn't support for removing this feature at this time.
 </p>
 </blockquote>
 
+<p><i>[
+Sophia Antipolis:
+]</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.
+</p>
+<p>
+&gt; Do you have a use case for r being empty and r being non-null? 
+</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.
+</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.
+</p>
+</blockquote>
+
+
 
 <p><b>Proposed resolution:</b></p>
 <p>
-In keeping the N2351 spirit and obviously my preference, change 20.6.12.2.5 [util.smartptr.shared.obs]:
+In keeping the N2351 spirit and obviously my preference, change 20.7.12.2.5 [util.smartptr.shared.obs]:
 </p>
 
 <blockquote>
@@ -10409,7 +9332,7 @@ Alternative proposed resolution: (I won't be happy if we do this, but it's possi
 </p>
 
 <p>
-Change 20.6.12.2.1 [util.smartptr.shared.const]:
+Change 20.7.12.2.1 [util.smartptr.shared.const]:
 </p>
 
 <blockquote>
@@ -10434,9 +9357,9 @@ instance with a non-NULL stored pointer.
 
 <hr>
 <h3><a name="713"></a>713. <tt>sort()</tt> complexity is too lax</h3>
-<p><b>Section:</b> 25.3.1.1 [sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 25.3.1.1 [sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
  <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-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>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 complexity of <tt>sort()</tt> is specified as "Approximately <tt>N
@@ -10461,8 +9384,8 @@ In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 2
 
 <blockquote>
 <p>
-<i>Complexity:</i> <del>Approximately</del> <ins>O(</ins><i>N</i> log(<i>N</i>)<ins>)</ins> <del>(where <i>N</i> == <i>last</i> - <i>first</i> )
-</del>comparisons<del> on the average</del>.<del><sup>266)</sup></del>
+<i>Complexity:</i> <del>Approximately</del> <ins>O(</ins><i>N</i> log(<i>N</i>)<ins>)</ins> (where <i>N</i> == <i>last</i> - <i>first</i> )
+comparisons<del> on the average</del>.<del><sup>266)</sup></del>
 </p>
 <p>
 <del><sup>266)</sup>
@@ -10478,13 +9401,13 @@ If the worst case behavior is important <tt>stable_sort()</tt> (25.3.1.2) or <tt
 
 <hr>
 <h3><a name="714"></a>714. <tt>search_n</tt> complexity is too lax</h3>
-<p><b>Section:</b> 25.1.9 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 25.1.12 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
  <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.search">issues</a> in [alg.search].</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>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 complexity for <tt>search_n</tt> (25.1.9 [alg.search] par 7) is specified as "At most
+The complexity for <tt>search_n</tt> (25.1.12 [alg.search] par 7) is specified as "At most
 (last - first ) * count applications of the corresponding predicate if
 count is positive, or 0 otherwise." This is unnecessarily pessimistic.
 Regardless of the value of count, there is no reason to examine any
@@ -10523,60 +9446,6 @@ template&lt;class ForwardIterator, class Size, class T,
 
 
 <hr>
-<h3><a name="715"></a>715. <tt>minmax_element</tt> complexity is too lax</h3>
-<p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</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#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The complexity for <tt>minmax_element</tt> (25.3.7 [alg.min.max] par 16) says "At most <tt>max(2 *
-(last - first ) - 2, 0)</tt> applications of the corresponding comparisons",
-i.e. the worst case complexity is no better than calling <tt>min_element</tt> and
-<tt>max_element</tt> separately. This is gratuitously inefficient. There is a
-well known technique that does better: see section 9.1 of CLRS
-(Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 25.3.7 [alg.min.max] to:
-</p>
-
-<blockquote>
-<pre>template&lt;class ForwardIterator&gt; 
-  pair&lt;ForwardIterator, ForwardIterator&gt; 
-    minmax_element(ForwardIterator first , ForwardIterator last); 
-template&lt;class ForwardIterator, class Compare&gt; 
-  pair&lt;ForwardIterator, ForwardIterator&gt; 
-    minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
-</pre>
-<blockquote>
-<p>
-<i>Returns:</i> <tt>make_pair(m, M)</tt>, where <tt>m</tt> is
-<del><tt>min_element(first, last)</tt> or <tt>min_element(first, last,
-comp)</tt></del> <ins>the first iterator in <tt>[first,
-last)</tt> such that no iterator in the range refers to a smaller element,</ins> and
-<ins>where</ins> <tt>M</tt> is <del><tt>max_element(first, last)</tt> or
-<tt>max_element(first, last, comp)</tt></del> <ins>the last iterator
-in <tt>[first, last)</tt> such that no iterator in the range refers to a larger element</ins>.
-</p>
-<p>
-<i>Complexity:</i> At most <del><tt>max(2 * (last - first ) - 2, 0)</tt></del>
-<ins><tt>max(&#8970;(3/2) (N-1)&#8971;, 0)</tt></ins> applications of the
-corresponding <del>comparisons</del> <ins>predicate, where <tt>N</tt> is <tt>distance(first, last)</tt></ins>.
-</p>
-</blockquote>
-</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#New">New</a>
  <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-08-31</p>
@@ -10642,7 +9511,7 @@ Sequence (23.1.1) and for a Reversible Container (23.1).
 </blockquote>
 
 <p>
-First of all, 23.1.1 [sequence.reqmts] is no longer "Sequence" but "Sequence container". 
+First of all, 23.1.3 [sequence.reqmts] is no longer "Sequence" but "Sequence container". 
 Secondly, after the resent changes to containers (<tt>emplace</tt>, <tt>push_back</tt>, 
 <tt>const_iterator</tt> parameters to <tt>insert</tt> and <tt>erase</tt>), <tt>basic_string</tt> is not 
 even close to conform to the current requirements.
@@ -10689,7 +9558,7 @@ different, a string abstraction in its own right.
 
 <hr>
 <h3><a name="719"></a>719. <tt>std::is_literal</tt> type traits should be provided</h3>
-<p><b>Section:</b> 20.4 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+<p><b>Section:</b> 20.5 [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>Date:</b> 2007-08-25</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>
@@ -10720,7 +9589,7 @@ a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
 
 <p>
 I strongly suggest that the standard provides a type traits for
-literal types in 20.4.4.3 [meta.unary.prop] for several reasons:
+literal types in 20.5.4.3 [meta.unary.prop] for several reasons:
 </p>
 
 <ol type="a">
@@ -10782,7 +9651,7 @@ These two issues should move to OPEN pending AM paper on type traits.
 
 <p><b>Proposed resolution:</b></p>
 <p>
-In 20.4.2 [meta.type.synop] in the group "type properties",
+In 20.5.2 [meta.type.synop] in the group "type properties",
 just below the line
 </p>
 
@@ -10797,7 +9666,7 @@ add a new one:
 </pre></blockquote>
 
 <p>
-In 20.4.4.3 [meta.unary.prop], table Type Property Predicates, just
+In 20.5.4.3 [meta.unary.prop], table Type Property Predicates, just
 below the line for the <tt>is_pod</tt> property add a new line:
 </p>
 
@@ -10821,11 +9690,11 @@ array of unknown bound, or
 
 <hr>
 <h3><a name="720"></a>720. Omissions in constexpr usages</h3>
-<p><b>Section:</b> 23.2.1 [array], 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+<p><b>Section:</b> 23.2.1 [array], 23.3.5 [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> Daniel Krügler <b>Date:</b> 2007-08-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>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>
@@ -10847,6 +9716,33 @@ initialisation. What have I overlooked here?
 </li>
 </ol>
 
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+We handle this as two parts
+</p>
+<ol>
+<li>
+The proposed resolution is correct; move to ready.
+</li>
+<li>
+The issue points out a real problem, but the issue is larger than just
+this solution. We believe a paper is needed, applying the full new
+features of C++ (including extensible literals) to update <tt>std::bitset</tt>.
+We note that we do not consider this new work, and that is should be
+handled by the Library Working Group.
+</li>
+</ol>
+<p>
+In order to have a consistent working paper, Alisdair and Daniel produced a new wording for the resolution.
+</p>
+</blockquote>
+
+
 
 <p><b>Proposed resolution:</b></p>
 <ol>
@@ -10917,44 +9813,11 @@ void main()
 
 
 <hr>
-<h3><a name="722"></a>722. Missing [c.math] functions <tt>nanf</tt> and <tt>nanl</tt></h3>
-<p><b>Section:</b> 26.7 [c.math] <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>Date:</b> 2007-08-27</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</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 the listing of 26.7 [c.math], table 108: Header <tt>&lt;cmath&gt;</tt> synopsis I miss
-the following C99 functions (from 7.12.11.2):
-</p>
-
-<blockquote><pre>float nanf(const char *tagp);
-long double nanl(const char *tagp);
-</pre></blockquote>
-
-<p>
-(Note: These functions cannot be overloaded and they are also not
-listed anywhere else)
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 26.7 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt>
-just after the existing entry <tt>nan</tt>.
-</p>
-
-
-
-
-
-<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#New">New</a>
+<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#Open">Open</a>
  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-29</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#New">New</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>
 According to the current state of the standard draft, the class
@@ -10966,6 +9829,15 @@ use cases, where a factory function returns regex values,
 which would take advantage of moveabilities.
 </p>
 
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+Needs wording for the semantics, the idea is agreed upon.
+</blockquote>
+
 
 <p><b>Proposed resolution:</b></p>
 <ol type="a">
@@ -11154,11 +10026,11 @@ following table:
 
 <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#New">New</a>
+<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>Date:</b> 2007-09-22</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#New">New</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>
 Two overloads of <tt>regex_replace()</tt> are currently provided:
@@ -11230,6 +10102,18 @@ is no way to avoid constructing a <tt>basic_string</tt>.)
 </li>
 </ol>
 
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<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><b>Proposed resolution:</b></p>
@@ -11335,10 +10219,10 @@ arguments.
 
 <hr>
 <h3><a name="728"></a>728. Problem in [rand.eng.mers]/6</h3>
-<p><b>Section:</b> 26.4.3.2 [rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+<p><b>Section:</b> 26.4.3.2 [rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng.mers">issues</a> in [rand.eng.mers].</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#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 The <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given 
@@ -11411,6 +10295,16 @@ proposed by Charles Karney should also be included in the proposed
 wording.
 </blockquote>
 
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+Note the main part of the issue is resolved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>.
+</blockquote>
+
 
 
 
@@ -11489,9 +10383,9 @@ for the proposed resolution.
 
 <hr>
 <h3><a name="734"></a>734. Unnecessary restriction in [rand.dist.norm.chisq]</h3>
-<p><b>Section:</b> 26.4.8.4.3 [rand.dist.norm.chisq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+<p><b>Section:</b> 26.4.8.4.3 [rand.dist.norm.chisq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</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>
 <tt>chi_squared_distribution</tt>, <tt>fisher_f_distribution</tt> and <tt>student_t_distribution</tt>
@@ -11528,6 +10422,27 @@ In N2424. Not wildly enthusiastic, not really felt necessary. Less
 frequently used in practice. Not terribly bad either. Move to OPEN.
 </blockquote>
 
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Marc Paterno: The generalizations were explicitly left out when designing the facility. It's harder to test.
+</p>
+<p>
+Marc Paterno: Ask implementers whether floating-point is a significant burden.
+</p>
+<p>
+Alisdair: It's neater to do it now, do ask Bill Plauger.
+</p>
+<p>
+Disposition: move to review with the option for "NAD" if it's not straightforward to implement; unanimous consent.
+</p>
+</blockquote>
+
+
 
 <p><b>Proposed resolution:</b></p>
 <p>
@@ -11615,126 +10530,29 @@ Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() con
 
 
 <hr>
-<h3><a name="740"></a>740. Please remove <tt>*_ptr&lt;T[N]&gt;</tt></h3>
-<p><b>Section:</b> 20.6.11.4 [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Herb Sutter <b>Date:</b> 2007-10-04</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.1.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>Date:</b> 2007-10-10</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>
-Please don't provide <tt>*_ptr&lt;T[N]&gt;</tt>. It doesn't enable any useful
-bounds-checking (e.g., you could imagine that doing <tt>op++</tt> on a
-<tt>shared_ptr&lt;T[N]&gt;</tt> yields a <tt>shared_ptr&lt;T[N-1]&gt;</tt>, but that promising path
-immediately falters on <tt>op--</tt> which can't reliably dereference because we
-don't know the lower bound). Also, most buffers you'd want to point to
-don't have a compile-time known size.
+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>
 
 <p>
-To enable any bounds-checking would require run-time information, with
-the usual triplet: base (lower bound), current offset, and max offset
-(upper  bound). And I can sympathize with the point of view that you
-wouldn't want to require this on <tt>*_ptr</tt> itself. But please let's not
-follow the <tt>&lt;T[N]&gt;</tt> path, especially not with additional functions to
-query the bounds etc., because this sets wrong user expectations by
-embarking on a path that doesn't go all the way to bounds checking as it
-seems to imply.
+This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators.  Here
+is example code:
 </p>
 
-<p>
-If bounds checking is desired, consider a <tt>checked_*_ptr</tt> instead (e.g.,
-<tt>checked_shared_ptr</tt>). And make the interfaces otherwise identical so that
-user code could easily <tt>#define/typedef</tt> between prepending <tt>checked_</tt> on
-debug builds and not doing so on release builds (for example).
-</p>
+<blockquote><pre>namespace Mine {
 
-<p>
-Note that some may object that <tt>checked_*_ptr</tt> may seem to make the smart
-pointer more like <tt>vector</tt>, and we don't want two ways to spell <tt>vector</tt>. I
-don't agree, but if that were true that would be another reason to
-remove <tt>*_ptr&lt;T[N]&gt;</tt> which equally makes the smart pointer more like
-<tt>std::array.</tt> :-)
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>Suggestion that fixed-size array instantiations are going to fail at
-compile time anyway (if we remove specialization) due to pointer decay,
-at least that appears to be result from available compilers.
-</p>
-<p>
-So concerns about about requiring static_assert seem unfounded.
-</p>
-<p>After a little more experimentation with compiler, it appears that
-fixed size arrays would only work at all if we supply these explicit
-specialization. So removing them appears less breaking than originally
-thought.
-</p>
-<p>
-straw poll unanimous move to Ready.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis under 20.6.11 [unique.ptr] p2:
-</p>
-
-<blockquote><pre>...
-template&lt;class T&gt; struct default_delete; 
-template&lt;class T&gt; struct default_delete&lt;T[]&gt;; 
-<del>template&lt;class T, size_t N&gt; struct default_delete&lt;T[N]&gt;;</del>
-
-template&lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr; 
-template&lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt;; 
-<del>template&lt;class T, class D, size_t N&gt; class unique_ptr&lt;T[N], D&gt;;</del>
-...
-</pre></blockquote>
-
-<p>
-Remove the entire section 20.6.11.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete&lt;T[N]&gt;</tt></b>.
-</p>
-
-<p>
-Remove the entire section 20.6.11.4 [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b>
-and its subsections: 20.6.11.4.1 [unique.ptr.compiletime.dtor], 20.6.11.4.2 [unique.ptr.compiletime.observers],
-20.6.11.4.3 [unique.ptr.compiletime.modifiers].
-</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3>
-<p><b>Section:</b> 20.1.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>Date:</b> 2007-10-10</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>
-This issue was split from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
-
-<p>
-This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators.  Here
-is example code:
-</p>
-
-<blockquote><pre>namespace Mine {
-
-template &lt;class T&gt;
-struct proxy {...};
+template &lt;class T&gt;
+struct proxy {...};
 
 template &lt;class T&gt;
 struct proxied_iterator
@@ -11871,224 +10689,9 @@ semantics described in this table.
 
 
 <hr>
-<h3><a name="743"></a>743. rvalue <tt>swap</tt> for <tt>shared_ptr</tt></h3>
-<p><b>Section:</b> 20.6.12.2.9 [util.smartptr.shared.spec] <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>Date:</b> 2007-10-10</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>
-When the LWG looked at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a> in Kona the following note was made:
-</p>
-
-<blockquote><p>
-We may need to open an issue to deal with the question of
-whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
-</p></blockquote>
-
-<p>
-This issue was opened in response to that note.
-</p>
-
-<p>
-I believe allowing rvalue <tt>shared_ptr</tt>s to <tt>swap</tt> is both
-appropriate, and consistent with how other library components are currently specified.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Concern that the three signatures for swap is needlessly complicated,
-but this issue merely brings shared_ptr into equal complexity with the
-rest of the library. Will open a new issue for concern about triplicate
-signatures.
-</p>
-<p>
-Adopt issue as written.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis in 20.6.12.2 [util.smartptr.shared]:
-</p>
-
-<blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
-...
-template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
-<ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
-template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
-</pre></blockquote>
-
-<p>
-Change 20.6.12.2.4 [util.smartptr.shared.mod]:
-</p>
-
-<blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
-</pre></blockquote>
-
-<p>
-Change 20.6.12.2.9 [util.smartptr.shared.spec]:
-</p>
-
-<blockquote><pre>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
-<ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
-template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="744"></a>744. What is the lifetime of an exception pointed to by an exception_ptr?</h3>
-<p><b>Section:</b> 18.7.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> Alisdair Meredith <b>Date:</b> 2007-10-10</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>
-Without some lifetime guarantee, it is hard to know how this type can be
-used.  Very specifically, I don't see how the current wording would
-guarantee and exception_ptr caught at the end of one thread could be safely
-stored and rethrown in another thread - the original motivation for this
-API.
-</p>
-<p>
-(Peter Dimov agreed it should be clearer, maybe a non-normative note to
-explain?)
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Agree the issue is real.
-</p>
-<p>
-Intent is lifetime is similar to a shared_ptr (and we might even want to
-consider explicitly saying that it is a shared_ptr&lt; unspecified type &gt;).
-</p>
-<p>
-We expect that most implementations will use shared_ptr, and the
-standard should be clear that the exception_ptr type is intended to be
-something whose semantics are smart-pointer-like so that the user does
-not need to worry about lifetime management. We still need someone to
-draught those words - suggest emailing Peter Dimov.
-</p>
-<p>
-Move to Open.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 18.7.5 [propagation]/7:
-</p>
-
-<blockquote>
--7- Returns: An <tt>exception_ptr</tt> object that refers to the currently
-handled exception or a copy of the currently handled exception, or a
-null <tt>exception_ptr</tt> object if no exception is being handled.
-<ins>The referenced object remains valid at least as long as there is an
-<tt>exception_ptr</tt> that refers to it.</ins>
-If the function needs to allocate memory and the attempt
-fails, it returns an <tt>exception_ptr</tt> object that refers to an instance of
-<tt>bad_alloc</tt>. It is unspecified whether the return values of two successive
-calls to <tt>current_exception</tt> refer to the same exception object. [<i>Note:</i>
-that is, it is unspecified whether <tt>current_exception</tt> creates a new copy
-each time it is called. <i>--end note</i>]
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="746"></a>746. current_exception may fail with bad_alloc</h3>
-<p><b>Section:</b> 18.7.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> Alisdair Meredith <b>Date:</b> 2007-10-10</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>
-I understand that the attempt to copy an exception may run out of memory,
-but I believe this is the only part of the standard that mandates failure
-with specifically <tt>bad_alloc</tt>, as opposed to allowing an
-implementation-defined type derived from <tt>bad_alloc</tt>.  For instance, the Core
-language for a failed new expression is:
-</p>
-<blockquote>
-<p>
-Any other allocation function that fails to allocate storage shall indicate
-failure only by throwing an exception of a type that would match a handler
-(15.3) of type <tt>std::bad_alloc</tt> (18.5.2.1).
-</p>
-</blockquote>
-<p>
-I think we should allow similar freedom here (or add a blanket
-compatible-exception freedom paragraph in 17)
-</p>
-<p>
-I prefer the clause 17 approach myself, and maybe clean up any outstanding
-wording that could also rely on it.
-</p>
-<p>
-Although filed against a specific case, this issue is a problem throughout
-the library. 
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Is issue bigger than library?
-</p>
-<p>
-No - Core are already very clear about their wording, which is inspiration for the issue.
-</p>
-<p>
-While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue.
-</p>
-<p>
-Accept the broad view and move to ready
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following exemption clause to 17.4.4.8 [res.on.exception.handling]:
-</p>
-
-<blockquote>
-A function may throw a type not listed in its <i>Throws</i> clause so long as it is
-derived from a class named in the <i>Throws</i> clause, and would be caught by an
-exception handler for the base type.
-</blockquote>
-
-
-
-
-
-<hr>
 <h3><a name="747"></a>747. We have 3 separate type traits to identify classes supporting no-throw operations</h3>
-<p><b>Section:</b> 20.4.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>
+<p><b>Section:</b> 20.5.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>Date:</b> 2007-10-10</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>
@@ -12160,80 +10763,9 @@ Move to OPEN. Need to talk to Core about this.
 
 
 <hr>
-<h3><a name="749"></a>749. Currently <tt>has_nothrow_copy_constructor&lt;T&gt;::value</tt> is true if T has 'a' nothrow copy constructor.</h3>
-<p><b>Section:</b> 20.4.4.3 [meta.unary.prop] <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>Date:</b> 2007-10-10</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#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Unfortunately a class can have multiple copy constructors, and I believe to
-be useful this trait should only return true is ALL copy constructors are
-no-throw.
-</p>
-<p>
-For instance:
-</p>
-<blockquote>
-<pre>struct awkward {
- awkward( const awkward &amp; ) throw() {}
- awkward( awkward &amp; ) { throw "oops"; } };
-</pre>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.4.4.3 [meta.unary.prop]:
-</p>
-
-<blockquote>
-<pre>has_trivial_copy_constructor</pre>
-<blockquote>
-<tt>T</tt> is a trivial type (3.9) or a reference type or a class type <del>with a trivial copy constructor</del>
-<ins>where all copy constructors are trivial</ins> (12.8).
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre>has_trivial_assign</pre>
-<blockquote>
-<tt>T</tt> is neither <tt>const</tt> nor a reference type, and <tt>T</tt> is a trivial type (3.9)
-or a class type <del>with a trivial copy assignment operator</del> <ins>where all copy assignment operators are trivial</ins> (12.8).
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre>has_nothrow_copy_constructor</pre>
-<blockquote>
-<tt>has_trivial_copy_constructor&lt;T&gt;::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with
-a</del> <ins>where all</ins> copy constructor<ins>s</ins> <del>that is</del> <ins>are</ins> 
-known not to throw any exceptions or <tt>T</tt> is an
-array of such a class type
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre>has_nothrow_assign</pre>
-<blockquote>
-<tt>T</tt> is neither <tt>const</tt> nor a reference type, and
-<tt>has_trivial_assign&lt;T&gt;::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with a</del>
-<ins>where all</ins> copy
-assignment operator<ins>s</ins> tak<ins>e</ins><del>ing</del> an lvalue of type <tt>T</tt> that is known not to
-throw any exceptions or <tt>T</tt> is an array of such a class type.
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
 <h3><a name="750"></a>750. The current definition for <tt>is_convertible</tt> requires that the type be
 implicitly convertible, so explicit constructors are ignored.</h3>
-<p><b>Section:</b> 20.4.5 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+<p><b>Section:</b> 20.5.5 [meta.rel] <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>Date:</b> 2007-10-10</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>
@@ -12321,11 +10853,11 @@ as-if rule.
 
 <hr>
 <h3><a name="752"></a>752. Allocator complexity requirement</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
  <b>Submitter:</b> Hans Boehm <b>Date:</b> 2007-10-11</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#New">New</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>
 Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations
@@ -12335,13 +10867,13 @@ on the allocators are expected to be amortized constant time."?
 As I think I pointed out earlier, this is currently fiction for
 <tt>allocate()</tt> if it has to obtain memory from the OS, and it's unclear to
 me how to interpret this for <tt>construct()</tt> and <tt>destroy()</tt> if they deal with
-large objects. &nbsp;Would it be controversial to officially let these take
+large objects.  Would it be controversial to officially let these take
 time linear in the size of the object, as they already do in real life?
 </p>
 <p>
 <tt>Allocate()</tt> more blatantly takes time proportional to the size of the
-object if you mix in GC. &nbsp;But it's not really a new problem, and I think
-we'd be confusing things by leaving the bogus requirements there. &nbsp;The
+object if you mix in GC.  But it's not really a new problem, and I think
+we'd be confusing things by leaving the bogus requirements there.  The
 current requirement on <tt>allocate()</tt> is generally not important anyway,
 since it takes O(size) to construct objects in the resulting space.
 There are real performance issues here, but they're all concerned with
@@ -12357,10 +10889,8 @@ Change 20.1.2 [allocator.requirements]/2:
 <blockquote>
 <p>
 -2- Table 39 describes the requirements on types manipulated through
-allocators. All the operations on the allocators are expected to be
-amortized constant time<ins>, except that <tt>allocate</tt> and
-<tt>construct</tt> may require time proportional to the size of the
-object allocated or constructed</ins>. Table 40 describes the
+allocators. <del>All the operations on the allocators are expected to be
+amortized constant time.</del> Table 40 describes the
 requirements on allocator types.
 </p>
 </blockquote>
@@ -12500,189 +11030,15 @@ unfortunately pulling it back to Open.  But I'm drafting wording to atone for th
 
 
 <hr>
-<h3><a name="755"></a>755. <tt>std::vector</tt> and <tt>std:string</tt> lack explicit shrink-to-fit operations</h3>
-<p><b>Section:</b> 23.2.6.2 [vector.capacity], 21.3.4 [string.capacity] <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>Date:</b> 2007-10-31</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#Ready">Ready</a> status.</p>
+<h3><a name="758"></a>758. <tt>shared_ptr</tt> and <tt>nullptr</tt></h3>
+<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-10-31</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#Review">Review</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-A <tt>std::vector</tt> can be shrunk-to-fit via the swap idiom:
-</p>
-
-<blockquote><pre>vector&lt;int&gt; v;
-...
-v.swap(vector&lt;int&gt;(v));  // shrink to fit
-</pre>
-<blockquote><p>
-or:
-</p></blockquote>
-<pre>vector&lt;int&gt;(v).swap(v);  // shrink to fit
-</pre>
-<blockquote><p>
-or:
-</p></blockquote>
-<pre>swap(v, vector&lt;int&gt;(v));  // shrink to fit
-</pre>
-</blockquote>
-
-<p>
-A non-binding request for shrink-to-fit can be made to a <tt>std::string</tt> via:
-</p>
-
-<blockquote><pre>string s;
-...
-s.reserve(0);
-</pre></blockquote>
-
-<p>
-Neither of these is at all obvious to beginners, and even some
-experienced C++ programmers are not aware that shrink-to-fit is
-trivially available.
-</p>
-<p>
-Lack of explicit functions to perform these commonly requested
-operations makes vector and string less usable for non-experts. Because
-the idioms are somewhat obscure, code readability is impaired. It is
-also unfortunate that two similar vector-like containers use different
-syntax for the same operation.
-</p>
-<p>
-The proposed resolution addresses these concerns. The proposed function
-takes no arguments to keep the solution simple and focused.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-To Class template basic_string 21.3 [basic.string] synopsis,
-Class template vector 23.2.6 [vector] synopsis, and Class
-vector&lt;bool&gt; 23.2.7 [vector.bool] synopsis, add:
-</p>
-
-<blockquote><pre>    
-void shrink_to_fit();
-</pre></blockquote>
-
-<p>
-To basic_string capacity 21.3.4 [string.capacity] and vector
-capacity 23.2.6.2 [vector.capacity], add:
-</p>
-
-<blockquote>
-<pre>void shrink_to_fit();
-</pre>
-<blockquote>
-<i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce
-<tt>capacity()</tt> to <tt>size()</tt>. [<i>Note:</i> The request is non-binding to
-allow latitude for implementation-specific optimizations.
-<i>-- end note</i>]
-</blockquote>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="756"></a>756. Container adaptors push</h3>
-<p><b>Section:</b> 23.2.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-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>
-After n2369 we have a single <tt>push_back</tt> overload in the sequence containers,
-of the "emplace" type. At variance with that, still in n2461, we have
-two separate overloads, the C++03 one + one taking an rvalue reference
-in the container adaptors. Therefore, simply from a consistency point of
-view, I was wondering whether the container adaptors should be aligned
-with the specifications of the sequence container themselves: thus have
-a single <tt>push</tt> along the lines:
-</p>
-
-<blockquote><pre>template&lt;typename... _Args&gt;
-void
-push(_Args&amp;&amp;... __args)
-  { c.push_back(std::forward&lt;_Args&gt;(__args)...); }
-</pre></blockquote>
-
-<p><i>[
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 23.2.5.1.1 [queue.defn]:
-</p>
-
-<blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
-<del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
-<ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
-</pre></blockquote>
-
-<p>
-Change 23.2.5.2 [priority.queue]:
-</p>
-
-<blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
-<del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
-<ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
-</pre></blockquote>
-
-<p>
-Change 23.2.5.2.2 [priqueue.members]:
-</p>
-
-<blockquote>
-<pre><del>void push(const value_type&amp; x);</del>
-</pre>
-<blockquote>
-<p>
-<del><i>Effects:</i></del>
-</p>
-<blockquote><pre><del>c.push_back(x);</del>
-<del>push_heap(c.begin(), c.end(), comp);</del>
-</pre></blockquote>
-</blockquote>
-
-<pre><ins>template&lt;class... Args&gt;</ins> void push(<del>value_type</del> <ins>Args</ins>&amp;&amp;<ins>...</ins> <del>x</del> <ins>args</ins>);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i>
-</p>
-<blockquote><pre>c.push_back(std::<del>move</del><ins>forward&lt;Args&gt;</ins>(<del>x</del> <ins>args</ins>)<ins>...</ins>);
-push_heap(c.begin(), c.end(), comp);
-</pre></blockquote>
-</blockquote>
-</blockquote>
-
-<p>
-Change 23.2.5.3.1 [stack.defn]:
-</p>
-
-<blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
-<del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
-<ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="758"></a>758. <tt>shared_ptr</tt> and <tt>nullptr</tt></h3>
-<p><b>Section:</b> 20.6.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-10-31</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#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Consider the following program:
+Consider the following program:
 </p>
 
 <blockquote><pre>int main() {
@@ -12774,7 +11130,7 @@ The following wording changes are less intrusive:
 </p>
 
 <p>
-In 20.6.12.2.1 [util.smartptr.shared.const], add:
+In 20.7.12.2.1 [util.smartptr.shared.const], add:
 </p>
 
 <blockquote><pre>shared_ptr(nullptr_t);
@@ -12832,11 +11188,28 @@ unnecessary; this is effectively an alias for the default constructor.
 </p>
 </blockquote>
 
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+We want to remove the reset functions from the proposed resolution.
+</p>
+<p>
+The remaining proposed resolution text (addressing the constructors) are wanted.
+</p>
+<p>
+Disposition: move to review. The review should check the wording in the then-current working draft.
+</p>
+</blockquote>
+
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add the following constructors to 20.6.12.2 [util.smartptr.shared]:
+Add the following constructors to 20.7.12.2 [util.smartptr.shared]:
 </p>
 
 <blockquote><pre>shared_ptr(nullptr_t);
@@ -12844,17 +11217,10 @@ template &lt;class D&gt; shared_ptr(nullptr_t, D d);
 template &lt;class D, class A&gt; shared_ptr(nullptr_t, D d, A a);
 </pre></blockquote>
 
-<p>
-Add the following methods to 20.6.12.2 [util.smartptr.shared]:
-</p>
 
-<blockquote><pre>void reset(nullptr_t);
-template &lt;class D&gt; void reset(nullptr_t, D d);
-template &lt;class D, class A&gt; void reset(nullptr_t, D d, A a);
-</pre></blockquote>
 
 <p>
-Add the following constructor definitions to 20.6.12.2.1 [util.smartptr.shared.const]:
+Add the following constructor definitions to 20.7.12.2.1 [util.smartptr.shared.const]:
 </p>
 
 <blockquote>
@@ -12905,90 +11271,7 @@ resource other than memory could not be obtained.
 </blockquote>
 </blockquote>
 
-<p>
-Add the following method definitions to 20.6.12.2.4 [util.smartptr.shared.mod]:
-</p>
-
-<blockquote>
-<pre>void reset(nullptr_t);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> Equivalent to <tt>shared_ptr(nullptr).swap(*this)</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre>template &lt;class D&gt; void reset(nullptr_t, const D d)
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> Equivalent to <tt>shared_ptr(nullptr, d).swap(*this)</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre>template &lt;class D, class A&gt; void reset(nullptr_t, D d, A a);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> Equivalent to <tt>shared_ptr(nullptr, d, a).swap(*this)</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="759"></a>759. A reference is not an object</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <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>Date:</b> 2007-11-06</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#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-23.1 [container.requirements] says:
-</p>
-
-<blockquote>
--12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No 
-diagnostic required.
-</blockquote>
-
-<p>
-A reference is not an object, but this sentence appears to claim so.
-</p>
-
-<p>
-What is probably meant here:
-</p>
-<blockquote>
-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><b>Proposed resolution:</b></p>
-<p>
-Change 23.1 [container.requirements]:
-</p>
 
-<blockquote>
--12- <del>Objects passed to member functions of a container as rvalue references shall not be elements</del>
-<ins>An object bound to an rvalue
-reference parameter of a member function of a container shall not be
-an element</ins>
-of that container<del>.</del><ins>;</ins> <del>N</del><ins>n</ins>o 
-diagnostic required.
-</blockquote>
 
 
 
@@ -13015,7 +11298,7 @@ this problem, can be efficiently implemented anyway
 </p>
 
 <p><i>[
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
 ]</i></p>
 
 
@@ -13062,68 +11345,11 @@ sub-objects of elements of the container. No diagnostic required.
 
 
 <hr>
-<h3><a name="761"></a>761. <tt>unordered_map</tt> needs an <tt>at()</tt> member function</h3>
-<p><b>Section:</b> 23.4.1.2 [unord.map.elem] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-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>
-The new member function <tt>at()</tt> was recently added to <tt>std::map()</tt>.  It acts 
-like <tt>operator[]()</tt>, except it throws an exception when the input key is 
-not found.  It is useful when the <tt>map</tt> is <tt>const</tt>, the <tt>value_type</tt> of the 
-key doesn't have  a default constructor, it is an error if the key is 
-not found, or the user wants to avoid accidentally adding an element to 
-the map.  For exactly these same reasons, <tt>at()</tt> would be equally useful 
-in <tt>std::unordered_map</tt>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following functions to the definition of <tt>unordered_map</tt> under "lookup" (23.4.1 [unord.map]):
-</p>
-
-<blockquote><pre>mapped_type&amp; at(const key_type&amp; k);
-const mapped_type &amp;at(const key_type &amp;k) const;
-</pre></blockquote>
-
-<p>
-Add the following definitions to 23.4.1.2 [unord.map.elem]:
-</p>
-
-<blockquote>
-<pre>mapped_type&amp; at(const key_type&amp; k);
-const mapped_type &amp;at(const key_type &amp;k) const;
-</pre>
-<blockquote>
-<p>
-<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>.
-</p>
-<p>
-<i>Throws:</i> An exception object of type <tt>out_of_range</tt> if no such element 
-is present.
-</p>
-</blockquote>
-</blockquote>
-
-<p><i>[
-Bellevue:  Editorial note: the "(unique)" differs from map.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
 <h3><a name="762"></a>762. <tt>std::unique_ptr</tt> requires complete type?</h3>
-<p><b>Section:</b> 20.6.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+<p><b>Section:</b> 20.7.11 [unique.ptr] <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>Date:</b> 2007-11-30</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr">active issues</a> in [unique.ptr].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr">issues</a> in [unique.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>
+<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 contrast to the proposed <tt>std::shared_ptr</tt>, <tt>std::unique_ptr</tt>
@@ -13158,22 +11384,22 @@ produce new wording.
 <p><b>Proposed resolution:</b></p>
 <p>
 The proposed changes in the following revision refers to the current state of
-N2521 including the assumption that 20.6.11.4 [unique.ptr.compiletime] will be removed
-according to the current state of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>.
+N2521 including the assumption that 20.7.11.4 [unique.ptr.compiletime] will be removed
+according to the current state of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>.
 </p>
 <p>
 The specialization <tt>unique_ptr&lt;T[]&gt;</tt> has some more restrictive constraints on
 type-completeness on <tt>T</tt> than <tt>unique_ptr&lt;T&gt;</tt>. The following proposed wordings
 try to cope with that. If the committee sees less usefulness on relaxed
 constraints on <tt>unique_ptr&lt;T[]&gt;</tt>, the alternative would be to stop this relaxation
-e.g. by adding one further bullet to 20.6.11.3 [unique.ptr.runtime]/1:
+e.g. by adding one further bullet to 20.7.11.3 [unique.ptr.runtime]/1:
 "<tt>T</tt> shall be a complete type, if used as template argument of
 <tt>unique_ptr&lt;T[], D&gt;</tt>
 </p>
 <p>
-This issue has some overlap with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, but it seems not to cause any
+This issue has some overlap with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, but it seems not to cause any
 problems with this one,
-because <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> adds only optional requirements on <tt>D</tt> that do not conflict
+because <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> adds only optional requirements on <tt>D</tt> that do not conflict
 with the here discussed
 ones, provided that <tt>D::pointer</tt>'s operations (including default
 construction, copy construction/assignment,
@@ -13185,7 +11411,7 @@ current specification of <tt>unique_ptr</tt>.
 <ol>
 <li>
 <p>
-In 20.6.11 [unique.ptr]/2 add as the last sentence to the existing para:
+In 20.7.11 [unique.ptr]/2 add as the last sentence to the existing para:
 </p>
 
 <blockquote>
@@ -13204,7 +11430,7 @@ function. -- <i>end note</i> ]
 
 <li>
 <p>
-20.6.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
+20.7.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
 </p>
 
 <blockquote>
@@ -13218,14 +11444,14 @@ The current wording says just this.
 
 <li>
 <p>
-In 20.6.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
+In 20.7.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
 </p>
 
 <blockquote>
 <p>
 <i>Requires:</i> <del>The expression <tt>D()(p)</tt> shall be well formed. The default constructor
 of <tt>D</tt> shall not throw an exception.</del>
-<tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type.
+<del><tt>D</tt> must not be a reference type.</del>
 <ins>
 <tt>D</tt> shall be default constructible, and that construction
 shall not throw an exception.
@@ -13255,7 +11481,7 @@ again requires Completeness of <tt>Y</tt>, if <tt>!SameType&lt;X, Y&gt;</tt>
 
 <li>
 <p>
-Merge 20.6.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
+Merge 20.7.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
 of 12, but transferring the "requires" to 13:
 </p>
 
@@ -13274,10 +11500,20 @@ pointer and the <tt>D</tt> deleter are well-formed and well-defined.
 </li>
 
 <li>
-20.6.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary.
+20.7.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary.
 </li>
 <li>
-<p>20.6.11.2.1 [unique.ptr.single.ctor]/21: No changes necessary.</p>
+<p>20.7.11.2.1 [unique.ptr.single.ctor]/21:</p>
+
+<blockquote>
+<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. If <tt>D</tt> is a reference
+type, then <tt>E</tt> shall be the same type as <tt>D</tt> (diagnostic
+required). <tt>U*</tt> shall be implicitly convertible to <tt>T*</tt>.
+<ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
+be complete types. <i>-- end note</i>]</ins>
+</blockquote>
 
 <p><i>[
 N.B.: The current wording of 21 already implicitly guarantees that <tt>U</tt>
@@ -13290,12 +11526,14 @@ e.g. "<tt>U</tt> shall be a complete type."
 
 <li>
 <p>
-20.6.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
+20.7.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
 </p>
 <blockquote>
 <p>
 <i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
 shall have well-defined behavior, and shall not throw exceptions.
+<ins>[<i>Note:</i> The use of <tt>default_delete</tt> requires <tt>T</tt> to
+be a complete type. <i>-- end note</i>]</ins>
 </p>
 <p><i>[
 N.B.: This requirement ensures that the whole responsibility on
@@ -13307,7 +11545,7 @@ type-completeness of <tt>T</tt> is delegated to this expression.
 
 <li>
 <p>
-20.6.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the
+20.7.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the
 current editorial issue, that "must shall" has to be changed to
 "shall", but this change is not a special part of this resolution.
 </p>
@@ -13321,8 +11559,17 @@ further requirements on the requirements of the effects clause
 
 <li>
 <p>
-20.6.11.2.3 [unique.ptr.single.asgn]/6: No changes necessary.
+20.7.11.2.3 [unique.ptr.single.asgn]/6:
 </p>
+
+<blockquote>
+<i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
+<tt>D</tt> shall not throw an exception. <tt>U*</tt> shall be implicitly
+convertible to <tt>T*</tt>.
+<ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
+be complete types. <i>-- end note</i>]</ins>
+</blockquote>
+
 <p><i>[
 N.B.: The current wording of p. 6 already implicitly guarantees that
 <tt>U</tt> is completely defined, because it requires that <tt>Convertible&lt;U*, T*&gt;</tt>
@@ -13333,7 +11580,7 @@ is true, see (6)+(8).
 
 <li>
 <p>
-20.6.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary.
+20.7.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary.
 </p>
 <p><i>[
 N.B.: Delegation to requirements of effects clause is sufficient.
@@ -13342,16 +11589,23 @@ N.B.: Delegation to requirements of effects clause is sufficient.
 </li>
 
 <li>
-20.6.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11: No changes necessary.
+20.7.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11:
 </li>
 
+<blockquote>
+<pre>T* operator-&gt;() const;</pre>
+<blockquote>
+<ins><i>Note:</i> Use typically requires <tt>T</tt> shall be complete. <i>-- end note</i>]</ins>
+</blockquote>
+</blockquote>
+
 <li>
-20.6.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary.
+20.7.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary.
 </li>
 
 <li>
 <p>
-20.6.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph:
+20.7.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph:
 </p>
 <blockquote>
 <i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
@@ -13360,54 +11614,28 @@ shall have well-defined behavior, and shall not throw exceptions.
 </li>
 
 <li>
-20.6.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
+20.7.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
 </li>
 
 <li>
 <p>
-20.6.11.3.1 [unique.ptr.runtime.ctor]: Add one additional paragraph just
-before the current one:
+20.7.11.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1:
 </p>
 
 <blockquote>
 <p>
-<i>Requires:</i> <tt>T</tt> shall be a complete type.
+A specialization for array types is provided with a slightly altered interface.
 </p>
-<p><i>[
-N.B.: We need this requirement, because otherwise it is not
-guaranteed that the c'tors can fulfill their requirements to reject
-any type that is convertible to <tt>T*</tt>.
-]</i></p>
-
-</blockquote>
-</li>
 
+<ul>
 <li>
-20.6.11.3.2 [unique.ptr.runtime.observers]/1: Change the clause to says:
+...
 </li>
-
-<blockquote>
-<i>Requires:</i> <tt>i &lt;</tt> the size of the array to which the stored pointer
-points. <tt>T</tt> shall be a complete type.
-</blockquote>
-
 <li>
-<p>
-20.6.11.3.3 [unique.ptr.runtime.modifiers]/1: Change the first sentence of the
-paragraph to say:
-</p>
-<blockquote>
-<p>
-<i>Requires:</i> <tt>T</tt> shall be a complete type. Does not accept pointer types
-which are convertible to <tt>T*</tt> (diagnostic required). [ Note: ...]
-</p>
-<p><i>[
-N.B. Similar to (15) we need this requirement such that <tt>reset</tt> can
-reject types which are convertible to <tt>T*</tt>
-]</i></p>
-
+<ins><tt>T</tt> shall be a complete type.</ins>
+</li>
+</ul>
 </blockquote>
-
 </li>
 </ol>
 
@@ -13507,157 +11735,233 @@ popular implementations for some standard <code>Containers</code>.
 
 
 <hr>
-<h3><a name="766"></a>766. Inconsistent exception guarantees between ordered and unordered associative containers</h3>
-<p><b>Section:</b> 23.1 [container.requirements], 23.1.3.1 [unord.req.except] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Ion Gaztañaga <b>Date:</b> 2007-12-22</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>
+<h3><a name="769"></a>769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"</h3>
+<p><b>Section:</b> 20.6.15.2 [func.wrap.func] <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>Date:</b> 2008-01-10</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>
-23.1 [container.requirements]p10 states:
-</p>
-
-<blockquote>
-<p>
-Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following
-additional requirements:
+N2461 already replaced in 20.6.15.2 [func.wrap.func] it's originally proposed
+(implicit) conversion operator to "unspecified-bool-type" by the new
+explicit bool conversion, but the inverse conversion should also
+use the new <tt>std::nullptr_t</tt> type instead of "unspecified-null-pointer-
+type".
 </p>
-<ul>
 
-<li>[...]</li>
 
-<li>no <tt>erase()</tt>, <tt>pop_back()</tt> or <tt>pop_front()</tt> function throws an exception.</li>
+<p><b>Proposed resolution:</b></p>
 
-</ul>
-</blockquote>
+<p>
+In 20.6 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis replace:
+</p>
+
+<blockquote><pre>template&lt;class R, class... ArgTypes&gt;
+  bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template&lt;class R, class... ArgTypes&gt;
+  bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
+template&lt;class R, class... ArgTypes&gt;
+  bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template&lt;class R, class... ArgTypes&gt;
+  bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
+</pre></blockquote>
 
 <p>
-23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer
-additional guarantees for <tt>deque</tt>/<tt>vector insert()</tt> and
-<tt>erase()</tt> members. However, 23.1 [container.requirements]p10
-does not mention 23.1.3.1 [unord.req.except] that specifies exception
-safety guarantees
-for unordered containers. In addition, 23.1.3.1 [unord.req.except]p1
-offers the following guaratee for
-<tt>erase()</tt>:
+In the class function synopsis of 20.6.15.2 [func.wrap.func] replace
 </p>
 
-<blockquote>
-No <tt>erase()</tt> function throws an exception unless that exception
-is thrown by the container's Hash or Pred object (if any).
-</blockquote>
+<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+...
+function&amp; operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+</pre></blockquote>
 
 <p>
-Summary:
+In 20.6.15.2 [func.wrap.func], "Null pointer comparisons" replace:
 </p>
 
+<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
+  bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template &lt;class R, class... ArgTypes&gt;
+  bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
+template &lt;class R, class... ArgTypes&gt;
+  bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template &lt;class R, class... ArgTypes&gt;
+  bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
+</pre></blockquote>
+
 <p>
-According to 23.1 [container.requirements]p10 no
-<tt>erase()</tt> function should throw an exception unless otherwise
-specified. Although does not explicitly mention 23.1.3.1 [unord.req.except], this section offers additional guarantees
-for unordered containers, allowing <tt>erase()</tt> to throw if
-predicate or hash function throws.
+In 20.6.15.2.1 [func.wrap.func.con], replace
 </p>
 
+<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+...
+function&amp; operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+</pre></blockquote>
+
 <p>
-In contrast, associative containers have no exception safety guarantees
-section so no <tt>erase()</tt> function should throw, <em>including
-<tt>erase(k)</tt></em> that needs to use the predicate function to
-perform its work. This means that the predicate of an associative
-container is not allowed to throw.
+In 20.6.15.2.6 [func.wrap.func.nullptr], replace
 </p>
 
+<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
+  bool operator==(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template &lt;class R, class... ArgTypes&gt;
+  bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
+</pre></blockquote>
+
 <p>
-So:
+and replace
 </p>
 
-<ol>
-<li>
-<tt>erase(k)</tt> for associative containers is not allowed to throw. On
-the other hand, <tt>erase(k)</tt> for unordered associative containers
-is allowed to throw.
-</li>
-<li>
-<tt>erase(q)</tt> for associative containers is not allowed to throw. On
-the other hand, <tt>erase(q)</tt> for unordered associative containers
-is allowed to throw if it uses the hash or predicate.
-</li>
-<li>
-To fulfill 1), predicates of associative containers are not allowed to throw.
-Predicates of unordered associative containers are allowed to throw.
-</li>
-<li>
-2) breaks a widely used programming pattern (flyweight pattern) for
-unordered containers, where objects are registered in a global map in
-their constructors and unregistered in their destructors. If <tt>erase(q)</tt> is
-allowed to throw, the destructor of the object would need to rethrow the
-exception or swallow it, leaving the object registered.
-</li>
-</ol>
+<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
+  bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template &lt;class R, class... ArgTypes&gt;
+  bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
+</pre></blockquote>
 
 
-<p><b>Proposed resolution:</b></p>
+
+
+
+
+<hr>
+<h3><a name="771"></a>771. Impossible throws clause in [string.conversions]</h3>
+<p><b>Section:</b> 21.4 [string.conversions] <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>Date:</b> 2008-01-13</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.conversions">active issues</a> in [string.conversions].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</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>
-Create a new sub-section of 23.1.2 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
-safety guarantees".
+The new <tt>to_string</tt> and <tt>to_wstring</tt> functions described in 21.4 [string.conversions]
+have throws clauses (paragraphs 8 and 16) which say:
 </p>
 
 <blockquote>
+<i>Throws:</i> nothing
+</blockquote>
+
 <p>
-1 For associative containers, no <tt>clear()</tt> function throws an exception.
-<tt>erase(k)</tt> does not throw an exception unless that exception is thrown by
-the container's Pred object (if any).
+Since all overloads return either a <tt>std::string</tt> or a <tt>std::wstring</tt> by value
+this throws clause is impossible to realize in general, since the <tt>basic_string</tt>
+constructors can fail due to out-of-memory conditions. Either these throws
+clauses should be removed or should be more detailled like:
 </p>
 
+<blockquote>
+<i>Throws:</i> Nothing if the string construction throws nothing
+</blockquote>
+
 <p>
-2 For associative containers, if an exception is thrown by any operation
-from within an <tt>insert()</tt> function inserting a single element, the
-<tt>insert()</tt> function has no effect.
+Further there is an editorial issue in p. 14: All three <tt>to_wstring</tt>
+overloads return a <tt>string</tt>, which should be <tt>wstring</tt> instead (The
+header <tt>&lt;string&gt;</tt> synopsis of 21.2 [string.classes] is correct in this
+regard).
 </p>
 
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-3 For associative containers, no <tt>swap</tt> function throws an exception
-unless that exception is thrown by the copy constructor or copy
-assignment operator of the container's Pred object (if any).
+In 21.4 [string.conversions], remove the paragraphs 8 and 16.
 </p>
+
+<blockquote>
+<pre>string to_string(long long val); 
+string to_string(unsigned long long val); 
+string to_string(long double val); 
+</pre>
+<blockquote>
+<del><i>Throws:</i> nothing</del>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre><ins>w</ins>string to_wstring(long long val); 
+<ins>w</ins>string to_wstring(unsigned long long val); 
+<ins>w</ins>string to_wstring(long double val); 
+</pre>
+<blockquote>
+<del><i>Throws:</i> nothing</del>
+</blockquote>
 </blockquote>
 
+
+
+
+
+
+<hr>
+<h3><a name="772"></a>772.  Impossible return clause in [string.conversions]</h3>
+<p><b>Section:</b> 21.4 [string.conversions] <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>Date:</b> 2008-01-13</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.conversions">active issues</a> in [string.conversions].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</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.1.3.1 [unord.req.except]p1:
+The return clause 21.4 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt>
+overloads says:
 </p>
 
 <blockquote>
-For unordered associative containers, no <tt>clear()</tt> function
-throws an exception. <del>No</del> <tt>erase(<ins>k</ins>)</tt>
-<del>function</del> <ins>does not</ins> throw<del>s</del> an exception
-unless that exception is thrown by the container's Hash or Pred object
-(if any).
+<i>Returns:</i> each function returns a <tt>wstring</tt> object holding the character
+representation of the value of its argument that would be generated by
+calling <tt>wsprintf(buf, fmt, val)</tt> with a format specifier of <tt>L"%lld"</tt>, <tt>L"%ulld"</tt>,
+or <tt>L"%f"</tt>, respectively.
 </blockquote>
 
 <p>
-Change 23.1 [container.requirements]p10 to add references to new sections:
+Problem is: There does not exist any <tt>wsprintf</tt> function in C99 (I checked
+the 2nd edition of ISO 9899, and the first and the second corrigenda from
+2001-09-01 and 2004-11-15). What probably meant here is the function
+<tt>swprintf</tt> from <tt>&lt;wchar.h&gt;/&lt;cwchar&gt;</tt>, but this has the non-equivalent
+declaration:
+</p>
+
+<blockquote><pre>int swprintf(wchar_t * restrict s, size_t n,
+const wchar_t * restrict format, ...);
+</pre></blockquote>
+
+<p>
+therefore the paragraph needs to mention the <tt>size_t</tt> parameter <tt>n</tt>.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the current wording of 21.4 [string.conversions]/p. 15 to:
 </p>
 
 <blockquote>
-Unless otherwise specified (see [deque.modifiers]<ins>,</ins>
-<del>and</del> [vector.modifiers]<ins>, [associative.req.except],
-[unord.req.except]</ins>) all container types defined in this clause meet
-the following additional requirements:
+<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a
+<tt>wstring</tt> object holding the character representation of the
+value of its argument that would be generated by calling
+<tt><del>ws</del><ins>sw</ins>printf(buf, <ins>bufsz,</ins> fmt,
+val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of <tt>L"%lld"</tt>,
+<tt>L"%ulld"</tt>, or <tt>L"%f"</tt>, respectively<ins>, where <tt>buf</tt>
+designates an internal character buffer of sufficient size <tt>bufsz</tt></ins>.
 </blockquote>
 
 <p>
-Change 23.1 [container.requirements]p10 referring to <tt>swap</tt>:
+[Hint to the editor: The resolution also adds to mention the name of
+the format specifier "fmt"]
+</p>
+
+<p>
+I also would like to remark that the current wording of it's equivalent
+paragraph 7 should also mention the meaning of <tt>buf</tt> and <tt>fmt</tt>.
+</p>
+
+<p>
+Change the current wording of 21.4 [string.conversions]/p. 7 to:
 </p>
 
 <blockquote>
-<ul>
-<li>
-no <tt>swap()</tt> function throws an exception<del> unless that exception is thrown
-by the copy constructor or assignment operator of the container's
-Compare object (if any; see [associative.reqmts])</del>.
-</li>
-</ul>
+<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a string object holding the
+character representation of the value of its argument that would be
+generated by calling <tt>sprintf(buf, fmt, val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of
+<tt>"%lld"</tt>, <tt>"%ulld"</tt>, or <tt>"%f"</tt>, respectively<ins>, where <tt>buf</tt> designates an internal
+character buffer of sufficient size</ins>.
 </blockquote>
 
 
@@ -13666,333 +11970,162 @@ Compare object (if any; see [associative.reqmts])</del>.
 
 
 <hr>
-<h3><a name="767"></a>767. Forwarding and backward compatibility</h3>
+<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> Sylvain Pion <b>Date:</b> 2007-12-28</p>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-01-14</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>
-Playing with g++'s C++0X mode, I noticed that the following
-code, which used to compile:
+It appears most containers declare but do not define a member-swap
+function.
 </p>
 
-<blockquote><pre>#include &lt;vector&gt;
-
-int main()
-{
-    std::vector&lt;char *&gt; v;
-    v.push_back(0);
-}
-</pre></blockquote>
-
 <p>
-now fails with the following error message:
+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>.../include/c++/4.3.0/ext/new_allocator.h: In member
-function 'void __gnu_cxx::new_allocator&lt;_Tp&gt;::construct(_Tp*,
-_Args&amp;&amp; ...) [with _Args = int, _Tp = char*]':
-.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void
-std::vector&lt;_Tp, _Alloc&gt;::push_back(_Args&amp;&amp; ...) [with
-_Args = int, _Tp = char*, _Alloc = std::allocator&lt;char*&gt;]'
-test.cpp:6: instantiated from here
-.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid
-conversion from 'int' to 'char*'
-</blockquote>
-
 <p>
-As far as I know, g++ follows the current draft here.
+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>
-Does the committee really intend to break compatibility for such cases?
+A quick survey of clause 23 shows that the following containers provide a
+definition for member-swap:
 </p>
 
-<p><i>[
-Sylvain adds: 
-]</i></p>
-
+<blockquote><pre>array
+queue
+stack
+vector
+</pre></blockquote>
 
-<blockquote>
 <p>
-I just noticed that <tt>std::pair</tt> has the same issue.
-The following now fails with GCC's -std=c++0x mode:
+Whereas the following declare it, but do not define the semantics:
 </p>
 
-<blockquote><pre>#include &lt;utility&gt;
-
-int main()
-{
-   std::pair&lt;char *, char *&gt; p (0,0);
-}
+<blockquote><pre>deque
+list
+map
+multimap
+multiset
+priority_queue
+set
+unordered_map
+unordered_multi_map
+unordered_multi_set
+unordered_set
 </pre></blockquote>
 
 <p>
-I have not made any general audit for such problems elsewhere.
+Suggested resolution:
 </p>
+<blockquote>
+Provide a definition for each of the affected containers...
 </blockquote>
 
 <p><i>[
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>
-]</i></p>
-
-
-<p><i>[
 Bellevue:
 ]</i></p>
 
 
 <blockquote>
-<p>
-Motivation is to handle the old-style int-zero-valued NULL pointers.
-Problem: this solution requires concepts in some cases, which some users
-will be slow to adopt. Some discussion of alternatives involving
-prohibiting variadic forms and additional library-implementation
-complexity.
-</p>
-<p>
-Discussion of "perfect world" solutions, the only such solution put
-forward being to retroactively prohibit use of the integer zero for a
-NULL pointer. This approach was deemed unacceptable given the large
-bodies of pre-existing code that do use integer zero for a NULL pointer.
-</p>
-<p>
-Another approach is to change the member names. Yet another approach is
-to forbid the extension in absence of concepts.
-</p>
-<p>
-Resolution: These issues (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>) will be subsumed into a
-paper to be produced by Alan Talbot in time for review at the 2008
-meeting in France. Once this paper is produced, these issues will be
-moved to NAD.
-</p>
+Move to Open and ask Alisdair to provide wording.
 </blockquote>
 
 
-
 <p><b>Proposed resolution:</b></p>
 <p>
-Add the following rows to Table 90 "Optional sequence container operations", 23.1.1 [sequence.reqmts]:
+Wording provided in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>.
 </p>
 
-<blockquote>
-<table border="1">
-<tbody><tr>
-<th>expression</th> <th>return type</th> <th>assertion/note<br>pre-/post-condition</th> <th>container</th>
-</tr>
 
-<tr>
-<td>
-<tt>a.push_front(t)</tt>
-</td>
-<td>
-<tt>void</tt>
-</td>
-<td>
-<tt>a.insert(a.begin(), t)</tt><br>
-<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
-</td>
-<td>
-<tt>list, deque</tt>
-</td>
-</tr>
-
-<tr>
-<td>
-<tt>a.push_front(rv)</tt>
-</td>
-<td>
-<tt>void</tt>
-</td>
-<td>
-<tt>a.insert(a.begin(), rv)</tt><br>
-<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
-</td>
-<td>
-<tt>list, deque</tt>
-</td>
-</tr>
-
-<tr>
-<td>
-<tt>a.push_back(t)</tt>
-</td>
-<td>
-<tt>void</tt>
-</td>
-<td>
-<tt>a.insert(a.end(), t)</tt><br>
-<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
-</td>
-<td>
-<tt>list, deque, vector, basic_string</tt>
-</td>
-</tr>
 
-<tr>
-<td>
-<tt>a.push_back(rv)</tt>
-</td>
-<td>
-<tt>void</tt>
-</td>
-<td>
-<tt>a.insert(a.end(), rv)</tt><br>
-<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
-</td>
-<td>
-<tt>list, deque, vector, basic_string</tt>
-</td>
-</tr>
 
-</tbody></table>
-</blockquote>
 
+<hr>
+<h3><a name="776"></a>776. Undescribed assign function of std::array</h3>
+<p><b>Section:</b> 23.2.1 [array] <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>Date:</b> 2008-01-20</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#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Change the synopsis in 23.2.2 [deque]:
+The class template array synopsis in 23.2.1 [array]/3 declares a member
+function
 </p>
 
-<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
-<ins>void push_front(T&amp;&amp; x);</ins>
-<ins>void push_back(const T&amp; x);</ins>
-<ins>void push_back(T&amp;&amp; x);</ins>
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
+<blockquote><pre>void assign(const T&amp; u);
 </pre></blockquote>
 
 <p>
-Change 23.2.2.3 [deque.modifiers]:
+which's semantic is no-where described. Since this signature is
+not part of the container requirements, such a semantic cannot
+be derived by those.
 </p>
 
-<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
-<ins>void push_front(T&amp;&amp; x);</ins>
-<ins>void push_back(const T&amp; x);</ins>
-<ins>void push_back(T&amp;&amp; x);</ins>
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
-</pre></blockquote>
-
 <p>
-Change the synopsis in 23.2.4 [list]:
+I found only one reference to this function in the issue list,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a> where the question is raised:
 </p>
 
-<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
-<ins>void push_front(T&amp;&amp; x);</ins>
-<ins>void push_back(const T&amp; x);</ins>
-<ins>void push_back(T&amp;&amp; x);</ins>
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
-</pre></blockquote>
+<blockquote>
+what's the effect of calling <tt>assign(T&amp;)</tt> on a zero-sized array?
+</blockquote>
 
 <p>
-Change 23.2.4.3 [list.modifiers]:
+which does not answer the basic question of this issue.
 </p>
 
-<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
-<ins>void push_front(T&amp;&amp; x);</ins>
-<ins>void push_back(const T&amp; x);</ins>
-<ins>void push_back(T&amp;&amp; x);</ins>
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
-</pre></blockquote>
-
 <p>
-Change the synopsis in 23.2.6 [vector]:
+If this function shall be part of the <tt>std::array</tt>, it's probable
+semantic should correspond to that of <tt>boost::array</tt>, but of
+course such wording must be added.
 </p>
 
-<blockquote><pre><ins>void push_back(const T&amp; x);</ins>
-<ins>void push_back(T&amp;&amp; x);</ins>
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-Change 23.2.6.4 [vector.modifiers]:
+Just after the section 23.2.1.4 [array.data] add the following new section:
 </p>
 
-<blockquote><pre><ins>void push_back(const T&amp; x);</ins>
-<ins>void push_back(T&amp;&amp; x);</ins>
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
-</pre></blockquote>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="768"></a>768. Typos in [atomics]?</h3>
-<p><b>Section:</b> 29.4.3 [atomics.types.generic] <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>Date:</b> 2007-12-28</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 the latest publicly available draft, paper
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">N2641</a>,
-in section 29.4.3 [atomics.types.generic], the following specialization of the template
-<tt>atomic&lt;&gt;</tt> is provided for pointers:
+23.2.1.5 array::fill [array.fill]
 </p>
 
-<blockquote><pre>template &lt;class T&gt; struct atomic&lt;T*&gt; : atomic_address { 
-  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
-  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
-
-  atomic() = default; 
-  constexpr explicit atomic(T); 
-  atomic(const atomic&amp;) = delete; 
-  atomic&amp; operator=(const atomic&amp;) = delete; 
-
-  T* operator=(T*) volatile; 
-  T* operator++(int) volatile; 
-  T* operator--(int) volatile; 
-  T* operator++() volatile; 
-  T* operator--() volatile; 
-  T* operator+=(ptrdiff_t) volatile;
-  T* operator-=(ptrdiff_t) volatile; 
-};
-</pre></blockquote>
+<blockquote>
+<pre>void fill(const T&amp; u);
+</pre>
 
 <p>
-First of all, there is a typo in the non-default constructor which
-should take a <tt>T*</tt> rather than a <tt>T</tt>.
+1: <i>Effects:</i> <tt>fill_n(begin(), N, u)</tt>
 </p>
+</blockquote>
 
 <p>
-As you can see, the specialization redefine and therefore hide a few
-methods from the base class <tt>atomic_address</tt>, namely <tt>fetch_add</tt>, <tt>fetch_sub</tt>,
-<tt>operator=</tt>, <tt>operator+=</tt> and <tt>operator-=</tt>. That's good, but... what happened
-to the other methods, in particular these ones:
+[N.B: I wonder, why class <tt>array</tt> does not have a "modifiers"
+section. If it had, then <tt>assign</tt> would naturally belong to it]
 </p>
 
-<blockquote><pre>void store(T*, memory_order = memory_order_seq_cst) volatile;
-T* load( memory_order = memory_order_seq_cst ) volatile;
-T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
-bool compare_swap( T*&amp;, T*, memory_order, memory_order ) volatile;
-bool compare_swap( T*&amp;, T*, memory_order = memory_order_seq_cst ) volatile;
-</pre></blockquote>
-
 <p>
-By reading paper
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427 "C++ Atomic Types and Operations"</a>,
-I see that the
-definition of the specialization <tt>atomic&lt;T*&gt;</tt> matches the one in the
-draft, but in the example implementation the methods <tt>load()</tt>, <tt>swap()</tt>
-and <tt>compare_swap()</tt> are indeed present.
+Change the synopsis in 23.2.1 [array]/3:
 </p>
 
-<p>
-Strangely, the example implementation does not redefine the method
-<tt>store()</tt>. It's true that a <tt>T*</tt> is always convertible to <tt>void*</tt>, but not
-hiding the <tt>void*</tt> signature from the base class makes the class
-error-prone to say the least: it lets you assign pointers of any type to
-a <tt>T*</tt>, without any hint from the compiler.
-</p>
+<blockquote><pre>template &lt;class T, size_t N&gt;
+struct array { 
+  ...
+  void <del>assign</del> <ins>fill</ins>(const T&amp; u);
+  ...
+</pre></blockquote>
 
-<p>
-Is there a true intent to remove them from the specialization or are
-they just missing from the definition because of a mistake?
-</p>
 
 <p><i>[
 Bellevue:
@@ -14001,46 +12134,40 @@ Bellevue:
 
 <blockquote>
 <p>
-The proposed revisions are accepted.
+Suggest substituting "fill" instead of "assign".
 </p>
 <p>
-Further discussion: why is the ctor labeled "constexpr"? Lawrence said
-this permits the object to be statically initialized, and that's
-important because otherwise there would be a race condition on
-initialization.
+Set state to Review given substitution of "fill" for "assign".
 </p>
 </blockquote>
 
 
-<p><b>Proposed resolution:</b></p>
+
+
+<hr>
+<h3><a name="779"></a>779. Resolution of #283 incomplete</h3>
+<p><b>Section:</b> 25.2.8 [alg.remove] <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>Date:</b> 2008-01-25</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</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 the synopsis in 29.4.3 [atomics.types.generic]:
+The resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> did not resolve similar necessary changes for algorithm
+<tt>remove_copy[_if]</tt>,
+which seems to be an oversight.
 </p>
 
-<blockquote><pre>template &lt;class T&gt; struct atomic&lt;T*&gt; : atomic_address { 
-  <ins>void store(T*, memory_order = memory_order_seq_cst) volatile;</ins>
-  <ins>T* load( memory_order = memory_order_seq_cst ) volatile;</ins>
-  <ins>T* swap( T*, memory_order = memory_order_seq_cst ) volatile;</ins>
-  <ins>bool compare_swap( T*&amp;, T*, memory_order, memory_order ) volatile;</ins>
-  <ins>bool compare_swap( T*&amp;, T*, memory_order = memory_order_seq_cst ) volatile;</ins>
 
-  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
-  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
-
-  atomic() = default; 
-  constexpr explicit atomic(T<ins>*</ins>); 
-  atomic(const atomic&amp;) = delete; 
-  atomic&amp; operator=(const atomic&amp;) = delete; 
+<p><b>Proposed resolution:</b></p>
+<p>
+In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with:
+</p>
 
-  T* operator=(T*) volatile; 
-  T* operator++(int) volatile; 
-  T* operator--(int) volatile; 
-  T* operator++() volatile; 
-  T* operator--() volatile; 
-  T* operator+=(ptrdiff_t) volatile;
-  T* operator-=(ptrdiff_t) volatile; 
-};
-</pre></blockquote>
+<blockquote>
+<i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt>
+and <tt>[result,result + (last - first))</tt> shall not overlap. <ins>The expression <tt>*result = *first</tt> shall be
+valid.</ins>
+</blockquote>
 
 
 
@@ -14048,87 +12175,80 @@ Change the synopsis in 29.4.3 [atomics.types.generic]:
 
 
 <hr>
-<h3><a name="769"></a>769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"</h3>
-<p><b>Section:</b> 20.5.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>Date:</b> 2008-01-10</p>
+<h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3>
+<p><b>Section:</b> 25.3.4 [alg.merge] <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>Date:</b> 2008-01-25</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>
-N2461 already replaced in 20.5.15.2 [func.wrap.func] it's originally proposed
-(implicit) conversion operator to "unspecified-bool-type" by the new
-explicit bool conversion, but the inverse conversion should also
-use the new <tt>std::nullptr_t</tt> type instead of "unspecified-null-pointer-
-type".
+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>
 
-
-<p><b>Proposed resolution:</b></p>
-
 <p>
-In 20.5 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis replace:
+Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.3.4 [alg.merge] in N2461
+have no Requires element and the Effects element contains some requirements,
+which is probably editorial. Worse is that:
 </p>
 
-<blockquote><pre>template&lt;class R, class... ArgTypes&gt;
-  bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template&lt;class R, class... ArgTypes&gt;
-  bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
-template&lt;class R, class... ArgTypes&gt;
-  bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template&lt;class R, class... ArgTypes&gt;
-  bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
-</pre></blockquote>
+<ul>
+<li>
+no assignment requirements are specified (neither implicit nor explicit).
+</li>
 
-<p>
-In the class function synopsis of 20.5.15.2 [func.wrap.func] replace
-</p>
+<li>
+the effects clause just speaks of "merges", which is badly worded
+near to a circular definition.
+</li>
 
-<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-...
-function&amp; operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-</pre></blockquote>
+<li>
+p. 2 mentions a range <tt>[first, last)</tt>, which is not defined by the
+function arguments or otherwise.
+</li>
+
+<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>
 
-<p>
-In 20.5.15.2 [func.wrap.func], "Null pointer comparisons" replace:
-</p>
 
-<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
-  bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template &lt;class R, class... ArgTypes&gt;
-  bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
-template &lt;class R, class... ArgTypes&gt;
-  bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template &lt;class R, class... ArgTypes&gt;
-  bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-In 20.5.15.2.1 [func.wrap.func.con], replace
+In 25.3.4 [alg.merge] replace p.1+ 2:
 </p>
 
-<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-...
-function&amp; operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-</pre></blockquote>
-
+<blockquote>
 <p>
-In 20.5.15.2.6 [func.wrap.func.nullptr], replace
+<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>.
 </p>
 
-<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
-  bool operator==(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template &lt;class R, class... ArgTypes&gt;
-  bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
-</pre></blockquote>
-
 <p>
-and replace
+<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>The results of the expressions <tt>*first1</tt> and <tt>*first2</tt>
+shall be writable to the output iterator.</ins>
 </p>
+</blockquote>
 
-<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
-  bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template &lt;class R, class... ArgTypes&gt;
-  bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
-</pre></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]
+</p>
 
 
 
@@ -14136,648 +12256,524 @@ template &lt;class R, class... ArgTypes&gt;
 
 
 <hr>
-<h3><a name="770"></a>770. std::function should use rvalue swap</h3>
-<p><b>Section:</b> 20.5.15 [func.wrap] <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>Date:</b> 2008-01-10</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="785"></a>785. Random Number Requirements in TR1</h3>
+<p><b>Section:</b> TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> John Maddock <b>Date:</b> 2008-01-15</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 expected that typical implementations of <tt>std::function</tt> will
-use dynamic memory allocations at least under given conditions,
-so it seems appropriate to change the current lvalue swappabilty of
-this class to rvalue swappability.
+Table 16 of TR1 requires that all Pseudo Random Number generators have a
 </p>
 
+<blockquote><pre>seed(integer-type s)
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-In 20.5 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis, just below of
+member function that is equivalent to:
 </p>
 
-<blockquote><pre>template&lt;class R, class... ArgTypes&gt;
-  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
-<ins>template&lt;class R, class... ArgTypes&gt;
-  void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
-template&lt;class R, class... ArgTypes&gt;
-  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</ins>
+<blockquote><pre>mygen = Generator(s)
 </pre></blockquote>
 
 <p>
-In 20.5.15.2 [func.wrap.func] class <tt>function</tt> definition, change
+But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the
 </p>
 
-<blockquote><pre>void swap(function&amp;<ins>&amp;</ins>);
+<blockquote><pre>template &lt;class Gen&gt;
+seed(Gen&amp;);
 </pre></blockquote>
 
 <p>
-In 20.5.15.2 [func.wrap.func], just below of
+member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
 </p>
 
-<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
-  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
-<ins>template &lt;class R, class... ArgTypes&gt;
-  void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
-template &lt;class R, class... ArgTypes&gt;
-  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</ins>
-</pre></blockquote>
-
 <p>
-In 20.5.15.2.2 [func.wrap.func.mod] change
+So... is this a bug in TR1?
 </p>
 
-<blockquote><pre>void swap(function&amp;<ins>&amp;</ins> other);
-</pre></blockquote>
-
-<p>
-In 20.5.15.2.7 [func.wrap.func.alg] add the two overloads
+<p>This is a real issue BTW, since the Boost implementation does adhere
+to the requirements of Table 16, while at least one commercial
+implementation does not and follows a strict adherence to sections
+5.1.4.5 and 5.1.4.6 instead.
 </p>
 
-<blockquote><pre><ins>template&lt;class R, class... ArgTypes&gt;
-  void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp; f2);
-template&lt;class R, class... ArgTypes&gt;
-  void swap(function&lt;R(ArgTypes...)&gt;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp;&amp; f2);</ins>
-</pre></blockquote>
+<p><i>[
+Jens adds:
+]</i></p>
+
+
+<blockquote>
+Both engines do have the necessary
+constructor, therefore the omission of the <tt>seed()</tt> member
+functions appears to be an oversight.
+</blockquote>
+
 
 
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
 
 
 
 
 <hr>
-<h3><a name="771"></a>771. Impossible throws clause in [string.conversions]</h3>
-<p><b>Section:</b> 21.4 [string.conversions] <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>Date:</b> 2008-01-13</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.conversions">active issues</a> in [string.conversions].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</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="787"></a>787. complexity of <tt>binary_search</tt></h3>
+<p><b>Section:</b> 25.3.3.4 [binary.search] <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>Date:</b> 2007-09-08</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 new <tt>to_string</tt> and <tt>to_wstring</tt> functions described in 21.4 [string.conversions]
-have throws clauses (paragraphs 8 and 16) which say:
+In 25.3.3.4 [binary.search]/3 the complexity of <tt>binary_search</tt> is described as
 </p>
 
 <blockquote>
-<i>Throws:</i> nothing
+At most <tt>log(last - first) + 2</tt> comparisons.
 </blockquote>
 
 <p>
-Since all overloads return either a <tt>std::string</tt> or a <tt>std::wstring</tt> by value
-this throws clause is impossible to realize in general, since the <tt>basic_string</tt>
-constructors can fail due to out-of-memory conditions. Either these throws
-clauses should be removed or should be more detailled like:
+This should be precised and brought in line with the nomenclature used for
+<tt>lower_bound</tt>, <tt>upper_bound</tt>, and <tt>equal_range</tt>.
 </p>
 
-<blockquote>
-<i>Throws:</i> Nothing if the string construction throws nothing
-</blockquote>
-
 <p>
-Further there is an editorial issue in p. 14: All three <tt>to_wstring</tt>
-overloads return a <tt>string</tt>, which should be <tt>wstring</tt> instead (The
-header <tt>&lt;string&gt;</tt> synopsis of 21.2 [string.classes] is correct in this
-regard).
+All existing libraries I'm aware of, delegate to
+<tt>lower_bound</tt> (+ one further comparison). Since
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>
+has now WP status, the resolution of #787 should
+be brought in-line with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a> by changing the <tt>+ 2</tt>
+to <tt>+ O(1)</tt>.
 </p>
 
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+Alisdair prefers to apply an upper bound instead of O(1), but that would
+require fixing for <tt>lower_bound</tt>, <tt>upper_bound</tt> etc. as well. If he really
+cares about it, he'll send an issue to Howard.
+</blockquote>
+
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-In 21.4 [string.conversions], remove the paragraphs 8 and 16.
+Change 25.3.3.4 [binary.search]/3
 </p>
 
 <blockquote>
-<pre>string to_string(long long val); 
-string to_string(unsigned long long val); 
-string to_string(long double val); 
-</pre>
-<blockquote>
-<del><i>Throws:</i> nothing</del>
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre><ins>w</ins>string to_wstring(long long val); 
-<ins>w</ins>string to_wstring(unsigned long long val); 
-<ins>w</ins>string to_wstring(long double val); 
-</pre>
-<blockquote>
-<del><i>Throws:</i> nothing</del>
-</blockquote>
+<i>Complexity:</i> At most <tt>log<ins><sub>2</sub></ins>(last - first) + <del>2</del> <ins><i>O</i>(1)</ins></tt> comparisons.
 </blockquote>
 
 
 
 
 
-
 <hr>
-<h3><a name="772"></a>772.  Impossible return clause in [string.conversions]</h3>
-<p><b>Section:</b> 21.4 [string.conversions] <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>Date:</b> 2008-01-13</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.conversions">active issues</a> in [string.conversions].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
+<h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3>
+<p><b>Section:</b> 24.5.1 [istream.iterator] <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>Date:</b> 2008-02-06</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#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The return clause 21.4 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt>
-overloads says:
+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>:
 </p>
 
 <blockquote>
-<i>Returns:</i> each function returns a <tt>wstring</tt> object holding the character
-representation of the value of its argument that would be generated by
-calling <tt>wsprintf(buf, fmt, val)</tt> with a format specifier of <tt>L"%lld"</tt>, <tt>L"%ulld"</tt>,
-or <tt>L"%f"</tt>, respectively.
+<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>
 
 <p>
-Problem is: There does not exist any <tt>wsprintf</tt> function in C99 (I checked
-the 2nd edition of ISO 9899, and the first and the second corrigenda from
-2001-09-01 and 2004-11-15). What probably meant here is the function
-<tt>swprintf</tt> from <tt>&lt;wchar.h&gt;/&lt;cwchar&gt;</tt>, but this has the non-equivalent
-declaration:
+<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).
 </p>
 
-<blockquote><pre>int swprintf(wchar_t * restrict s, size_t n,
-const wchar_t * restrict format, ...);
-</pre></blockquote>
-
 <p>
-therefore the paragraph needs to mention the <tt>size_t</tt> parameter <tt>n</tt>.
+Also I would prefer to be explicit about calling <tt>fail()</tt> here
+(there is no <tt>operator void*()</tt> anymore.)
 </p>
 
 
-
 <p><b>Proposed resolution:</b></p>
 <p>
-Change the current wording of 21.4 [string.conversions]/p. 15 to:
-</p>
-
-<blockquote>
-<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a
-<tt>wstring</tt> object holding the character representation of the
-value of its argument that would be generated by calling
-<tt><del>ws</del><ins>sw</ins>printf(buf, <ins>bufsz,</ins> fmt,
-val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of <tt>L"%lld"</tt>,
-<tt>L"%ulld"</tt>, or <tt>L"%f"</tt>, respectively<ins>, where <tt>buf</tt>
-designates an internal character buffer of sufficient size <tt>bufsz</tt></ins>.
-</blockquote>
-
-<p>
-[Hint to the editor: The resolution also adds to mention the name of
-the format specifier "fmt"]
-</p>
-
-<p>
-I also would like to remark that the current wording of it's equivalent
-paragraph 7 should also mention the meaning of <tt>buf</tt> and <tt>fmt</tt>.
-</p>
-
-<p>
-Change the current wording of 21.4 [string.conversions]/p. 7 to:
+Change 24.5.1 [istream.iterator]/1:
 </p>
 
 <blockquote>
-<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a string object holding the
-character representation of the value of its argument that would be
-generated by calling <tt>sprintf(buf, fmt, val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of
-<tt>"%lld"</tt>, <tt>"%ulld"</tt>, or <tt>"%f"</tt>, respectively<ins>, where <tt>buf</tt> designates an internal
-character buffer of sufficient size</ins>.
+<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="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>Date:</b> 2008-01-14</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="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3>
+<p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</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>
-
-<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>
-
-<p>
-A quick survey of clause 23 shows that the following containers provide a
-definition for member-swap:
+<tt>discrete_distribution</tt> should have a constructor like:
 </p>
 
-<blockquote><pre>array
-queue
-stack
-vector
+<blockquote><pre>template&lt;class _Fn&gt;
+  discrete_distribution(result_type _Count, double _Low, double _High,
+                        _Fn&amp; _Func);
 </pre></blockquote>
 
 <p>
-Whereas the following declare it, but do not define the semantics:
+(Makes it easier to fill a histogram with function values over a range.)
 </p>
 
-<blockquote><pre>deque
-list
-map
-multimap
-multiset
-priority_queue
-set
-unordered_map
-unordered_multi_map
-unordered_multi_set
-unordered_set
-</pre></blockquote>
+<p><i>[
+Bellevue:
+]</i></p>
+
 
-<p>
-Suggested resolution:
-</p>
 <blockquote>
-Provide a definition for each of the affected containers...
+How do you specify the function so that it does not return negative
+values? If you do it is a bad construction. This requirement is already
+there. Where in each bin does one evaluate the function? In the middle.
+Need to revisit tomorrow.
 </blockquote>
 
 <p><i>[
-Bellevue:
+Sophia Antipolis:
 ]</i></p>
 
 
 <blockquote>
-Move to Open and ask Alisdair to provide wording.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Wording provided in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>.
+Bill is not requesting this.
 </p>
-
-
-
-
-
-<hr>
-<h3><a name="775"></a>775. Tuple indexing should be unsigned?</h3>
-<p><b>Section:</b> 20.3.1.4 [tuple.helper] <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>Date:</b> 2008-01-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>
-The tuple element access API identifies the element in the sequence
-using signed integers, and then goes on to enforce the requirement that
-I be &gt;= 0.  There is a much easier way to do this - declare I as
-<tt>unsigned</tt>.
+Marc Paterno: <tt>_Fn</tt> cannot return negative values at the points where the
+function is sampled. It is sampled in the middle of each bin. <tt>_Fn</tt> cannot
+return 0 everywhere it is sampled.
 </p>
 <p>
-In fact the proposal is to use <code>std::size_t</code>, matching the type used in the <tt>tuple_size</tt> API.
+Jens: lambda expressions are rvalues
 </p>
 <p>
-A second suggestion is that it is hard to imagine an API that deduces
-and index at compile time and returns a reference throwing an exception.
-Add a specific <em>Throws:</em> Nothing paragraph to each element
-access API.
+Add a library issue to provide an
+<tt>initializer_list&lt;double&gt;</tt> constructor for
+<tt>discrete_distribution</tt>.
 </p>
 <p>
-In addition to <code>tuple</code>, update the API applies to
-<code>pair</code> and <code>array</code>, and should be updated
-accordingly.
+Marc Paterno: dislikes reference for <tt>_Fn</tt> parameter. Make it pass-by-value (to use lambda),
+use <tt>std::ref</tt> to wrap giant-state function objects.
 </p>
-
 <p>
-A third observation is that the return type of the <code>get</code>
-functions for <code>std::pair</code> is pseudo-code, but it is not
-clearly marked as such.  There is actually no need for pseudo-code as
-the return type can be specified precisely with a call to
-<code>tuple_element</code>.  This is already done for
-<code>std::tuple</code>, and <code>std::array</code> does not have a
-problem as all elements are of type <code>T</code>.
+Daniel: See <tt>random_shuffle</tt>, pass-by-rvalue-reference.
 </p>
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Update header &lt;utility&gt; synopsis in 20.2 [utility]
+Daniel to draft wording.
 </p>
-<pre><em>// 20.2.3, tuple-like access to pair:</em>
-template &lt;class T&gt; class tuple_size;
-template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element;
+</blockquote>
 
-template &lt;class T1, class T2&gt; struct tuple_size&lt;std::pair&lt;T1, T2&gt; &gt;;
-template &lt;class T1, class T2&gt; struct tuple_element&lt;0, std::pair&lt;T1, T2&gt; &gt;;
-template &lt;class T1, class T2&gt; struct tuple_element&lt;1, std::pair&lt;T1, T2&gt; &gt;;
+<p><i>[
+Pre San Francisco, Daniel provided wording:
+]</i></p>
 
-template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
-  <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(std::pair&lt;T1, T2&gt;&amp;);
-template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
-  const <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(const std::pair&lt;T1, T2&gt;&amp;);
-</pre>
-<p>
-Update <strong>20.2.3 [pairs] Pairs</strong>
-</p>
-<pre>template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
-  <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(pair&lt;T1, T2&gt;&amp;);
-template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
-  const <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(const pair&lt;T1, T2&gt;&amp;);
-</pre>
-<p>
-<del>24 <em>Return type:</em> If <code>I == 0</code> then <code>P</code> is <code>T1</code>, if <code>I == 1</code> then <code>P</code> is <code>T2</code>, and otherwise the program is ill-formed.</del>
-</p>
-<p>
-25 <em>Returns:</em> If <code>I == 0</code> returns <code>p.first</code>, <del>otherwise</del> <ins>if <code>I == 1</code></ins> returns <code>p.second</code><ins>, and otherwise the program is ill-formed</ins>.
-</p>
-<p>
-<ins><em>Throws:</em> Nothing.</ins>
-</p>
 
+<blockquote>
+The here proposed changes of the WP refer to the current state of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
+During the Sophia Antipolis meeting two different proposals came up
+regarding the functor argument type, either by value or by rvalue-reference.
+For consistence with existing conventions (state-free algorithms and the
+<tt>general_pdf_distribution</tt> c'tor signature) the author decided to propose a
+function argument that is provided by value. If severe concerns exists that
+stateful functions would be of dominant relevance, it should be possible to
+replace the two occurrences of <tt>Func</tt> by <tt>Func&amp;&amp;</tt> in this proposal as part
+of an editorial process.
+</blockquote>
 
-<p>
-Update header &lt;tuple&gt; synopsis in 20.3 [tuple] with a APIs as below:
-</p>
-<pre>template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element; <em>// undefined</em>
-template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt; class tuple_element&lt;I, tuple&lt;Types...&gt; &gt;;
 
-<em>// 20.3.1.4, element access:</em>
-template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt;
-  typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp; get(tuple&lt;Types...&gt;&amp;);
-template &lt;<del>int</del><ins>size_t</ins> I, class ... types&gt;
-  typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type const&amp; get(const tuple&lt;Types...&gt;&amp;);
-</pre>
 
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
 <p>
-Update <strong>20.3.1.4 [tuple.helper] Tuple helper classes</strong>
-</p>
-<pre>template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt;
-class tuple_element&lt;I, tuple&lt;Types...&gt; &gt; {
-public:
-  typedef TI type;
-};</pre>
-<p>
-1 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
-</p>
-<p>
-2 <em>Type:</em> <code>TI</code> is the type of the <code>I</code>th element of <code>Types</code>, where indexing is zero-based.
-</p>
-<p>
-Update <strong>20.3.1.5 [tuple.elem] Element access</strong>
-</p>
-<pre>template &lt;<del>int</del><ins>size_t</ins> I, class... types &gt;
-typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp; get(tuple&lt;Types...&gt;&amp; t);
-</pre>
-1 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
-<p>
-2 <em>Returns:</em> A reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
-</p>
-<ins><em>Throws:</em> Nothing.</ins>
-<pre>template &lt;<del>int</del><ins>size_t</ins> I, class... types&gt;
-typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type const&amp; get(const tuple&lt;Types...&gt;&amp; t);
-</pre>
-<p>
-3 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
-</p>
-<p>
-4 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
-</p>
-<p>
-<ins><em>Throws:</em> Nothing.</ins>
+In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, just
+<em>before</em> the member declaration
 </p>
 
+<blockquote><pre>explicit discrete_distribution(const param_type&amp; parm);
+</pre></blockquote>
 
 <p>
-Update header &lt;array&gt; synopsis in 20.2 [utility]
+insert:
 </p>
-<pre>template &lt;class T&gt; class tuple_size; <em>// forward declaration</em>
-template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element; <em>// forward declaration</em>
-template &lt;class T, size_t N&gt;
-  struct tuple_size&lt;array&lt;T, N&gt; &gt;;
-template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
-  struct tuple_element&lt;I, array&lt;T, N&gt; &gt;;
-template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
-  T&amp; get(array&lt;T, N&gt;&amp;);
-template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
-  const T&amp; get(const array&lt;T, N&gt;&amp;);
-</pre>
 
+
+<blockquote><pre>template&lt;typename Func&gt;
+discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
+</pre></blockquote>
+</li>
+
+<li>
 <p>
-Update <strong>23.2.1.6 [array.tuple] Tuple interface to class template array</strong>
-</p>
-<pre>tuple_element&lt;<ins>size_t </ins>I, array&lt;T, N&gt; &gt;::type
-</pre>
-<p>
-3 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N.</code> The program is ill-formed if <code>I</code> is out of bounds.
-</p>
-<p>
-4 <em>Value:</em> The type <code>T</code>.
-</p>
-<pre>template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt; T&amp; get(array&lt;T, N&gt;&amp; a);
-</pre>
-<p>
-5 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N</code>. The program is ill-formed if <code>I</code> is out of bounds.
-</p>
-<p>
-<em>Returns:</em> A reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
-</p>
-<p>
-<ins><em>Throws:</em> Nothing.</ins>
+Between p.4 and p.5 insert a series of new paragraphs as part of the
+new member description::
 </p>
-<pre>template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt; const T&amp; get(const array&lt;T, N&gt;&amp; a);
+<blockquote><pre>template&lt;typename Func&gt;
+discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
 </pre>
+
 <p>
-6 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N</code>. The program is ill-formed if <code>I</code> is out of bounds.
-</p>
-<p>
-7 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
+<i>Complexity:</i> Exactly nf invocations of fw.
 </p>
 <p>
-<ins><em>Throws:</em> Nothing.</ins>
+<i>Requires:</i>
 </p>
+<ol type="a">
+<li>
+fw shall be callable with one argument of type double, and shall
+return values of a type convertible to double;</li>
 
+<li>If nf &gt; 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> &lt; <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values
+<tt><i>x</i><sub><i>k</i></sub></tt>, fw(<tt><i>x</i><sub><i>k</i></sub></tt>) shall return a weight value <tt><i>w</i><sub><i>k</i></sub></tt> that is non-negative, non-NaN,
+and non-infinity;</li>
 
-<p><i>[
-Bellevue: Note also that the phrase "The program is ill-formed if I is
-out of bounds" in the requires clauses are probably unnecessary, and
-could be removed at the editor's discretion. Also std:: qualification
-for pair is also unnecessary.
-]</i></p>
-
-
+<li>The following relations shall hold: nf &#8805; 0, and 0 &lt; S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li>
 
+</ol>
 
-<hr>
-<h3><a name="776"></a>776. Undescribed assign function of std::array</h3>
-<p><b>Section:</b> 23.2.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> Daniel Krügler <b>Date:</b> 2008-01-20</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 class template array synopsis in 23.2.1 [array]/3 declares a member
-function
+<i>Effects:</i>
 </p>
+<ol type="a">
+<li>If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and
+   consist of the single value <tt><i>w</i><sub><i>0</i></sub></tt> = 1.</li>
 
-<blockquote><pre>void assign(const T&amp; u);
+<li>
+<p>Otherwise, sets n = nf, deltax = (<tt><i>x</i><sub><i>max</i></sub></tt> - <tt><i>x</i><sub><i>min</i></sub></tt>)/n and <tt><i>x</i><sub><i>cent</i></sub></tt> = <tt><i>x</i><sub><i>min</i></sub></tt> +
+0.5 * deltax.</p>
+<blockquote><pre>For each k = 0, . . . ,n-1, calculates:
+  <tt><i>x</i><sub><i>k</i></sub></tt> = <tt><i>x</i><sub><i>cent</i></sub></tt> + k * deltax
+  <tt><i>w</i><sub><i>k</i></sub></tt> = fw(<tt><i>x</i><sub><i>k</i></sub></tt>)
+</pre></blockquote>
+</li>
+<li>
+<p>Constructs a discrete_distribution object with probabilities:</p>
+<blockquote><pre><tt><i>p</i><sub><i>k</i></sub></tt> = <tt><i>w</i><sub><i>k</i></sub></tt>/S  for k = 0, . . . , n-1.
 </pre></blockquote>
+</li>
+</ol>
+</blockquote>
+</li>
+</ol>
 
-<p>
-which's semantic is no-where described. Since this signature is
-not part of the container requirements, such a semantic cannot
-be derived by those.
-</p>
 
-<p>
-I found only one reference to this function in the issue list,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a> where the question is raised:
-</p>
 
-<blockquote>
-what's the effect of calling <tt>assign(T&amp;)</tt> on a zero-sized array?
-</blockquote>
 
-<p>
-which does not answer the basic question of this issue.
-</p>
 
+<hr>
+<h3><a name="794"></a>794. <tt>piecewise_constant_distribution</tt> missing constructor</h3>
+<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</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 this function shall be part of the <tt>std::array</tt>, it's probable
-semantic should correspond to that of <tt>boost::array</tt>, but of
-course such wording must be added.
+<tt>piecewise_constant_distribution</tt> should have a constructor like:
 </p>
 
+<blockquote><pre>template&lt;class _Fn&gt;
+   piecewise_constant_distribution(size_t _Count,
+            _Ty _Low, _Ty _High, _Fn&amp; _Func);
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Just after the section 23.2.1.4 [array.data] add the following new section:
+(Makes it easier to fill a histogram with function values over a range.
+The two (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>) make a sensible replacement for
+<tt>general_pdf_distribution</tt>.)
 </p>
 
-<p>
-23.2.1.5 array::fill [array.fill]
-</p>
+<p><i>[
+Sophia Antipolis:
+]</i></p>
 
-<blockquote>
-<pre>void fill(const T&amp; u);
-</pre>
 
+<blockquote>
 <p>
-1: <i>Effects:</i> <tt>fill_n(begin(), N, u)</tt>
+Marc: uses variable width of bins and weight for each bin. This is not
+giving enough flexibility to control both variables.
 </p>
-</blockquote>
-
 <p>
-[N.B: I wonder, why class <tt>array</tt> does not have a "modifiers"
-section. If it had, then <tt>assign</tt> would naturally belong to it]
+Add a library issue to provide an constructor taking an
+<tt>initializer_list&lt;double&gt;</tt> and <tt>_Fn</tt> for <tt>piecewise_constant_distribution</tt>.
 </p>
-
 <p>
-Change the synopsis in 23.2.1 [array]/3:
+Daniel to draft wording.
 </p>
-
-<blockquote><pre>template &lt;class T, size_t N&gt;
-struct array { 
-  ...
-  void <del>assign</del> <ins>fill</ins>(const T&amp; u);
-  ...
-</pre></blockquote>
-
+</blockquote>
 
 <p><i>[
-Bellevue:
+Pre San Francisco, Daniel provided wording.
 ]</i></p>
 
 
 <blockquote>
-<p>
-Suggest substituting "fill" instead of "assign".
-</p>
-<p>
-Set state to Review given substitution of "fill" for "assign".
-</p>
+The here proposed changes of the WP refer to the current state of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
+For reasons explained in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, the author decided to propose a function
+argument that is provided by value. The issue proposes a c'tor signature,
+that does not take advantage of the full flexibility of
+<tt>piecewise_constant_distribution</tt>,
+because it restricts on a constant bin width, but the use-case seems to
+be popular enough to justify it's introduction.
 </blockquote>
 
 
 
+<p><b>Proposed resolution:</b></p>
 
-<hr>
-<h3><a name="777"></a>777. Atomics Library Issue</h3>
-<p><b>Section:</b> 29.4.4 [atomics.types.operations] <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>Date:</b> 2008-01-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>
+<ol>
+<li>
 <p>
-The load functions are defined as
+In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
+just <em>before</em> the member declaration
 </p>
 
-<blockquote><pre>C atomic_load(volatile A* object);
-C atomic_load_explicit(volatile A* object, memory_order);
-C A::load(memory_order order = memory_order_seq_cst) volatile;
+<blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
 </pre></blockquote>
-
 <p>
-which prevents their use in <tt>const</tt> contexts.
+insert:
 </p>
+<blockquote><pre>template&lt;typename Func&gt;
+piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
+</pre></blockquote>
+</li>
 
-<p><i>[
-post Bellevue Peter adds:
-]</i></p>
-
-
-<blockquote>
+<li>
 <p>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a> suggests making <tt>atomic_load</tt> operate on <tt>const</tt> objects. There is a
-subtle point here. Atomic loads do not generally write to the object, except
-potentially for the <tt>memory_order_seq_cst</tt> constraint. Depending on the
-architecture, a dummy write with the same value may be required to be issued
-by the atomic load to maintain sequential consistency. This, in turn, may
-make the following code:
+Between p.4 and p.5 insert a new sequence of paragraphs nominated
+below as [p5_1], [p5_2],
+[p5_3], and [p5_4] as part of the new member description:
 </p>
 
-<blockquote><pre>const atomic_int x{};
-
-int main()
-{
-  x.load();
-}
-</pre></blockquote>
-
+<blockquote><pre>template&lt;typename Func&gt;
+piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
+</pre>
+<blockquote>
 <p>
-dump core under a straightforward implementation that puts const objects in
-a read-only section.
+[p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>.
 </p>
 <p>
-There are ways to sidestep the problem, but it needs to be considered.
+[p5_2] <i>Requires:</i>
 </p>
+<ol type="a">
+<li><tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
+return values of a type convertible to double;
+</li>
+<li>
+For all sample values <tt><i>x<sub>k</sub></i></tt> defined below, fw(<tt><i>x<sub>k</sub></i></tt>) shall return a weight
+value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
+</li>
+<li>
+The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> &lt; <tt><i>x<sub>max</sub></i></tt>, and
+0 &lt; S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.
+</li>
+</ol>
 <p>
-The tradeoff is between making the data member of the atomic types
-mutable and requiring the user to explicitly mark atomic members as
-mutable, as is already the case with mutexes.
+[p5_3] <i>Effects:</i>
 </p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
+<ol type="a">
+<li>
+<p>If nf == 0,</p>
+ <ol type="a">
+ <li>
+sets deltax = <tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>, and</li>
+<li> lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
+    value <tt><i>w<sub>0</sub></i></tt> = 1, and</li>
+<li> lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt><i>b<sub>0</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> and 
+              <tt><i>b<sub>1</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt>
+</li>
+</ol>
+</li>
+<li>
+<p>Otherwise,</p>
+<ol type="a">
+<li> sets <tt>n = nf</tt>, <tt>deltax = </tt>(<tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>)/n,
+                 <tt><i>x<sub>cent</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + 0.5 * deltax, and
+</li>
+<li><p>lets the sequences <tt>w</tt> and <tt>b</tt> have length <tt>n</tt> and <tt>n+1</tt>, resp. and</p>
+<blockquote><pre>for each k = 0, . . . ,n-1, calculates:
+  <tt><i>dx<sub>k</sub></i></tt> = k * deltax
+  <tt><i>b<sub>k</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
+  <tt><i>x<sub>k</sub></i></tt> = <tt><i>x<sub>cent</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
+  <tt><i>w<sub>k</sub></i></tt> = fw(<tt><i>x<sub>k</sub></i></tt>),
+</pre></blockquote> 
+<p> and</p>
+</li>
+<li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li>
+</ol>
+</li>
+<li>
 <p>
-Add the <tt>const</tt> qualifier to <tt>*object</tt> and <tt>*this</tt>.
+Constructs a <tt>piecewise_constant_distribution</tt> object with
+the above computed sequence <tt>b</tt> as the interval boundaries
+and with the probability densities:
 </p>
-
-<blockquote><pre>C atomic_load(<ins>const</ins> volatile A* object);
-C atomic_load_explicit(<ins>const</ins> volatile A* object, memory_order);
-C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile;
-</pre></blockquote>
+<blockquote><pre><tt><i>&#961;<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax)  for k = 0, . . . , n-1.
+</pre></blockquote> 
+</li>
+</ol>
+<p>
+[p5_4] <i>Remarks:</i> In this context, the subintervals [<tt><i>b<sub>k</sub></i></tt>, <tt><i>b<sub>k+1</sub></i></tt>) are commonly
+ known as the <i>bins</i> of a histogram.
+ </p>
+</blockquote>
+</blockquote>
+</li>
+</ol>
 
 
 
@@ -14785,1025 +12781,1193 @@ C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile;
 
 
 <hr>
-<h3><a name="778"></a>778. std::bitset does not have any constructor taking a string literal</h3>
-<p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-01-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#bitset.cons">active issues</a> in [bitset.cons].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.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>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a></p>
+<h3><a name="800"></a>800. Issues in 26.4.7.1 [rand.util.seedseq](6)</h3>
+<p><b>Section:</b> 26.4.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> Stephan Tolksdorf <b>Date:</b> 2008-02-18</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</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>
-A small issue with <tt>std::bitset</tt>: it does not have any constructor
-taking a string literal, which is clumsy and looks like an oversigt when
-we tried to enable uniform use of <tt>string</tt> and <tt>const char*</tt> in the library.
-</p>
-
-<p>
-Suggestion: Add
+The for-loop in the algorithm specification has <tt>n</tt> iterations, where <tt>n</tt> is
+defined to be <tt>end - begin</tt>, i.e. the number of supplied w-bit quantities.
+Previous versions of this algorithm and the general logic behind it
+suggest that this is an oversight and that in the context of the
+for-loop <tt>n</tt> should be the number of full 32-bit quantities in <tt>b</tt> (rounded
+upwards). If <tt>w</tt> is 64, the current algorithm throws away half of all bits
+in <tt>b</tt>. If <tt>w</tt> is 16, the current algorithm sets half of all elements in <tt>v</tt>
+to 0.
 </p>
 
-<blockquote><pre>explicit bitset( const char* str );
-</pre></blockquote>
-
 <p>
-to std::bitset.
+There are two more minor issues:
 </p>
 
+<ul>
+<li>
+Strictly speaking <tt>end - begin</tt> is not defined since
+<tt>InputIterator</tt> is not required to be a random access iterator.
+</li>
+<li>
+Currently all integral types are allowed as input to the <tt>seed_seq</tt>
+constructor, including <tt>bool</tt>. IMHO allowing <tt>bool</tt>s unnecessarily
+complicates the implementation without any real benefit to the user.
+I'd suggest to exclude <tt>bool</tt>s as input.
+</li>
+</ul>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to synopsis in 23.3.5 [template.bitset]
-</p>
-
-<blockquote><pre>explicit bitset( const char* str );
-</pre></blockquote>
+<p><i>[
+Bellevue:
+]</i></p>
 
-<p>
-Add to synopsis in 23.3.5.1 [bitset.cons]
-</p>
 
-<blockquote><pre>explicit bitset( const char* str );
-</pre>
-<p>
-<i>Effects:</i> Constructs a <tt>bitset</tt> as if <tt>bitset(string(str))</tt>.
-</p>
+<blockquote>
+Move to OPEN Bill will try to propose a resolution by the next meeting.
 </blockquote>
 
+<p><i>[
+post Bellevue:  Bill provided wording.
+]</i></p>
 
 
-
-
-
-<hr>
-<h3><a name="779"></a>779. Resolution of #283 incomplete</h3>
-<p><b>Section:</b> 25.2.8 [alg.remove] <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>Date:</b> 2008-01-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</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 resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> did not resolve similar necessary changes for algorithm
-<tt>remove_copy[_if]</tt>,
-which seems to be an oversight.
+This issue is made moot if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> is accepted.
 </p>
 
 
+
 <p><b>Proposed resolution:</b></p>
 <p>
-In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with one of:
+Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with:
 </p>
 
 <blockquote>
-<i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt>
-and <tt>[result,result + (last - first))</tt> shall not overlap. <ins>The expression <tt>*result = *first</tt> shall be
-valid.</ins>
-</blockquote>
-
 <p>
-or
+<i>Effects:</i> Constructs a <tt>seed_seq</tt> object by effectively concatenating the
+low-order <tt>u</tt> bits of each of the elements of the supplied sequence <tt>[begin,
+end)</tt>
+in ascending order of significance to make a (possibly very large) unsigned
+binary number <tt>b</tt> having a total of <tt>n</tt> bits, and then carrying out the
+following
+algorithm:
 </p>
 
-<blockquote>
-<i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt>
-and <tt>[result,result + (last - first))</tt> shall not overlap.
-<ins>The result of the expression <tt>*first</tt> shall
-be writable to the output iterator.</ins>
+<blockquote><pre>for( v.clear(); n &gt; 0; n -= 32 )
+   v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
+</pre></blockquote>
 </blockquote>
 
 
 
 
 
-
 <hr>
-<h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3>
-<p><b>Section:</b> 25.3.4 [alg.merge] <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>Date:</b> 2008-01-25</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="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
+<p><b>Section:</b> 20.4 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-02-18</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</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>
-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:
+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>
-Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.3.4 [alg.merge] in N2461
-have no Requires element and the Effects element contains some requirements,
-which is probably editorial. Worse is that:
+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>
-
-<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>
-
-<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>
-
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-In 25.3.4 [alg.merge] replace p.1+ 2:
+There are at least two cases where specification of an explicitly
+defaulted function may be desirable.
 </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>.
+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>
-<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>The results of the expressions <tt>*first1</tt> and <tt>*first2</tt>
-shall be writable to the output iterator.</ins>
+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>
-</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]
+** 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>
-
-
-
-
-
-
-<hr>
-<h3><a name="781"></a>781. <tt>std::complex</tt> should add missing C99 functions</h3>
-<p><b>Section:</b> 26.3.7 [complex.value.ops] <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>Date:</b> 2008-01-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#complex.value.ops">active issues</a> in [complex.value.ops].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</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>
-A comparision of the N2461 header <tt>&lt;complex&gt;</tt> synopsis ([complex.synopsis])
-with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
-some complex functions that are missing in C++. These are:
+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>
 
-<ol>
-<li>
-7.3.9.4: (required elements of the C99 library)<br>
-The <tt>cproj</tt> functions
-</li>
-<li>
-7.26.1: (optional elements of the C99 library)<br>
-<pre>cerf    cerfc    cexp2
-cexpm1  clog10   clog1p
-clog2   clgamma  ctgamma
-</pre>
-</li>
-</ol>
+<blockquote><pre>tuple() = default;
+tuple(const tuple&amp;) = default;
+</pre></blockquote>
 
 <p>
-I propose that at least the required <tt>cproj</tt> overloads are provided as equivalent
-C++ functions. This addition is easy to do in one sentence (delegation to C99
-function).
+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>
-Please note also that the current entry <tt>polar</tt>
-in 26.3.9 [cmplx.over]/1
-should be removed from the mentioned overload list. It does not make sense to require that a
-function already expecting <em>scalar</em> arguments
-should cast these arguments into corresponding
-<tt>complex&lt;T&gt;</tt> arguments, which are not accepted by
-this function.
+** How does the committee wish to trade implementation
+efficiency versus implementation flexibility?
 </p>
 
+<p><i>[
+Bellevue:
+]</i></p>
+
 
-<p><b>Proposed resolution:</b></p>
+<blockquote>
 <p>
-In 26.3.1 [complex.synopsis] add just between the declaration of <tt>conj</tt> and <tt>fabs</tt>:
+General agreement; the first half of the issue is NAD.
 </p>
-
-<blockquote><pre>template&lt;class T&gt; complex&lt;T&gt; conj(const complex&lt;T&gt;&amp;);
-<ins>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp;);</ins>
-template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp;);
-</pre></blockquote>
-
 <p>
-In 26.3.7 [complex.value.ops] just after p.6 (return clause of <tt>conj</tt>) add:
+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>
-
-<blockquote>
-<pre>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp; x);
-</pre>
-<blockquote>
-
-<i>Effects:</i> Behaves the same as C99 function <tt>cproj</tt>, defined in
-subclause 7.3.9.4."
-</blockquote>
-</blockquote>
-
 <p>
-In 26.3.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to
-the overload list.
+Concensus: Go forward, but not at expense of other desired qualities.
 </p>
-
-<blockquote>
 <p>
-The following function templates shall have additional overloads:
+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><pre>arg           norm 
-conj          <del>polar</del> <ins>proj</ins>
-imag          real
-</pre></blockquote>
 </blockquote>
 
 
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
 
 
 
 
 <hr>
-<h3><a name="782"></a>782. Extended <tt>seed_seq</tt> constructor is useless</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <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>Date:</b> 2008-01-27</p>
+<h3><a name="803"></a>803. Simplification of <tt>seed_seq::seq_seq</tt></h3>
+<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Charles Karney <b>Date:</b> 2008-02-22</p>
 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</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#Ready">Ready</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>
-Part of the resolution of n2423, issue 8 was the proposal to
-extend the <tt>seed_seq</tt> constructor accepting an input range
-as follows (which is now part of N2461):
+<tt>seed_seq(InputIterator begin, InputIterator end);</tt> constructs a <tt>seed_seq</tt>
+object repacking the bits of supplied sequence <tt>[begin, end)</tt> into a
+32-bit vector.
 </p>
-
-<blockquote><pre>template&lt;class InputIterator,
-size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits&gt;
-seed_seq(InputIterator begin, InputIterator end);
-</pre></blockquote>
-
 <p>
-First, the expression <tt>iterator_traits&lt;InputIterator&gt;::value_type</tt>
-is invalid due to missing <tt>typename</tt> keyword, which is easy to
-fix.
+This repacking triggers several problems:
 </p>
-
+<ol>
+<li>
+Distinctness of the output of <tt>seed_seq::generate</tt> required the
+introduction of the initial "<tt>if (w &lt; 32) v.push_back(n);</tt>"  (Otherwise
+the unsigned short vectors [1, 0] and [1] generate the same sequence.)
+</li>
+<li>
+Portability demanded the introduction of the template parameter <tt>u</tt>.
+(Otherwise some sequences could not be obtained on computers where no
+integer types are exactly 32-bits wide.)
+</li>
+<li>
+The description and algorithm have become unduly complicated.
+</li>
+</ol>
 <p>
-Second (and worse), while the language now supports default
-template arguments of function templates, this customization
-point via the second <tt>size_t</tt> template parameter is of no advantage,
-because <tt>u</tt> can never be deduced, and worse - because it is a
-constructor function template - it can also never be explicitly
-provided (14.8.1 [temp.arg.explicit]/7).
+I propose simplifying this <tt>seed_seq</tt> constructor to be "32-bit only".
+Despite it's being simpler, there is NO loss of functionality (see
+below).
 </p>
-
 <p>
-The question arises, which advantages result from a compile-time
-knowledge of <tt>u</tt> versus a run time knowledge? If run time knowledge
-suffices, this parameter should be provided as normal function
-default argument [Resolution marked (A)], if compile-time knowledge
-is important, this could be done via a tagging template or more
-user-friendly via a standardized helper generator function
-(<tt>make_seed_seq</tt>), which allows this [Resolution marked (B)].
+Here's how the description would read
 </p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
 <blockquote>
 <p>
-Fermilab does not have a strong opinion. Would prefer to go with
-solution A. Bill agrees that solution A is a lot simpler and does the
-job.
+26.4.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt>
 </p>
-<p>
-Proposed Resolution: Accept Solution A.
+
+<blockquote>
+<pre>template&lt;class InputIterator&gt;
+  seed_seq(InputIterator begin, InputIterator end);
+</pre>
+<blockquote>
+<p>
+5 <i>Requires:</i> NO CHANGE
 </p>
+<p>
+6 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by
+</p>
+<blockquote>
+<pre>for (InputIterator s = begin; s != end; ++s)
+   v.push_back((*s) mod 2^32);
+</pre>
+</blockquote>
+</blockquote>
+</blockquote>
 </blockquote>
 
 <p>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> claims to make this issue moot.
+Discussion:
 </p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<ol type="A">
+<p>
+The chief virtues here are simplicity, portability, and generality.
+</p>
+<ul>
+<li>
+Simplicity -- compare the above specification with the
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> proposal.
+</li>
+<li>
+Portability -- with <tt>iterator_traits&lt;InputIterator&gt;::value_type =
+uint_least32_t</tt> the user is guaranteed to get the same behavior across
+platforms.
+</li>
+<li>
+Generality -- any behavior that the
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
+proposal can achieve can be
+obtained with this simpler proposal (albeit with a shuffling of bits
+in the input sequence).
+</li>
+</ul>
+<p>
+Arguments (and counter-arguments) against making this change (and
+retaining the
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
+behavior) are:
+</p>
+<ul>
 <li>
 <p>
-In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace:
+The user can pass an array of <tt>unsigned char</tt> and <tt>seed_seq</tt> will nicely
+ repack it.
 </p>
-
-<blockquote><pre>class seed_seq 
-{ 
-public:
-   ...
-   template&lt;class InputIterator<del>,
-      size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
-          seed_seq(InputIterator begin, InputIterator end<ins>,
-          size_t u = numeric_limits&lt;typename iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</ins>);
-   ...
-};
+<p>
+ Response: So what?  Consider the seed string "ABC".  The
+ <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
+ proposal results in
+</p>
+<blockquote><pre>v = { 0x3, 0x434241 };
+</pre></blockquote>
+<p>
+while the simplified proposal yields
+</p>
+<blockquote><pre>v = { 0x41, 0x42, 0x43 };
 </pre></blockquote>
-
 <p>
-and do a similar replacement in the member description between
-p.3 and p.4.
+The results produced by <tt>seed_seq::generate</tt> with the two inputs are
+different but nevertheless equivalently "mixed up" and this remains
+true even if the seed string is long.
 </p>
 </li>
-
 <li>
 <p>
-In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis <em>and</em> in the
-member description between p.3 and p.4 replace:
+With long strings (e.g., with bit-length comparable to the number of
+ bits in the state), <tt>v</tt> is longer (by a factor of 4) with the simplified
+ proposal and <tt>seed_seq::generate</tt> will be slower.
 </p>
-
-<blockquote><pre>template&lt;class InputIterator<del>,
-  size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
-         seed_seq(InputIterator begin, InputIterator end);
-<ins>template&lt;class InputIterator, size_t u&gt;
-seed_seq(InputIterator begin, InputIterator end, <i>implementation-defined</i> s);</ins>
-</pre></blockquote>
-
 <p>
-In 26.4.2 [rand.synopsis], header <tt>&lt;random&gt;</tt> synopsis, immediately after the
-class <tt>seed_seq</tt> declaration <em>and</em> in 26.4.7.1 [rand.util.seedseq]/2, immediately
-after the class <tt>seed_seq</tt> definition add:
+Response: It's unlikely that the efficiency of <tt>seed_seq::generate</tt> will
+ be a big issue.  If it is, the user is free to repack the seed vector
+ before constructing <tt>seed_seq</tt>.
 </p>
-
-<blockquote><pre>template&lt;size_t u, class InputIterator&gt;
-  seed_seq make_seed_seq(InputIterator begin, InputIterator end);
+</li>
+<li>
+<p>
+A user can pass an array of 64-bit integers and all the bits will be
+ used.
+</p>
+<p>
+ Response: Indeed.  However, there are many instances in the 
+ <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
+ where integers are silently coerced to a narrower width and this
+ should just be a case of the user needing to read the documentation.
+ The user can of course get equivalent behavior by repacking his seed
+ into 32-bit pieces.  Furthermore, the unportability of the 
+ <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
+ proposal with
+</p>
+<blockquote><pre>unsigned long s[] = {1, 2, 3, 4};
+seed_seq q(s, s+4);
 </pre></blockquote>
+<p>
+ which typically results in <tt>v = {1, 2, 3, 4}</tt> on 32-bit machines and in
+<tt>v = {1, 0, 2, 0, 3, 0, 4, 0}</tt> on 64-bit machines is a major pitfall for
+ unsuspecting users.
+</p>
+</li>
+</ul>
 
 <p>
-In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
+Note: this proposal renders moot issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>.
 </p>
 
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
 <blockquote>
 <p>
-The first constructor behaves as if it would provide an
-integral constant expression <tt>u</tt> of type <tt>size_t</tt> of value
-<tt>numeric_limits&lt;typename iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</tt>.
+Marc Paterno wants portable behavior between 32bit and 64bit machines;
+we've gone to significant trouble to support portability of engines and
+their values.
+</p>
+<p>
+Jens: the new algorithm looks perfectly portable
+</p>
+<p>
+Marc Paterno to review off-line.
 </p>
 <p>
-The second constructor uses an implementation-defined mechanism
-to provide an integral constant expression <tt>u</tt> of type <tt>size_t</tt> and
-is called by the function <tt>make_seed_seq</tt>.
+Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..."
+</p>
+<p>
+Disposition: move to review; unanimous consent.
+</p>
+<p>
+(moots <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>)
 </p>
 </blockquote>
 
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add:
+Change 26.4.7.1 [rand.util.seedseq]:
 </p>
 
 <blockquote>
-<pre>template&lt;size_t u, class InputIterator&gt;
-   seed_seq make_seed_seq(InputIterator begin, InputIterator end);
+<pre>template&lt;class InputIterator<del>, 
+  size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
+  seed_seq(InputIterator begin, InputIterator end);
 </pre>
 <blockquote>
 <p>
-where <tt>u</tt> is used to construct an object <tt>s</tt> of implementation-defined type.
+-5- <i>Requires:</i> <tt>InputIterator</tt> shall satisfy the requirements of an input iterator (24.1.1)
+such that <tt>iterator_traits&lt;InputIterator&gt;::value_type</tt> shall denote an integral type.
+</p>
+<p>
+-6- Constructs a <tt>seed_seq</tt> object by <ins>the following algorithm</ins> <del>rearranging some or all of the bits of the supplied sequence
+<tt>[begin,end)</tt> of w-bit quantities into 32-bit units, as if by the following: </del>
 </p>
 <p>
-<i>Returns:</i> <tt>seed_seq(begin, end, s)</tt>;
+<del>First extract the rightmost <tt>u</tt> bits from each of the <tt>n = end
+- begin</tt> elements of the supplied sequence and concatenate all the
+extracted bits to initialize a single (possibly very large) unsigned
+binary number, <tt>b = &#8721;<sup>n-1</sup><sub>i=0</sub> (begin[i] 
+mod 2<sup>u</sup>) · 2<sup>w·i</sup></tt> (in which the bits of each <tt>begin[i]</tt>
+are treated as denoting an unsigned quantity). Then carry out 
+the following algorithm:</del>
 </p>
+<blockquote><pre><del>
+v.clear(); 
+if ($w$ &lt; 32) 
+  v.push_back($n$); 
+for( ; $n$ &gt; 0; --$n$) 
+  v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
+</del></pre></blockquote>
+<blockquote>
+<pre><ins>
+for (InputIterator s = begin; s != end; ++s)
+   v.push_back((*s) mod 2<sup>32</sup>);
+</ins></pre>
+</blockquote>
 </blockquote>
 </blockquote>
-
-</li>
-</ol>
-
 
 
 
 
 
 <hr>
-<h3><a name="783"></a>783. <tt>thread::id</tt> reuse</h3>
-<p><b>Section:</b> 30.2.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> Hans Boehm <b>Date:</b> 2008-02-01</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="804"></a>804. Some problems with classes <tt>error_code</tt>/<tt>error_condition</tt></h3>
+<p><b>Section:</b> 19.4 [syserr] <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>Date:</b> 2008-02-24</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</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#Review">Review</a> status.</p>
 <p><b>Discussion:</b></p>
+<ol type="A">
+<li>
 <p>
-The current working paper 
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html">N2497</a>,
-integrated just before Bellevue) is
-not completely clear whether a given <tt>thread::id</tt> value may be reused once
-a thread has exited and has been joined or detached.  Posix allows
-thread ids (<tt>pthread_t</tt> values) to be reused in this case.  Although it is
-not completely clear whether this originally was the right decision, it
-is clearly the established practice, and we believe it was always the
-intent of the C++ threads API to follow Posix and allow this.  Howard
-Hinnant's example implementation implicitly relies on allowing reuse
-of ids, since it uses Posix thread ids directly.
+19.4.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> and
+19.4.3.1 [syserr.errcondition.overview]/, class <tt>error_condition</tt> synopses
+declare an expository data member <tt>cat_</tt>:
 </p>
-
+<blockquote><pre>const error_category&amp; cat_; // exposition only
+</pre></blockquote>
+<p>
+which is used to define the semantics of several members. The decision
+to use a member of reference type lead to several problems:
+</p>
+<ol>
+<li>
+The classes are not <tt>(Copy)Assignable</tt>, which is probably not the intent.
+</li>
+<li>
+The post conditions of all modifiers from
+19.4.2.3 [syserr.errcode.modifiers] and 19.4.3.3 [syserr.errcondition.modifiers], resp.,
+cannot be fulfilled.
+</li>
+</ol>
 <p>
-It is important to be clear on this point, since it the reuse of thread
-ids often requires extra care in client code, which would not be
-necessary if thread ids were unique across all time.  For example, a
-hash table indexed by thread id may have to be careful not to associate
-data values from an old thread with a new one that happens to reuse the
-id.  Simply removing the old entry after joining a thread may not be
-sufficient, if it creates a visible window between the join and removal
-during which a new thread with the same id could have been created and
-added to the table.
+The simple fix would be to replace the reference by a pointer member.
 </p>
+</li>
+
+<li>
+I would like to give the editorial remark that in both classes the
+constrained <tt>operator=</tt>
+overload (template with <tt>ErrorCodeEnum</tt> argument) makes in invalid
+usage of <tt>std::enable_if</tt>: By using the default value for the second <tt>enable_if</tt>
+parameter the return type would be defined to be <tt>void&amp;</tt> even in otherwise
+valid circumstances - this return type must be explicitly provided (In
+<tt>error_condition</tt> the first declaration uses an explicit value, but of wrong
+type).
+</li>
+
+<li>
+The member function <tt>message</tt> throws clauses (
+19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and
+19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing",
+although
+they return a <tt>std::string</tt> by value, which might throw in out-of-memory
+conditions (see related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>).
+</li>
+</ol>
 
 <p><i>[
-post Bellevue Peter adds:
+Sophia Antipolis:
 ]</i></p>
 
 
 <blockquote>
 <p>
-There is a real issue with <tt>thread::id</tt> reuse, but I urge the LWG to
-reconsider fixing this by disallowing reuse, rather than explicitly allowing
-it. Dealing with thread id reuse is an incredibly painful exercise that
-would just force the world to reimplement a non-conflicting <tt>thread::id</tt> over
-and over.
+Part A: NAD (editorial), cleared by the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.
 </p>
 <p>
-In addition, it would be nice if a <tt>thread::id</tt> could be manipulated
-atomically in a lock-free manner, as motivated by the recursive lock
-example:
+Part B: Technically correct, save for typo. Rendered moot by the concept proposal 
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2620.html">N2620</a>) NAD (editorial).
 </p>
-
 <p>
-<a href="http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html">http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html</a>
+Part C: We agree; this is consistent with the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>.
 </p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Add a sentence to 30.2.1.1 [thread.thread.id]/p1:
+Howard: please ping Beman, asking him to clear away parts A and B from
+the wording in the proposed resolution, so it is clear to the editor
+what needs to be applied to the working paper.
 </p>
-
-<blockquote>
 <p>
-An object of type <code>thread::id</code> provides
-a unique identifier for each thread of execution
-and a single distinct value for all thread objects
-that do not represent a thread of execution ([thread.threads.class]).
-Each thread of execution has a <code>thread::id</code>
-that is not equal to the <code>thread::id</code>
-of other threads of execution
-and that is not equal to
-the <code>thread::id</code> of <code>std::thread</code> objects
-that do not represent threads of execution.
-<ins>The library may reuse the value of a <code>thread::id</code> of a
-terminated thread that can no longer be joined.</ins>
+Beman provided updated wording. Since issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a> is not going
+forward, the provided wording includes resolution of part A.
 </p>
 </blockquote>
 
 
 
+<p><b>Proposed resolution:</b></p>
 
-
-<hr>
-<h3><a name="785"></a>785. Random Number Requirements in TR1</h3>
-<p><b>Section:</b> TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> John Maddock <b>Date:</b> 2008-01-15</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>
-Table 16 of TR1 requires that all Pseudo Random Number generators have a
+Resolution of part A:
 </p>
-
-<blockquote><pre>seed(integer-type s)
-</pre></blockquote>
-
+<blockquote>
 <p>
-member function that is equivalent to:
+Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview synopsis as indicated:
 </p>
 
-<blockquote><pre>mygen = Generator(s)
+<blockquote><pre>private:
+  int val_;                    // exposition only
+  const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
 </pre></blockquote>
 
 <p>
-But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the
+Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated:
 </p>
 
-<blockquote><pre>template &lt;class Gen&gt;
-seed(Gen&amp;);
-</pre></blockquote>
-
+<blockquote>
+<pre>error_code();
+</pre>
+<blockquote>
 <p>
-member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
+<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
 </p>
-
 <p>
-So... is this a bug in TR1?
+<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>system_category</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+<pre>error_code(int val, const error_category&amp; cat);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
 </p>
+</blockquote>
+</blockquote>
 
-<p>This is a real issue BTW, since the Boost implementation does adhere
-to the requirements of Table 16, while at least one commercial
-implementation does not and follows a strict adherence to sections
-5.1.4.5 and 5.1.4.6 instead.
+<p>
+Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated:
 </p>
 
-<p><i>[
-Jens adds:
-]</i></p>
+<blockquote>
+<pre>void assign(int val, const error_category&amp; cat);
+</pre>
+<blockquote>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+</blockquote>
 
+<p>
+Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers as indicated:
+</p>
 
 <blockquote>
-Both engines do have the necessary
-constructor, therefore the omission of the <tt>seed()</tt> member
-functions appears to be an oversight.
+const error_category&amp; category() const;
+<blockquote>
+<p>
+<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
 </blockquote>
 
+<p>
+Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated:
+</p>
 
+<blockquote><pre>private:
+  int val_;                    // exposition only
+  const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
+Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated:
 </p>
+<p><i>[
+(If the proposed resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> has already been applied, the
+name <tt>posix_category</tt> will have been changed to <tt>generic_category</tt>. That has
+no effect on this resolution.)
+]</i></p>
 
 
+<blockquote>
+<pre>error_condition();
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>posix_category</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+<pre>error_condition(int val, const error_category&amp; cat);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+</blockquote>
 
+<p>
+Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated:
+</p>
 
-
-<hr>
-<h3><a name="786"></a>786. Thread library timed waits, UTC and monotonic clocks</h3>
-<p><b>Section:</b> X [datetime.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Christopher Kohlhoff, Jeff Garland <b>Date:</b> 2008-02-03</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>
+<blockquote>
+void assign(int val, const error_category&amp; cat);
+<blockquote>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
+</p>
 <p>
-The draft C++0x thread library requires that the time points of type
-<tt>system_time</tt> and returned by <tt>get_system_time()</tt> represent Coordinated
-Universal Time (UTC) (section X [datetime.system]). This can lead to
-surprising behavior when a library user performs a duration-based wait,
-such as <tt>condition_variable::timed_wait()</tt>. A complete explanation of the
-problem may be found in the
-<a href="http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19">Rationale for the Monotonic Clock</a>
-section in POSIX, but in summary:
+<i>Throws:</i> Nothing.
 </p>
+</blockquote>
+</blockquote>
 
-<ul>
-<li>
-Operations such as <tt>condition_variable::timed_wait()</tt> (and its POSIX
-equivalent, <tt>pthread_cond_timedwait()</tt>) are specified using absolute times
-to address the problem of spurious wakeups.
-</li>
+<p>
+Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated:
+</p>
 
-<li>
-The typical use of the timed wait operations is to perform a relative
-wait. This may be achieved by first calculating an absolute time as the
-sum of the current time and the desired duration. In fact, the C++0x
-thread library includes duration-based overloads of
-<tt>condition_variable::timed_wait()</tt> that behave as if by calling the
-corresponding absolute time overload with a time point value of
-<tt>get_system_time() + rel_time</tt>.
-</li>
+<blockquote>
+const error_category&amp; category() const;
+<blockquote>
+<p>
+<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+</blockquote>
+</blockquote>
 
-<li>
-A UTC clock may be affected by changes to the system time, such as
-synchronization with an external source, leap seconds, or manual changes
-to the clock.
-</li>
+<p>
+Resolution of part C:
+</p>
 
-<li>
-Should the clock change during a timed wait operation, the actual
-duration of the wait will not be the expected length. For example, a
-user may intend a timed wait of one second duration but, due to an
-adjustment of the system clock backwards by a minute, the wait instead
-takes 61 seconds.
-</li>
-</ul>
+<blockquote>
 
 <p>
-POSIX solves the problem by introducing a new monotonic clock, which is
-unaffected by changes to the system time. When a condition variable is
-initialized, the user may specify whether the monotonic clock is to be
-used. (It is worth noting that on POSIX systems it is not possible to
-use <tt>condition_variable::native_handle()</tt> to access this facility, since
-the desired clock type must be specified during construction of the
-condition variable object.)
+In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
 </p>
 
+<blockquote>
+<pre>virtual string message(int ev) const = 0;
+</pre>
+
+<blockquote>
 <p>
-In the context of the C++0x thread library, there are added dimensions
-to the problem due to the need to support platforms other than POSIX:
+<i>Returns:</i> A string that describes the error condition denoted by <tt>ev</tt>.
 </p>
+<p>
+<del><i>Throws:</i> Nothing.</del>
+</p>
+</blockquote>
+</blockquote>
 
-<ul>
-<li>
-Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock.
-</li>
-
-<li>
-Some environments do not have a monotonic clock, but do have a UTC clock.
-</li>
+<p>
+In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8.
+</p>
 
-<li>
-The Microsoft Windows API's synchronization functions use relative
-timeouts based on an implied monotonic clock. A program that switches
-from the Windows API to the C++0x thread library will now find itself
-susceptible to clock changes.
-</li>
-</ul>
+<blockquote>
+<pre>string message() const;
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>category().message(value())</tt>.
+</p>
+<p>
+<del><i>Throws:</i> Nothing.</del>
+</p>
+</blockquote>
+</blockquote>
 
 <p>
-One possible minimal solution:
+In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.
 </p>
 
-<ul>
-<li>
-Strike normative references to UTC and an epoch based on 1970-01-01.
-</li>
+<blockquote>
+<pre>string message() const;
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>category().message(value())</tt>.
+</p>
+<p>
+<del><i>Throws:</i> Nothing.</del>
+</p>
+</blockquote>
+</blockquote>
 
-<li>
-Make the semantics of <tt>system_time</tt> and <tt>get_system_time()</tt>
-implementation-defined (i.e standard library implementors may choose the
-appropriate underlying clock based on the capabilities of the target
-platform).
-</li>
+</blockquote>
 
-<li>
-Add a non-normative note encouraging use of a monotonic clock.
-</li>
 
-<li>
-Remove <tt>system_time::seconds_since_epoch()</tt>.
-</li>
 
-<li>
-Change the constructor <tt>explicit system_time(time_t secs, nanoseconds ns
-= 0)</tt> to <tt>explicit system_time(nanoseconds ns)</tt>.
-</li>
-</ul>
 
 
 
-<p><b>Proposed resolution:</b></p>
+<hr>
+<h3><a name="805"></a>805. <tt>posix_error::posix_errno</tt> concerns</h3>
+<p><b>Section:</b> 19.4 [syserr] <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>Date:</b> 2008-02-24</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</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>
+19.4 [syserr]
 </p>
 
+<blockquote><pre>namespace posix_error {
+  enum posix_errno {
+    address_family_not_supported, // EAFNOSUPPORT
+    ...
+</pre></blockquote>
 
+<p>
+should rather use the new scoped-enum  facility (7.2 [dcl.enum]),
+which would avoid the necessity for a new <tt>posix_error</tt>
+namespace, if I understand correctly.
+</p>
 
+<p><i>[
+Further discussion:
+]</i></p>
 
 
-<hr>
-<h3><a name="787"></a>787. complexity of <tt>binary_search</tt></h3>
-<p><b>Section:</b> 25.3.3.4 [binary.search] <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>Date:</b> 2007-09-08</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>
+<blockquote>
 <p>
-In 25.3.3.4 [binary.search]/3 the complexity of <tt>binary_search</tt> is described as
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf">N2347</a>,
+Strongly Typed Enums, since renamed Scoped Enums.
 </p>
-
-<blockquote>
-At most <tt>log(last - first) + 2</tt> comparisons.
-</blockquote>
-
 <p>
-This should be precised and brought in line with the nomenclature used for
-<tt>lower_bound</tt>, <tt>upper_bound</tt>, and <tt>equal_range</tt>.
+Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution.
 </p>
-
 <p>
-All existing libraries I'm aware of, delegate to
-<tt>lower_bound</tt> (+ one further comparison). Since
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>
-has now WP status, the resolution of #787 should
-be brought in-line with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a> by changing the <tt>+ 2</tt>
-to <tt>+ O(1)</tt>.
+Nick Stoughton asked in Bellevue that <tt>posix_error</tt> and <tt>posix_errno</tt> not be used as names. The LWG agreed.
+</p>
+<p>
+The wording for the Proposed resolution was provided by Beman Dawes.
 </p>
+</blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change 25.3.3.4 [binary.search]/3
+Change System error support 19.4 [syserr] as indicated:
 </p>
 
-<blockquote>
-<i>Complexity:</i> At most <tt>log<ins><sub>2</sub></ins>(last - first) + <del>2</del> <ins><i>O</i>(1)</ins></tt> comparisons.
-</blockquote>
+<blockquote><pre><del>namespace posix_error {</del>
+  enum <del>posix_errno</del> <ins>class errc</ins> {
+    address_family_not_supported, // EAFNOSUPPORT
+    ...
+    wrong_protocol_type, // EPROTOTYPE
+  };
+<del>} // namespace posix_error</del>
 
+template &lt;&gt; struct is_error_condition_enum&lt;<del>posix_error::posix_errno</del> <ins>errc</ins>&gt;
+  : public true_type {}
 
+<del>namespace posix_error {</del>
+  error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
+  error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
+<del>} // namespace posix_error</del>
+</pre></blockquote>
 
+<p>
+Change System error support 19.4 [syserr] :
+</p>
 
+<blockquote>
+<del>The <tt>is_error_code_enum</tt> and <tt>is_error_condition_enum</tt> templates may be
+specialized for user-defined types to indicate that such a type is
+eligible for class <tt>error_code</tt> and class <tt>error_condition</tt> automatic
+conversions, respectively.</del>
+</blockquote>
 
-<hr>
-<h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3>
-<p><b>Section:</b> 24.5.1 [istream.iterator] <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>Date:</b> 2008-02-06</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#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <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>:
+Change System error support 19.4 [syserr] and its subsections:
 </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.
+<ul>
+<li>
+remove all occurrences of <tt>posix_error::</tt>
+</li>
+<li>
+change all instances of <tt>posix_errno</tt> to <tt>errc</tt>
+</li>
+<li>
+change all instances of <tt>posix_category</tt> to <tt>generic_category</tt>
+</li>
+<li>
+change all instances of <tt>get_posix_category</tt> to <tt>get_generic_category</tt>
+</li>
+</ul>
 </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).
+Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2:
 </p>
 
+<blockquote>
+<i>Remarks:</i> The object's <tt>default_error_condition</tt> and equivalent virtual
+functions shall behave as specified for the class <tt>error_category</tt>. The
+object's name virtual function shall return a pointer to the string
+<del>"POSIX"</del> <ins>"GENERIC"</ins>.
+</blockquote>
+
 <p>
-Also I would prefer to be explicit about calling <tt>fail()</tt> here
-(there is no <tt>operator void*()</tt> anymore.)
+Change 19.4.2.5 [syserr.errcode.nonmembers] Class <tt>error_code</tt> non-member functions as indicated:
 </p>
 
+<blockquote>
+<pre>error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
+</pre>
+
+<blockquote>
+<i>Returns:</i> <tt>error_code(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
+</blockquote>
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 24.5.1 [istream.iterator]/1:
+Change 19.4.3.5 [syserr.errcondition.nonmembers] Class <tt>error_condition</tt> non-member functions as indicated:
 </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.
+<pre>error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
+</pre>
+
+<blockquote>
+<i>Returns:</i> <tt>error_condition(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
+</blockquote>
 </blockquote>
 
 
 
+<p><b>Rationale:</b></p>
+<table border="1">
+<tbody><tr>
+<th colspan="2">Names Considered</th>
+</tr>
 
+<tr>
+<td><tt>portable</tt></td>
+<td>
+Too non-specific. Did not wish to reserve such a common word in
+namespace std. Not quite the right meaning, either.
+</td>
+</tr>
 
-<hr>
-<h3><a name="789"></a>789. <tt>xor_combine_engine(result_type)</tt> should be explicit</h3>
-<p><b>Section:</b> 26.4.4.4 [rand.adapt.xor] <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>Date:</b> 2008-02-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.adapt.xor">issues</a> in [rand.adapt.xor].</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>xor_combine_engine(result_type)</tt> should be <tt>explicit</tt>. (Obvious oversight.)
-</p>
+<tr>
+<td><tt>portable_error</tt></td>
+<td>
+Too long. Explicit qualification is always required for scoped enums, so
+a short name is desirable. Not quite the right meaning, either. May be
+misleading because <tt>*_error</tt> in the std lib is usually an exception class
+name.
+</td>
+</tr>
 
-<p><i>[
-Bellevue:
-]</i></p>
+<tr>
+<td><tt>std_error</tt></td>
+<td>
+Fairly short, yet explicit. But in fully qualified names like
+<tt>std::std_error::not_enough_memory</tt>, the std_ would be unfortunate. Not
+quite the right meaning, either. May be misleading because <tt>*_error</tt> in
+the std lib is usually an exception class name.
+</td>
+</tr>
 
+<tr>
+<td><tt>generic</tt></td>
+<td>
+Short enough. The category could be <tt>generic_category</tt>. Fully qualified
+names like <tt>std::generic::not_enough_memory</tt> read well. Reserving in
+namespace std seems dicey.
+</td>
+</tr>
 
-<blockquote>
-Non-controversial. Bill is right, but Fermilab believes that this is
-easy to use badly and hard to use right, and so it should be removed
-entirely. Got into TR1 by well defined route, do we have permission to
-remove stuff? Should probably check with Jens, as it is believed he is
-the originator. Broad consensus that this is not a robust engine
-adapter.
-</blockquote>
+<tr>
+<td><tt>generic_error</tt></td>
+<td>
+Longish. The category could be <tt>generic_category</tt>. Fully qualified names
+like <tt>std::generic_error::not_enough_memory</tt> read well. Misleading because
+<tt>*_error</tt> in the std lib is usually an exception class name.
+</td>
+</tr>
 
+<tr>
+<td><tt>generic_err</tt></td>
+<td>
+A bit less longish. The category could be <tt>generic_category</tt>. Fully
+qualified names like <tt>std::generic_err::not_enough_memory</tt> read well.
+</td>
+</tr>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis].
-</p>
-<p>
-Remove 26.4.4.4 [rand.adapt.xor] <tt>xor_combine_engine</tt>.
-</p>
+<tr>
+<td><tt>gen_err</tt></td>
+<td>
+Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
+names like <tt>std::gen_err::not_enough_memory</tt> read well.
+</td>
+</tr>
+
+<tr>
+<td><tt>generr</tt></td>
+<td>
+Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
+names like <tt>std::generr::not_enough_memory</tt> read well.
+</td>
+</tr>
+
+<tr>
+<td><tt>error</tt></td>
+<td>
+Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
+names like <tt>std::error::not_enough_memory</tt> read well. Do we want to use
+this general a name?
+</td>
+</tr>
+
+<tr>
+<td><tt>err</tt></td>
+<td>
+Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
+names like <tt>std::err::not_enough_memory</tt> read well. Although alone it
+looks odd as a name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names,
+it seems fairly intuitive.
+Problem: <tt>err</tt> is used throughout the standard library as an argument name
+and in examples as a variable name; it seems too confusing to add yet
+another use of the name.
+</td>
+</tr>
+
+<tr>
+<td><tt>errc</tt></td>
+<td>
+Short enough. The "c" stands for "constant". The category could be
+<tt>generic_category</tt>. Fully qualified names like
+<tt>std::errc::not_enough_memory</tt> read well. Although alone it looks odd as a
+name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names, it seems fairly
+intuitive. There are no uses of <tt>errc</tt> in the current C++ standard.
+</td>
+</tr>
+</tbody></table>
 
 
 
 
 
 <hr>
-<h3><a name="792"></a>792. <tt>piecewise_constant_distribution</tt> is undefined for a range with just one endpoint</h3>
-<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <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>Date:</b> 2008-02-09</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
+<h3><a name="806"></a>806. <tt>unique_ptr::reset</tt> effects incorrect, too permissive</h3>
+<p><b>Section:</b> 20.7.11.2.5 [unique.ptr.single.modifiers] <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>Date:</b> 2008-03-13</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>piecewise_constant_distribution</tt> is undefined for a range with just one
-endpoint. (Probably should be the same as an empty range.)
+<tt>void unique_ptr::reset(T* p = 0)</tt> is currently specified as:
 </p>
 
+<blockquote>
+<i>Effects:</i> If <tt>p == get()</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
+There are two problems with this. One, if <tt>get() == 0</tt> and <tt>p != 0</tt>, the
+deleter is called with a NULL pointer, and this is probably not what's
+intended (the destructor avoids calling the deleter with 0.)
 </p>
 
-<blockquote>
-b) If <tt>firstB == lastB</tt> <ins>or the sequence <tt>w</tt> has the length zero</ins>,
-</blockquote>
+<p>
+Two, the special check for <tt>get() == p</tt> is generally not needed and such a
+situation usually indicates an error in the client code, which is being
+masked. As a data point, <tt>boost::shared_ptr</tt> was changed to assert on such
+self-resets in 2001 and there were no complaints.
+</p>
 
+<p>
+One might think that self-resets are necessary for operator= to work; it's specified to perform
+</p>
 
+<blockquote><pre>reset( u.release() );
+</pre></blockquote>
 
+<p>
+and the self-assignment
+</p>
 
+<blockquote><pre>p = move(p);
+</pre></blockquote>
 
-<hr>
-<h3><a name="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3>
-<p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</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>discrete_distribution</tt> should have a constructor like:
+might appear to result in a self-reset. But it doesn't; the <tt>release()</tt> is
+performed first, zeroing the stored pointer. In other words, <tt>p.reset(
+q.release() )</tt> works even when <tt>p</tt> and <tt>q</tt> are the same <tt>unique_ptr</tt>, and there
+is no need to special-case <tt>p.reset( q.get() )</tt> to work in a similar
+scenario, as it definitely doesn't when <tt>p</tt> and <tt>q</tt> are separate.
 </p>
 
-<blockquote><pre>template&lt;class _Fn&gt;
-  discrete_distribution(result_type _Count, double _Low, double _High,
-                        _Fn&amp; _Func);
-</pre></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
 
 <p>
-(Makes it easier to fill a histogram with function vaues over a range.)
+Change 20.7.11.2.5 [unique.ptr.single.modifiers]:
 </p>
 
-<p><i>[
-Bellevue:
-]</i></p>
+<blockquote>
+<pre>void reset(T* p = 0);
+</pre>
+<blockquote>
+-4- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
+</blockquote>
+</blockquote>
 
+<p>
+Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]:
+</p>
 
 <blockquote>
-How do you specify the function so that it does not return negative
-values? If you do it is a bad construction. This requirement is already
-there. Where in each bin does one evaluate the function? In the middle.
-Need to revisit tomorrow.
+<pre>void reset(T* p = 0);
+</pre>
+<blockquote>
+<p>...</p>
+<p>
+-2- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
+</p>
+</blockquote>
 </blockquote>
 
 
-<p><b>Proposed resolution:</b></p>
-
 
 
 
 
 <hr>
-<h3><a name="794"></a>794. <tt>piecewise_constant_distribution</tt> missing constructor</h3>
-<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</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="807"></a>807. <tt>tuple</tt> construction should not fail unless its element's construction fails</h3>
+<p><b>Section:</b> 20.4.1.2 [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> Howard Hinnant <b>Date:</b> 2008-03-13</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>piecewise_constant_distribution</tt> should have a constructor like:
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> Added a throws clause to <tt>bind</tt> constructors.  I believe the same throws clause
+should be added to <tt>tuple</tt> except it ought to take into account move constructors as well.
 </p>
 
-<blockquote><pre>template&lt;class _Fn&gt;
-   piecewise_constant_distribution(size_t _Count,
-            _Ty _Low, _Ty _High, _Fn&amp; _Func);
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-(Makes it easier to fill a histogram with function vaues over a range.
-The two (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>) make a sensible replacement for
-<tt>general_pdf_distribution</tt>.)
+Add to 20.4.1.2 [tuple.cnstr]:
 </p>
 
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
+<p>
+For each <tt>tuple</tt> constructor and assignment operator, an exception is thrown only if the construction
+or assignment of one of the types in <tt>Types</tt> throws an exception.
+</p>
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="798"></a>798. Refactoring of binders lead to interface breakage</h3>
-<p><b>Section:</b> D.8 [depr.lib.binders] <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>Date:</b> 2008-02-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
+<h3><a name="808"></a>808. [forward] incorrect redundant specification</h3>
+<p><b>Section:</b> 20.2.2 [forward] <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>Date:</b> 2008-03-13</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>
 <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>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2521.pdf">N2521</a>
-and its earlier predecessors have moved the old binders from
-[lib.binders] to D.8 [depr.lib.binders] thereby introducing some renaming
-of the template parameter names (<tt>Operation -&gt; Fn</tt>). During this
-renaming process the <em>protected</em> data member <tt>op</tt> was also renamed to
-<tt>fn</tt>, which seems as an unnecessary interface breakage to me - even if
-this user access point is probably rarely used.
+p4 (forward) says:
+</p>
+<blockquote>
+<i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.
+</blockquote>
+
+<p>
+First of all, lvalue-ness and rvalue-ness are properties of an expression,
+not of a type (see 3.10 [basic.lval]).  Thus, the phrasing "Return type" is wrong.
+Second, the phrase says exactly what the core language wording says for
+folding references in 14.3.1 [temp.arg.type]/p4  and for function return values
+in 5.2.2 [expr.call]/p10.  (If we feel the wording should be retained, it should
+at most be a note with cross-references to those sections.)
+</p>
+<p>
+The prose after the example talks about "forwarding as an <tt>int&amp;</tt> (an lvalue)" etc.
+In my opinion, this is a category error:  "<tt>int&amp;</tt>" is a type, "lvalue" is a
+property of an expression, orthogonal to its type.  (Btw, expressions cannot
+have reference type, ever.)
+</p>
+<p>
+Similar with move:
+</p>
+<blockquote>
+Return type: an rvalue.
+</blockquote>
+<p>
+is just wrong and also redundant.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change D.8.1 [depr.lib.binder.1st]:
+Change 20.2.2 [forward] as indicated:
 </p>
 
 <blockquote>
-<pre>template &lt;class Fn&gt; 
-class binder1st 
-  : public unary_function&lt;typename Fn::second_argument_type, 
-                          typename Fn::result_type&gt; { 
-protected: 
-  Fn <del>fn</del> <ins>op</ins>; 
-  typename Fn::first_argument_type value; 
-public: 
-  binder1st(const Fn&amp; x, 
-            const typename Fn::first_argument_type&amp; y); 
-  typename Fn::result_type 
-    operator()(const typename Fn::second_argument_type&amp; x) const; 
-  typename Fn::result_type 
-    operator()(typename Fn::second_argument_type&amp; x) const; 
-};
+<pre>template &lt;class T&gt; T&amp;&amp; forward(typename identity&lt;T&gt;::type&amp;&amp; t);
 </pre>
 
 <blockquote>
+<p>...</p>
 <p>
--1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
+<del><i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.</del>
 </p>
+<p>...</p>
 <p>
--2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
+-7- In the first call to <tt>factory</tt>, <tt>A1</tt> is deduced as <tt>int</tt>, so 2 is forwarded to <tt>A</tt>'s constructor
+as <del>an <tt>int&amp;&amp;</tt> (</del>an rvalue<del>)</del>. In the second call to factory, <tt>A1</tt> is deduced
+as <tt>int&amp;</tt>, so <tt>i</tt> is forwarded to <tt>A</tt>'s constructor as <del>an <tt>int&amp;</tt> (</del>an lvalue<del>)</del>.
+In both cases, <tt>A2</tt> is deduced as double, so 1.414 is forwarded to <tt>A</tt>'s constructor as
+<del><tt>double&amp;&amp;</tt> (</del>an rvalue<del>)</del>.
 </p>
 </blockquote>
-</blockquote>
-
-<p>
-Change D.8.3 [depr.lib.binder.2nd]:
-</p>
 
-<blockquote>
-<pre>template &lt;class Fn&gt; 
-class binder2nd
-  : public unary_function&lt;typename Fn::first_argument_type, 
-                          typename Fn::result_type&gt; { 
-protected: 
-  Fn <del>fn</del> <ins>op</ins>; 
-  typename Fn::second_argument_type value; 
-public: 
-  binder2nd(const Fn&amp; x, 
-            const typename Fn::second_argument_type&amp; y); 
-  typename Fn::result_type 
-    operator()(const typename Fn::first_argument_type&amp; x) const; 
-  typename Fn::result_type 
-    operator()(typename Fn::first_argument_type&amp; x) const; 
-};
+<pre>template &lt;class T&gt; typename remove_reference&lt;T&gt;::type&amp;&amp; move(T&amp;&amp; t);
 </pre>
 
 <blockquote>
+<p>...</p>
 <p>
--1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
-</p>
-<p>
--2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
+<del><i>Return type:</i>  an rvalue.</del>
 </p>
 </blockquote>
+
 </blockquote>
 
 
@@ -15812,80 +13976,91 @@ public:
 
 
 <hr>
-<h3><a name="800"></a>800. Issues in 26.4.7.1 [rand.util.seedseq](6)</h3>
-<p><b>Section:</b> 26.4.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> Stephan Tolksdorf <b>Date:</b> 2008-02-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</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="809"></a>809. std::swap should be overloaded for array types</h3>
+<p><b>Section:</b> 25.2.3 [alg.swap] <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>Date:</b> 2008-02-28</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</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 for-loop in the algorithm specification has <tt>n</tt> iterations, where <tt>n</tt> is
-defined to be <tt>end - begin</tt>, i.e. the number of supplied w-bit quantities.
-Previous versions of this algorithm and the general logic behind it
-suggest that this is an oversight and that in the context of the
-for-loop <tt>n</tt> should be the number of full 32-bit quantities in <tt>b</tt> (rounded
-upwards). If <tt>w</tt> is 64, the current algorithm throws away half of all bits
-in <tt>b</tt>. If <tt>w</tt> is 16, the current algorithm sets half of all elements in <tt>v</tt>
-to 0.
-</p>
-
-<p>
-There are two more minor issues:
-</p>
-
-<ul>
-<li>
-Strictly speaking <tt>end - begin</tt> is not defined since
-<tt>InputIterator</tt> is not required to be a random access iterator.
-</li>
-<li>
-Currently all integral types are allowed as input to the <tt>seed_seq</tt>
-constructor, including <tt>bool</tt>. IMHO allowing <tt>bool</tt>s unnecessarily
-complicates the implementation without any real benefit to the user.
-I'd suggest to exclude <tt>bool</tt>s as input.
-</li>
-</ul>
-
-<p><i>[
-Bellevue:
-]</i></p>
+For the sake of generic programming, the header <code>&lt;algorithm&gt;</code> should provide an
+overload of <code>std::swap</code> for array types:
+</p><pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
+</pre>
 
 
-<blockquote>
-Move to OPEN Bill will try to propose a resolution by the next meeting.
-</blockquote>
+<p>
+It became apparent to me that this overload is missing, when I considered how to write a swap
+function for a generic wrapper class template.
+(Actually I was thinking of Boost's <a href="http://www.boost.org/libs/utility/value_init.htm">value_initialized</a>.)
+Please look at the following template, <code>W</code>, and suppose that is intended to be a very
+<em>generic</em> wrapper:
+</p><pre>template&lt;class T&gt; class W {
+public:
+   T data;
+};
+</pre>
+Clearly <code>W&lt;T&gt;</code> is <em>CopyConstructible and CopyAssignable</em>, and therefore
+<em>Swappable</em>, whenever <code>T</code> is <em>CopyConstructible and CopyAssignable</em>.
+Moreover, <code>W&lt;T&gt;</code> is <em>also</em> Swappable when <code>T</code> is an array type
+whose element type is CopyConstructible and CopyAssignable.
+Still it is recommended to add a <em>custom</em> swap function template to such a class template,
+for the sake of efficiency and exception safety.
+(E.g., <em>Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing
+swap</em>.)
+This function template is typically written as follows:
+<pre>template&lt;class T&gt; void swap(W&lt;T&gt;&amp; x, W&lt;T&gt;&amp; y) {
+  using std::swap;
+  swap(x.data, y.data);
+}
+</pre>
+Unfortunately, this will introduce an undesirable inconsistency, when <code>T</code> is an array.
+For instance, <code>W&lt;std::string[8]&gt;</code> is Swappable, but the current Standard does not
+allow calling the custom swap function that was especially written for <code>W</code>!
+<pre>W&lt;std::string[8]&gt; w1, w2;  // Two objects of a Swappable type.
+std::swap(w1, w2);  // Well-defined, but inefficient.
+using std::swap;
+swap(w1, w2);  // Ill-formed, just because ADL finds W's swap function!!!
+</pre>
 
-<p><i>[
-post Bellevue:  Bill provided wording.
-]</i></p>
+<code>W</code>'s <code>swap</code> function would try to call <code>std::swap</code> for an array,
+<code>std::string[8]</code>, which is not supported by the Standard Library.
+This issue is easily solved by providing an overload of <code>std::swap</code> for array types.
+This swap function should be implemented in terms of swapping the elements of the arrays, so that
+it would be non-throwing for arrays whose element types have a non-throwing swap.
 
 
 <p>
-This issue is made moot if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> is accepted.
+Note that such an overload of <code>std::swap</code> should also support <em>multi-dimensional</em>
+arrays. Fortunately that isn't really an issue, because it would do so <i>automatically</i>, by
+means of recursion.
 </p>
 
+<p>
+For your information, there was a discussion on this issue at comp.lang.c++.moderated: <a href="http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/9341ebd3635c9c74">[Standard
+Library] Shouldn't std::swap be overloaded for C-style arrays?</a>
+</p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with:
+Add an extra condition to the definition of Swappable requirements [swappable] in 20.1.1 [utility.arg.requirements]:
 </p>
-
 <blockquote>
+- <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose element type is <tt>Swappable</tt>.
+</blockquote>
 <p>
-<i>Effects:</i> Constructs a <tt>seed_seq</tt> object by effectively concatenating the
-low-order <tt>u</tt> bits of each of the elements of the supplied sequence <tt>[begin,
-end)</tt>
-in ascending order of significance to make a (possibly very large) unsigned
-binary number <tt>b</tt> having a total of <tt>n</tt> bits, and then carrying out the
-following
-algorithm:
+Add the following to 25.2.3 [alg.swap]:
 </p>
-
-<blockquote><pre>for( v.clear(); n &gt; 0; n -= 32 )
-   v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
-</pre></blockquote>
+<blockquote>
+<pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
+</pre>
+<blockquote>
+<i>Requires:</i> Type <code>T</code> shall be <tt>Swappable</tt>.
+</blockquote>
+<blockquote>
+<i>Effects:</i> <code>swap_ranges(a, a + N, b);</code>
+</blockquote>
 </blockquote>
 
 
@@ -15893,102 +14068,154 @@ algorithm:
 
 
 <hr>
-<h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
-<p><b>Section:</b> 20.3 [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>Date:</b> 2008-02-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</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>
+<h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3>
+<p><b>Section:</b> 27.6.4 [ext.manip] <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>Date:</b> 2008-03-01</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</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>
-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.
+The recent draft (as well as the original proposal n2072) uses an
+operational semantic
+for <tt>get_money</tt> ([ext.manip]/3) and <tt>put_money</tt> ([ext.manip]/5), which uses
 </p>
+
+<blockquote><pre>istreambuf_iterator&lt;charT&gt;
+</pre></blockquote>
+
 <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.
+and
 </p>
+
+<blockquote><pre>ostreambuf_iterator&lt;charT&gt;
+</pre></blockquote>
+
 <p>
-There are at least two cases where specification of an explicitly
-defaulted function may be desirable.
+resp, instead of the iterator instances, with explicitly provided
+traits argument (The operational semantic defined by <tt>f</tt> is also traits
+dependent). This is an obvious oversight because both <tt>*stream_buf</tt>
+c'tors expect a <tt>basic_streambuf&lt;charT,traits&gt;</tt> as argument.
 </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
+The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic (p.
+7 and p. 9)
+of n2071 incorporated in N2521, where additional to the problem we
+have an editorial issue in <tt>get_time</tt> (<tt>streambuf_iterator</tt> instead of
+<tt>istreambuf_iterator</tt>).
 </p>
 
-<blockquote><pre>pair() = default;
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <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.
+In 27.6.4 [ext.manip]/3 within function <tt>f</tt> replace the first line
 </p>
 
+<blockquote><pre>template &lt;class charT, class traits, class moneyT&gt; 
+void f(basic_ios&lt;charT, traits&gt;&amp; str, moneyT&amp; mon, bool intl) { 
+   typedef istreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
+   ...
+</pre></blockquote>
+
 <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?
+In 27.6.4 [ext.manip]/4 remove the first template <tt>charT</tt> parameter:
 </p>
+
+<blockquote><pre>template &lt;<del>class charT, </del>class moneyT&gt; unspecified put_money(const moneyT&amp; mon, bool intl = false<ins>)</ins>;
+</pre></blockquote>
+
 <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:
+In 27.6.4 [ext.manip]/5 within function <tt>f</tt> replace the first line
 </p>
 
-<blockquote><pre>tuple() = default;
-tuple(const tuple&amp;) = default;
+<blockquote><pre>template &lt;class charT, class traits, class moneyT&gt; 
+void f(basic_ios&lt;charT, traits&gt;&amp; str, const moneyT&amp; mon, bool intl) { 
+  typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
+  ...
 </pre></blockquote>
 
 <p>
-This changes is not implementation neutral.  In particular, it
-prevents implementations based on pointers to the parameter
-types.  It does however, permit implementations using the
-parameter types as bases.
+In 27.6.4 [ext.manip]/7 within function <tt>f</tt> replace the first line
 </p>
+
+<blockquote><pre>template &lt;class charT, class traits&gt; 
+void f(basic_ios&lt;charT, traits&gt;&amp; str, struct tm *tmb, const charT *fmt) { 
+  typedef <ins>i</ins>streambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
+  ...
+</pre></blockquote>
+
 <p>
-** How does the committee wish to trade implementation
-efficiency versus implementation flexibility?
+In 27.6.4 [ext.manip]/8 add const:
 </p>
 
-<p><i>[
-Bellevue:
-]</i></p>
-
+<blockquote><pre>template &lt;class charT&gt; unspecified put_time(<ins>const</ins> struct tm *tmb, const charT *fmt);
+</pre></blockquote>
 
-<blockquote>
 <p>
-General agreement; the first half of the issue is NAD.
+In 27.6.4 [ext.manip]/9 within function <tt>f</tt> replace the first line
 </p>
+
+<blockquote><pre>template &lt;class charT, class traits&gt; 
+void f(basic_ios&lt;charT, traits&gt;&amp; str, const struct tm *tmb, const charT *fmt) { 
+  typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
+  ...
+</pre></blockquote>
+
 <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.
+Add to the <tt>&lt;iomanip&gt;</tt> synopsis in 27.6 [iostream.format]
 </p>
+
+<blockquote><pre>template &lt;class moneyT&gt; unspecified get_money(moneyT&amp; mon, bool intl = false);
+template &lt;class moneyT&gt; unspecified put_money(const moneyT&amp; mon, bool intl = false);
+template &lt;class charT&gt; unspecified get_time(struct tm *tmb, const charT *fmt);
+template &lt;class charT&gt; unspecified put_time(const struct tm *tmb, const charT *fmt);
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3>
+<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-03-14</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#New">New</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>
-Concensus: Go forward, but not at expense of other desired qualities.
+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>template&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; y);
+</pre></blockquote>
+
 <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.
+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>
+
+<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><b>Proposed resolution:</b></p>
@@ -16000,217 +14227,184 @@ tabled until Alisdair's proposals are disposed of.
 
 
 <hr>
-<h3><a name="803"></a>803. Simplification of <tt>seed_seq::seq_seq</tt></h3>
-<p><b>Section:</b> 26.4.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> Charles Karney <b>Date:</b> 2008-02-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</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="812"></a>812. unsolicited multithreading considered harmful?</h3>
+<p><b>Section:</b> 25.3.1 [alg.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Paul McKenney <b>Date:</b> 2008-02-27</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>seed_seq(InputIterator begin, InputIterator end);</tt> constructs a <tt>seed_seq</tt>
-object repacking the bits of supplied sequence <tt>[begin, end)</tt> into a
-32-bit vector.
+Multi-threading is a good thing, but unsolicited multi-threading can
+potentially be harmful.  For example, <tt>sort()</tt> performance might be
+greatly increased via a multithreaded implementation.  However, such
+a multithreaded implementation could result in concurrent invocations
+of the user-supplied comparator.  This would in turn result in problems
+given a caching comparator that might be written for complex sort keys.
+Please note that this is not a theoretical issue, as multithreaded
+implementations of <tt>sort()</tt> already exist.
 </p>
 <p>
-This repacking triggers several problems:
+Having a multithreaded <tt>sort()</tt> available is good, but it should not
+be the default for programs that are not explicitly multithreaded.
+Users should not be forced to deal with concurrency unless they have
+asked for it.
 </p>
-<ol>
-<li>
-Distinctness of the output of <tt>seed_seq::generate</tt> required the
-introduction of the initial "<tt>if (w &lt; 32) v.push_back(n);</tt>"  (Otherwise
-the unsigned short vectors [1, 0] and [1] generate the same sequence.)
-</li>
-<li>
-Portability demanded the introduction of the template parameter <tt>u</tt>.
-(Otherwise some sequences could not be obtained on computers where no
-integer types are exactly 32-bits wide.)
-</li>
-<li>
-The description and algorithm have become unduly complicated.
-</li>
-</ol>
+
+<p><i>[
+This may be covered by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2410.html">N2410</a>
+Thread-Safety in the Standard Library (Rev 1).
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-I propose simplifying this <tt>seed_seq</tt> constructor to be "32-bit only".
-Despite it's being simpler, there is NO loss of functionality (see
-below).
 </p>
+
+
+
+
+
+<hr>
+<h3><a name="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3>
+<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Matt Austern <b>Date:</b> 2008-02-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#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Here's how the description would read
+Several places in 20.7.12.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>.
+However, that term is nowhere defined. The closest thing we have to a
+definition is that the default constructor creates an empty <tt>shared_ptr</tt>
+and that a copy of a default-constructed <tt>shared_ptr</tt> is empty. Are any
+other <tt>shared_ptr</tt>s empty? For example, is <tt>shared_ptr((T*) 0)</tt> empty? What
+are the properties of an empty <tt>shared_ptr</tt>? We should either clarify this
+term or stop using it.
+</p><p>
 </p>
+One reason it's not good enough to leave this term up to the reader's
+intuition is that, in light of
+<a href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2007/n2351.htm">N2351</a>
+and issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, most readers'
+intuitive understanding is likely to be wrong. Intuitively one might
+expect that an empty <tt>shared_ptr</tt> is one that doesn't store a pointer,
+but, whatever the definition is, that isn't it.
+
+
+<p><i>[
+Peter adds:
+]</i></p>
+
+
 <blockquote>
 <p>
-26.4.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt>
+Or, what is an "empty" <tt>shared_ptr</tt>?
 </p>
 
-<blockquote>
-<pre>template&lt;class InputIterator&gt;
-  seed_seq(InputIterator begin, InputIterator end);
-</pre>
-<blockquote>
+<ul>
+<li>
 <p>
-5 <i>Requires:</i> NO CHANGE
+Are any other <tt>shared_ptrs</tt> empty?
 </p>
 <p>
-6 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by
+Yes. Whether a given <tt>shared_ptr</tt> instance is empty or not is (*)
+completely specified by the last mutating operation on that instance.
+Give me an example and I'll tell you whether the <tt>shared_ptr</tt> is empty or
+not.
 </p>
 <blockquote>
-<pre>for (InputIterator s = begin; s != end; ++s)
-   v.push_back((*s) mod 2^32);
-</pre>
-</blockquote>
-</blockquote>
-</blockquote>
+(*) If it isn't, this is a legitimate defect.
 </blockquote>
+</li>
 
+<li>
 <p>
-Discussion:
+For example, is <tt>shared_ptr((T*) 0)</tt> empty?
 </p>
 <p>
-The chief virtues here are simplicity, portability, and generality.
+No. If it were empty, it would have a <tt>use_count()</tt> of 0, whereas it is
+specified to have an <tt>use_count()</tt> of 1.
 </p>
-<ul>
-<li>
-Simplicity -- compare the above specification with the
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> proposal.
-</li>
-<li>
-Portability -- with <tt>iterator_traits&lt;InputIterator&gt;::value_type =
-uint_least32_t</tt> the user is guaranteed to get the same behavior across
-platforms.
 </li>
+
 <li>
-Generality -- any behavior that the
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
-proposal can achieve can be
-obtained with this simpler proposal (albeit with a shuffling of bits
-in the input sequence).
-</li>
-</ul>
 <p>
-Arguments (and counter-arguments) against making this change (and
-retaining the
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
-behavior) are:
+What are the properties of an empty <tt>shared_ptr</tt>?
 </p>
-<ul>
+<p>
+The properties of an empty <tt>shared_ptr</tt> can be derived from the
+specification. One example is that its destructor is a no-op. Another is
+that its <tt>use_count()</tt> returns 0. I can enumerate the full list if you
+really like.
+</p>
+</li>
+
 <li>
 <p>
-The user can pass an array of <tt>unsigned char</tt> and <tt>seed_seq</tt> will nicely
- repack it.
+We should either clarify this term or stop using it.
 </p>
 <p>
- Response: So what?  Consider the seed string "ABC".  The
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
- proposal results in
+I don't agree with the imperative tone
 </p>
-<blockquote><pre>v = { 0x3, 0x434241 };
-</pre></blockquote>
 <p>
-while the simplified proposal yields
+A clarification would be either a no-op - if it doesn't contradict the
+existing wording - or a big mistake if it does.
 </p>
-<blockquote><pre>v = { 0x41, 0x42, 0x43 };
-</pre></blockquote>
 <p>
-The results produced by <tt>seed_seq::generate</tt> with the two inputs are
-different but nevertheless equivalently "mixed up" and this remains
-true even if the seed string is long.
+I agree that a clarification that is formally a no-op may add value.
 </p>
 </li>
+
 <li>
 <p>
-With long strings (e.g., with bit-length comparable to the number of
- bits in the state), <tt>v</tt> is longer (by a factor of 4) with the simplified
- proposal and <tt>seed_seq::generate</tt> will be slower.
+However, that term is nowhere defined.
 </p>
 <p>
-Response: It's unlikely that the efficiency of <tt>seed_seq::generate</tt> will
- be a big issue.  If it is, the user is free to repack the seed vector
- before constructing <tt>seed_seq</tt>.
+Terms can be useful without a definition. Consider the following
+simplistic example. We have a type <tt>X</tt> with the following operations
+defined:
 </p>
-</li>
-<li>
+<blockquote><pre>X x;
+X x2(x);
+X f(X x);
+X g(X x1, X x2);
+</pre></blockquote>
 <p>
-A user can pass an array of 64-bit integers and all the bits will be
- used.
+A default-constructed value is green.<br>
+A copy has the same color as the original.<br>
+<tt>f(x)</tt> returns a red value if the argument is green, a green value otherwise.<br>
+<tt>g(x1,x2)</tt> returns a green value if the arguments are of the same color, a red value otherwise.
 </p>
+
 <p>
- Response: Indeed.  However, there are many instances in the 
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
- where integers are silently coerced to a narrower width and this
- should just be a case of the user needing to read the documentation.
- The user can of course get equivalent behavior by repacking his seed
- into 32-bit pieces.  Furthermore, the unportability of the 
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
- proposal with
+Given these definitions, you can determine the color of every instance
+of type <tt>X</tt>, even if you have absolutely no idea what green and red mean.
 </p>
-<blockquote><pre>unsigned long s[] = {1, 2, 3, 4};
-seed_seq q(s, s+4);
-</pre></blockquote>
+
 <p>
- which typically results in <tt>v = {1, 2, 3, 4}</tt> on 32-bit machines and in
-<tt>v = {1, 0, 2, 0, 3, 0, 4, 0}</tt> on 64-bit machines is a major pitfall for
- unsuspecting users.
+Green and red are "nowhere defined" and completely defined at the same time.
 </p>
 </li>
 </ul>
 
 <p>
-Note: this proposal renders moot issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>.
+Alisdair's wording is fine.
 </p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
 </blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change 26.4.7.1 [rand.util.seedseq]:
-</p>
-
-<blockquote>
-<pre>template&lt;class InputIterator<del>, 
-  size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
-  seed_seq(InputIterator begin, InputIterator end);
-</pre>
-<blockquote>
-<p>
--5- <i>Requires:</i> <tt>InputIterator</tt> shall satisfy the requirements of an input iterator (24.1.1)
-such that <tt>iterator_traits&lt;InputIterator&gt;::value_type</tt> shall denote an integral type.
-</p>
-<p>
--6- Constructs a <tt>seed_seq</tt> object by <del>rearranging some or all of the bits of the supplied sequence
-<tt>[begin,end)</tt> of w-bit quantities into 32-bit units, as if by the following: </del>
-</p>
-<p>
-<del>First extract the rightmost <tt>u</tt> bits from each of the <tt>n = end
-- begin</tt> elements of the supplied sequence and concatenate all the
-extracted bits to initialize a single (possibly very large) unsigned
-binary number, <tt>b = &#8721;<sup>n-1</sup><sub>i=0</sub> (begin[i] 
-mod 2<sup>u</sup>) · 2<sup>w·i</sup></tt> (in which the bits of each <tt>begin[i]</tt>
-are treated as denoting an unsigned quantity). Then carry out 
-the following algorithm:</del>
+Append the following sentance to 20.7.12.2 [util.smartptr.shared]
 </p>
-<blockquote><pre><del>
-v.clear(); 
-if ($w$ &lt; 32) 
-  v.push_back($n$); 
-for( ; $n$ &gt; 0; --$n$) 
-  v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
-</del></pre></blockquote>
 <blockquote>
-<pre><ins>
-for (InputIterator s = begin; s != end; ++s)
-   v.push_back((*s) mod 2<sup>32</sup>);
-</ins></pre>
-</blockquote>
-</blockquote>
+The <code>shared_ptr</code> class template stores a pointer, usually obtained
+via <code>new</code>. <code>shared_ptr</code> implements semantics of
+shared ownership; the last remaining owner of the pointer is responsible for
+destroying the object, or otherwise releasing  the resources associated with
+the stored pointer. <ins>A <code>shared_ptr</code> object that does not own
+a pointer is said to be <i>empty</i>.</ins>
 </blockquote>
 
 
@@ -16218,858 +14412,938 @@ for (InputIterator s = begin; s != end; ++s)
 
 
 <hr>
-<h3><a name="804"></a>804. Some problems with classes <tt>error_code</tt>/<tt>error_condition</tt></h3>
-<p><b>Section:</b> 19.4 [syserr] <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>Date:</b> 2008-02-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</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>
+<h3><a name="814"></a>814. <tt>vector&lt;bool&gt;::swap(reference, reference)</tt> not defined</h3>
+<p><b>Section:</b> 23.2.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> Alisdair Meredith <b>Date:</b> 2008-03-17</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector.bool">active issues</a> in [vector.bool].</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>
-<ol type="A">
-<li>
-<p>
-19.4.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> and
-19.4.3.1 [syserr.errcondition.overview]/, class <tt>error_condition</tt> synopses
-declare an expository data member <tt>cat_</tt>:
-</p>
-<blockquote><pre>const error_category&amp; cat_; // exposition only
-</pre></blockquote>
 <p>
-which is used to define the semantics of several members. The decision
-to use a member of reference type lead to several problems:
+<tt>vector&lt;bool&gt;::swap(reference, reference)</tt> has no definition.
 </p>
-<ol>
-<li>
-The classes are not <tt>(Copy)Assignable</tt>, which is probably not the intent.
-</li>
-<li>
-The post conditions of all modifiers from
-19.4.2.3 [syserr.errcode.modifiers] and 19.4.3.3 [syserr.errcondition.modifiers], resp.,
-cannot be fulfilled.
-</li>
-</ol>
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-The simple fix would be to replace the reference by a pointer member.
 </p>
-</li>
 
-<li>
-I would like to give the editorial remark that in both classes the
-constrained <tt>operator=</tt>
-overload (template with <tt>ErrorCodeEnum</tt> argument) makes in invalid
-usage of <tt>std::enable_if</tt>: By using the default value for the second <tt>enable_if</tt>
-parameter the return type would be defined to be <tt>void&amp;</tt> even in otherwise
-valid circumstances - this return type must be explicitly provided (In
-<tt>error_condition</tt> the first declaration uses an explicit value, but of wrong
-type).
-</li>
 
-<li>
-The member function <tt>message</tt> throws clauses (
-19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and
-19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing",
-although
-they return a <tt>std::string</tt> by value, which might throw in out-of-memory
-conditions (see related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>).
-</li>
-</ol>
 
 
-<p><b>Proposed resolution:</b></p>
+
+<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.6.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>Date:</b> 2008-03-16</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 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
+<tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as
+described in the rvalue core proposal.
 </p>
 
-<blockquote>
-<pre>virtual string message(int ev) const = 0;
-</pre>
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
 
 <blockquote>
-<p>
-<i>Returns:</i> A string that describes the error condition denoted by <tt>ev</tt>.
-</p>
-<p>
-<del><i>Throws:</i> Nothing.</del>
-</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>
 
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-In 19.4.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> synopsis, modifiers section,
-replace the current <tt>operator=</tt> overload by the following:
 </p>
 
-<blockquote>
-<pre>template &lt;class ErrorCodeEnum&gt; 
-  typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value<ins>, error_code</ins>&gt;::type&amp; 
-    operator=(ErrorCodeEnum e);
-</pre>
-</blockquote>
 
+
+
+
+<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.6.11.1.3 [func.bind.bind] <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>Date:</b> 2008-02-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#New">New</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>
-In the private section of the same class replace the current
-data member <tt>cat_</tt> definition by:
+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>
-const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
+<tt>tuple</tt> construction should probably have a similar guarantee.
 </blockquote>
 
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-In 19.4.2.2 [syserr.errcode.constructors], change p. 2 to read:
 </p>
 
-<blockquote>
-<pre>error_code();
-</pre>
-<blockquote>
-<p>
-</p><p>...</p>
 
+
+
+
+<hr>
+<h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3>
+<p><b>Section:</b> 20.6.11.1.3 [func.bind.bind] <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>Date:</b> 2008-03-17</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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>system_category</tt>.
+The functor retureed 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>
-</blockquote>
-</blockquote>
-
 <p>
-Change 19.4.2.2 [syserr.errcode.constructors] p. 5 to read:
+This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>.
 </p>
 
-<blockquote>
-<pre>error_code(int val, const error_category&amp; cat);
-</pre>
-<blockquote>
-<p>...</p>
+
+<p><b>Proposed resolution:</b></p>
 <p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
 </p>
-</blockquote>
-</blockquote>
 
+
+
+
+
+<hr>
+<h3><a name="818"></a>818. wording for memory ordering</h3>
+<p><b>Section:</b> 29.1 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-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 19.4.2.3 [syserr.errcode.modifiers], change p. 1 to read:
+29.1 [atomics.order] p1 says in the table that
 </p>
 
 <blockquote>
-<pre>void assign(int val, const error_category&amp; cat);
-</pre>
-<blockquote>
-<p>
-</p><p>...</p>
+<table border="1">
+<tbody><tr>
+<th>Element</th><th>Meaning</th>
+</tr>
+<tr>
+<td><tt>memory_order_acq_rel</tt></td>
+<td>the operation has both acquire and release semantics</td>
+</tr>
+</tbody></table>
+</blockquote>
 
 <p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
+To my naked eye, that seems to imply that even an atomic read has both
+acquire and release semantics.
 </p>
-</blockquote>
-</blockquote>
 
 <p>
-In 19.4.2.3 [syserr.errcode.modifiers], change the <tt>operator=</tt> signature to read:
+Then, p1 says in the table:
 </p>
 
 <blockquote>
-<pre>template &lt;class ErrorCodeEnum&gt; 
-  typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value<ins>, error_code</ins>&gt;::type&amp; 
-    operator=(ErrorCodeEnum e);
-</pre>
+<table border="1">
+<tbody><tr>
+<th>Element</th><th>Meaning</th>
+</tr>
+<tr>
+<td><tt>memory_order_seq_cst</tt></td>
+<td>the operation has both acquire and release semantics,
+    and, in addition, has sequentially-consistent operation ordering</td>
+</tr>
+</tbody></table>
 </blockquote>
 
 <p>
-In 19.4.2.4 [syserr.errcode.observers], change p. 3 to read:
+So that seems to be "the same thing" as <tt>memory_order_acq_rel</tt>, with additional
+constraints.
 </p>
 
-<blockquote>
-<pre>const error_category&amp; category() const;
-</pre>
-<blockquote>
 <p>
-</p><p>...</p>
+I'm then reading p2, where it says:
+</p>
+
+<blockquote>
+The <tt>memory_order_seq_cst</tt> operations that load a value are acquire operations
+on the affected locations. The <tt>memory_order_seq_cst</tt> operations that store a value
+are release operations on the affected locations.
+</blockquote>
 
 <p>
-<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
+That seems to imply that atomic reads only have acquire semantics.  If that
+is intended, does this also apply to <tt>memory_order_acq_rel</tt> and the individual
+load/store operations as well?
 </p>
-</blockquote>
-</blockquote>
 
 <p>
-In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8.
+Also, the table in p1 contains phrases with "thus" that seem to indicate
+consequences of normative wording in 1.10 [intro.multithread].  That shouldn't be in
+normative text, for the fear of redundant or inconsistent specification with
+the other normative text.
 </p>
 
-<blockquote>
-<pre>string message() const;
-</pre>
-<blockquote>
 <p>
-</p><p>...</p>
+Double-check 29.4 [atomics.types.operations] that each
+operation clearly says whether it's a load or a store operation, or
+both.  (It could be clearer, IMO.  Solution not in current proposed resolution.)
+</p>
 
 <p>
-<del><i>Throws:</i> Nothing.</del>
+29.1 [atomics.order] p2:  What's a "consistent execution"?  It's not defined in
+1.10 [intro.multithread], it's just used in notes there.
 </p>
-</blockquote>
-</blockquote>
 
 <p>
-In 19.4.3.1 [syserr.errcondition.overview]/1, class <tt>error_condition</tt>
-synopsis, constructors section, replace the template constructor
-overload declaration by one with an added "::value"
+And why does 29.4 [atomics.types.operations] p9 for "load" say:
 </p>
 
+
 <blockquote>
-<pre>template &lt;class ErrorConditionEnum&gt;
-  error_condition(ErrorConditionEnum e,
-    typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;<ins>::value</ins>&gt;::type* = 0);
-</pre>
+<i>Requires:</i> The order argument shall not be <tt>memory_order_acquire</tt>
+nor <tt>memory_order_acq_rel</tt>.
 </blockquote>
 
 <p>
-In 19.4.3.1 [syserr.errcondition.overview]/1, class <tt>error_condition</tt> synopsis,
-modifiers section,
-replace the <tt>operator=</tt> overload declaration by:
+(Since this is exactly the same restriction as for "store", it seems to be a typo.)
+</p>
+
+<p>
+And then: 29.4 [atomics.types.operations] p12:
 </p>
 
 <blockquote>
-<pre>template&lt;typename ErrorConditionEnum&gt; 
-  typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;<ins>::value</ins>, <del>error_code</del> <ins>error_condition</ins>&gt;::type &amp; 
-     operator=( ErrorConditionEnum e );
-</pre>
+These operations are read-modify-write operations in the sense of the
+"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the
+evaluation that produced the input value synchronize with any evaluation
+that reads the updated value.
 </blockquote>
 
 <p>
-In the private section of the same class replace the current
-data member <tt>cat_</tt> definition by:
+This is redundant with 1.10 [intro.multithread], see above for the reasoning.
 </p>
 
-<blockquote><pre>const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-In 19.4.3.2 [syserr.errcondition.constructors], change p. 2 to read:
+Replace the cross-reference in p1 to refer to 1.1 [intro.scope] instead of
+1.7 [intro.memory].
+Rephrase the table in as follows (maybe don't use a table):
 </p>
 
 <blockquote>
-<pre>error_condition();
-</pre>
-<blockquote>
-<p>
-</p><p>...</p>
-
 <p>
-<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>posix_category</tt>.
+For <tt>memory_order_relaxed</tt>, no operation orders memory.
 </p>
-</blockquote>
-</blockquote>
 
 <p>
-In the same section, change p. 5 to read:
+For <tt>memory_order_release</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>,
+a store operation performs a release operation on the affected memory location.
 </p>
 
-<blockquote>
-<pre>error_condition(int val, const error_category&amp; cat);
-</pre>
-<blockquote>
-<p>
-</p><p>...</p>
-
 <p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
+For <tt>memory_order_acquire</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>,
+a load operation performs an acquire operation on the affected memory location.
 </p>
 </blockquote>
-</blockquote>
 
 <p>
-In 19.4.3.3 [syserr.errcondition.modifiers], change p. 1 to read:
+Rephrase 29.1 [atomics.order] p2:
 </p>
 
 <blockquote>
-<pre>void assign(int val, const error_category&amp; cat);
-</pre>
-<blockquote>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
-</p>
-</blockquote>
+<del>The <tt>memory_order_seq_cst</tt> operations that load a value are
+acquire operations on the affected locations. The
+<tt>memory_order_seq_cst</tt> operations that store a value are release
+operations on the affected locations.</del>
+<del>In addition, in a consistent
+execution, t</del><ins>T</ins>here <del>must be</del> <ins>is</ins> a single
+total order <tt>S</tt> on all
+<tt>memory_order_seq_cst</tt> operations, consistent with the happens before
+order and modification orders for all affected locations, such that each
+<tt>memory_order_seq_cst</tt> operation observes either the last preceding
+modification according to this order <tt>S</tt>, or the result of an operation
+that is not <tt>memory_order_seq_cst</tt>. [<i>Note:</i> Although it is not explicitly
+required that <tt>S</tt> include locks, it can always be extended to an order
+that does include lock and unlock operations, since the ordering between
+those is already included in the happens before ordering. <i>-- end note</i>]
 </blockquote>
 
 <p>
-In the same section replace the current <tt>operator=</tt> overload declaration by:
+Rephrase 29.4 [atomics.types.operations] p12 as:
 </p>
 
 <blockquote>
-<pre>template &lt;class ErrorConditionEnum&gt; 
-  typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value<ins>, error_condition</ins>&gt;::type&amp;
-    operator=(ErrorConditionEnum e);
-</pre></blockquote>
+<i>Effects:</i> Atomically replaces the value pointed to by object or by
+this with desired. Memory is affected according to the value of order.
+These operations are read-modify-write operations <del>in the sense of the
+"synchronizes with" definition</del> (1.10 [intro.multithread])<del>, so both such an operation and the
+evaluation that produced the input value synchronize with any evaluation
+that reads the updated value</del>.
+</blockquote>
 
 <p>
-In 19.4.3.4 [syserr.errcondition.observers], change p. 3 to read:
+Same in p15, p20, p22.
 </p>
 
-<blockquote>
-<pre>const error_category&amp; category() const;
-</pre>
-<blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="819"></a>819. rethrow_if_nested</h3>
+<p><b>Section:</b> 18.7.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> Alisdair Meredith <b>Date:</b> 2008-03-25</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>Returns:</i> <tt><ins>*</ins>cat_</tt>.
+Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I
+got it quite right.
 </p>
-</blockquote>
-</blockquote>
 
 <p>
-In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.
+The current wording says:
 </p>
 
 <blockquote>
-<pre>string message() const;
+<pre>template &lt;class E&gt; void rethrow_if_nested(const E&amp; e);
 </pre>
 <blockquote>
 <p>
-</p><p>...</p>
-
-<p>
-<del><i>Throws:</i> Nothing.</del>
+<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>
+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><b>Proposed resolution:</b></p>
+
 
 
 
 
 <hr>
-<h3><a name="805"></a>805. <tt>posix_error::posix_errno</tt> concerns</h3>
-<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-02-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</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>
+<h3><a name="820"></a>820. <tt>current_exception()</tt>'s interaction with throwing copy ctors</h3>
+<p><b>Section:</b> 18.7.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> Stephan T. Lavavej <b>Date:</b> 2008-03-26</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>
-19.4 [syserr]
+As of N2521, the Working Paper appears to be silent about what
+<tt>current_exception()</tt> should do if it tries to copy the currently handled
+exception and its copy constructor throws.  18.7.5 [propagation]/7 says "If the
+function needs to allocate memory and the attempt fails, it returns an
+<tt>exception_ptr</tt> object that refers to an instance of <tt>bad_alloc</tt>.", but
+doesn't say anything about what should happen if memory allocation
+succeeds but the actual copying fails.
 </p>
 
-<blockquote><pre>namespace posix_error {
-  enum posix_errno {
-    address_family_not_supported, // EAFNOSUPPORT
-    ...
-</pre></blockquote>
+<p>
+I see three alternatives: (1) return an <tt>exception_ptr</tt> object that refers
+to an instance of some fixed exception type, (2) return an <tt>exception_ptr</tt>
+object that refers to an instance of the copy ctor's thrown exception
+(but if that has a throwing copy ctor, an infinite loop can occur), or
+(3) call <tt>terminate()</tt>.
+</p>
 
 <p>
-should rather use the new scoped-enum  facility (7.2 [dcl.enum]),
-which would avoid the necessity for a new <tt>posix_error</tt>
-namespace, if I understand correctly.
+I believe that <tt>terminate()</tt> is the most reasonable course of action, but
+before we go implement that, I wanted to raise this issue.
 </p>
 
 <p><i>[
-Further discussion:
+Peter's summary:
 ]</i></p>
 
 
 <blockquote>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf">N2347</a>,
-Strongly Typed Enums, since renamed Scoped Enums.
+The current practice is to not have throwing copy constructors in
+exception classes, because this can lead to <tt>terminate()</tt> as described in
+15.5.1 [except.terminate]. Thus calling <tt>terminate()</tt> in this situation seems
+consistent and does not introduce any new problems.
 </p>
+
 <p>
-Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution.
+However, the resolution of core issue 475 may relax this requirement:
 </p>
+
+<blockquote>
+The CWG agreed with the position that <tt>std::uncaught_exception()</tt> should
+return <tt>false</tt> during the copy to the exception object and that <tt>std::terminate()</tt>
+should not be called if that constructor exits with an exception.
+</blockquote>
+
 <p>
-Nick Stoughton asked in Bellevue that <tt>posix_error</tt> and <tt>posix_errno</tt> not be used as names. The LWG agreed.
+Since throwing copy constructors will no longer call <tt>terminate()</tt>, option
+(3) doesn't seem reasonable as it is deemed too drastic a response in a
+recoverable situation.
 </p>
+
 <p>
-The wording for the Proposed resolution was provided by Beman Dawes.
+Option (2) cannot be adopted by itself, because a potential infinite
+recursion will need to be terminated by one of the other options.
 </p>
+
 </blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change System error support 19.4 [syserr] as indicated:
+Add the following paragraph after 18.7.5 [propagation]/7:
 </p>
 
-<blockquote><pre><del>namespace posix_error {</del>
-  enum <del>posix_errno</del> <ins>class errc</ins> {
-    address_family_not_supported, // EAFNOSUPPORT
-    ...
-    wrong_protocol_type, // EPROTOTYPE
-  };
-<del>} // namespace posix_error</del>
+<blockquote>
+<p>
+<i>Returns (continued):</i> If the attempt to copy the current exception
+object throws an exception, the function returns an <tt>exception_ptr</tt> that
+refers to the thrown exception or, if this is not possible, to an
+instance of <tt>bad_exception</tt>.
+</p>
+<p>
+[<i>Note:</i> The copy constructor of the thrown exception may also fail, so
+the implementation is allowed to substitute a <tt>bad_exception</tt> to avoid
+infinite recursion. <i>-- end note.</i>]
+</p>
+</blockquote>
+
+
 
-template &lt;&gt; struct is_error_condition_enum&lt;<del>posix_error::posix_errno</del> <ins>errc</ins>&gt;
-  : public true_type {}
 
-<del>namespace posix_error {</del>
-  error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
-  error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
-<del>} // namespace posix_error</del>
-</pre></blockquote>
 
+
+<hr>
+<h3><a name="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3>
+<p><b>Section:</b> 20.7.11.3.3 [unique.ptr.runtime.modifiers] <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>Date:</b> 2008-03-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>
-Change System error support 19.4 [syserr] :
+Reading resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> I noticed the following:
 </p>
 
 <blockquote>
-<del>The <tt>is_error_code_enum</tt> and <tt>is_error_condition_enum</tt> templates may be
-specialized for user-defined types to indicate that such a type is
-eligible for class <tt>error_code</tt> and class <tt>error_condition</tt> automatic
-conversions, respectively.</del>
+<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
+</pre>
+
+<p>
+-1- <i>Requires:</i> Does not accept pointer types which are convertible
+to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
+required). [<i>Note:</i> One implementation technique is to create a private
+templated overload. <i>-- end note</i>]
+</p>
 </blockquote>
 
 <p>
-Change System error support 19.4 [syserr] and its subsections:
+This could be cleaned up by mandating the overload as a public deleted
+function.  In addition, we should probably overload <tt>reset</tt> on <tt>nullptr_t</tt>
+to be a stronger match than the deleted overload. Words...
 </p>
 
-<blockquote>
-<ul>
-<li>
-remove all occurrences of <tt>posix_error::</tt>
-</li>
-<li>
-change all instances of <tt>posix_errno</tt> to <tt>errc</tt>
-</li>
-<li>
-change all instances of <tt>posix_category</tt> to <tt>generic_category</tt>
-</li>
-<li>
-change all instances of <tt>get_posix_category</tt> to <tt>get_generic_category</tt>
-</li>
-</ul>
-</blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2:
+Add to class template definition in 20.7.11.3 [unique.ptr.runtime]
 </p>
 
 <blockquote>
-<i>Remarks:</i> The object's <tt>default_error_condition</tt> and equivalent virtual
-functions shall behave as specified for the class <tt>error_category</tt>. The
-object's name virtual function shall return a pointer to the string
-<del>"POSIX"</del> <ins>"GENERIC"</ins>.
+<pre>// modifiers 
+T* release(); 
+void reset(T* p = 0); 
+<ins>void reset( nullptr_t );</ins>
+<ins>template&lt; typename T &gt; void reset( T ) = delete;</ins>
+void swap(unique_ptr&amp;&amp; u);
+</pre>
 </blockquote>
 
 <p>
-Change 19.4.2.5 [syserr.errcode.nonmembers] Class <tt>error_code</tt> non-member functions as indicated:
+Update 20.7.11.3.3 [unique.ptr.runtime.modifiers]
 </p>
 
 <blockquote>
-<pre>error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
+<pre>void reset(pointer p = pointer());
+<ins>void reset(nullptr_t);</ins>
 </pre>
 
-<blockquote>
-<i>Returns:</i> <tt>error_code(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
-</blockquote>
+<p>
+<del>-1- <i>Requires:</i> Does not accept pointer types which are convertible
+to <tt>pointer</tt> (diagnostic
+required). [<i>Note:</i> One implementation technique is to create a private
+templated overload. <i>-- end note</i>]</del>
+</p>
+<p>
+<i>Effects:</i> If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>. 
+</p>
+<p>...</p>
 </blockquote>
 
+<p><i>[
+Note this wording incorporates resolutions for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a> (New) and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (Ready).
+]</i></p>
+
+
+
+
+
+
+<hr>
+<h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3>
+<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <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>Date:</b> 2008-04-01</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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Change 19.4.3.5 [syserr.errcondition.nonmembers] Class <tt>error_condition</tt> non-member functions as indicated:
+I just noticed that the following program is legal in C++03, but
+is forbidden in the current draft:
 </p>
 
-<blockquote>
-<pre>error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
-</pre>
+<blockquote><pre>#include &lt;vector&gt;
+#include &lt;iostream&gt;
 
-<blockquote>
-<i>Returns:</i> <tt>error_condition(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
-</blockquote>
-</blockquote>
+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.)
+</p>
 
 
 
-<p><b>Rationale:</b></p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.1.1 [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]:
+</p>
+
+<blockquote>
 <table border="1">
 <tbody><tr>
-<th colspan="2">Names Considered</th>
+<th>expression</th><th>post-condition</th>
 </tr>
-
 <tr>
-<td><tt>portable</tt></td>
-<td>
-Too non-specific. Did not wish to reserve such a common word in
-namespace std. Not quite the right meaning, either.
-</td>
+<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><tt>portable_error</tt></td>
-<td>
-Too long. Explicit qualification is always required for scoped enums, so
-a short name is desirable. Not quite the right meaning, either. May be
-misleading because <tt>*_error</tt> in the std lib is usually an exception class
-name.
-</td>
+<td colspan="2" align="center">...</td>
 </tr>
+</tbody></table>
+</blockquote>
+
+<p>
+In 20.1.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]:
+</p>
 
+<blockquote>
+<table border="1">
+<tbody><tr>
+<th>expression</th><th>post-condition</th>
+</tr>
 <tr>
-<td><tt>std_error</tt></td>
-<td>
-Fairly short, yet explicit. But in fully qualified names like
-<tt>std::std_error::not_enough_memory</tt>, the std_ would be unfortunate. Not
-quite the right meaning, either. May be misleading because <tt>*_error</tt> in
-the std lib is usually an exception class name.
-</td>
+<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><tt>generic</tt></td>
-<td>
-Short enough. The category could be <tt>generic_category</tt>. Fully qualified
-names like <tt>std::generic::not_enough_memory</tt> read well. Reserving in
-namespace std seems dicey.
-</td>
-</tr>
-
-<tr>
-<td><tt>generic_error</tt></td>
-<td>
-Longish. The category could be <tt>generic_category</tt>. Fully qualified names
-like <tt>std::generic_error::not_enough_memory</tt> read well. Misleading because
-<tt>*_error</tt> in the std lib is usually an exception class name.
-</td>
-</tr>
-
-<tr>
-<td><tt>generic_err</tt></td>
-<td>
-A bit less longish. The category could be <tt>generic_category</tt>. Fully
-qualified names like <tt>std::generic_err::not_enough_memory</tt> read well.
-</td>
-</tr>
-
-<tr>
-<td><tt>gen_err</tt></td>
-<td>
-Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
-names like <tt>std::gen_err::not_enough_memory</tt> read well.
-</td>
-</tr>
-
-<tr>
-<td><tt>generr</tt></td>
-<td>
-Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
-names like <tt>std::generr::not_enough_memory</tt> read well.
-</td>
-</tr>
-
-<tr>
-<td><tt>error</tt></td>
-<td>
-Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
-names like <tt>std::error::not_enough_memory</tt> read well. Do we want to use
-this general a name?
-</td>
-</tr>
-
-<tr>
-<td><tt>err</tt></td>
-<td>
-Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
-names like <tt>std::err::not_enough_memory</tt> read well. Although alone it
-looks odd as a name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names,
-it seems fairly intuitive.
-Problem: <tt>err</tt> is used throughout the standard library as an argument name
-and in examples as a variable name; it seems too confusing to add yet
-another use of the name.
-</td>
-</tr>
-
-<tr>
-<td><tt>errc</tt></td>
-<td>
-Short enough. The "c" stands for "constant". The category could be
-<tt>generic_category</tt>. Fully qualified names like
-<tt>std::errc::not_enough_memory</tt> read well. Although alone it looks odd as a
-name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names, it seems fairly
-intuitive. There are no uses of <tt>errc</tt> in the current C++ standard.
-</td>
+<td colspan="2" align="center">...</td>
 </tr>
 </tbody></table>
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="806"></a>806. <tt>unique_ptr::reset</tt> effects incorrect, too permissive</h3>
-<p><b>Section:</b> 20.6.11.2.5 [unique.ptr.single.modifiers] <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>Date:</b> 2008-03-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>
+<h3><a name="823"></a>823. <tt>identity&lt;void&gt;</tt> seems broken</h3>
+<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Walter Brown <b>Date:</b> 2008-04-09</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>
+<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>
-<tt>void unique_ptr::reset(T* p = 0)</tt> is currently specified as:
+N2588 seems to have added an <tt>operator()</tt> member function to the
+<tt>identity&lt;&gt;</tt> helper in 20.2.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>
 
-<blockquote>
-<i>Effects:</i> If <tt>p == get()</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
-</blockquote>
-
 <p>
-There are two problems with this. One, if <tt>get() == 0</tt> and <tt>p != 0</tt>, the
-deleter is called with a NULL pointer, and this is probably not what's
-intended (the destructor avoids calling the deleter with 0.)
+Suggested resolution:  Specialize <tt>identity&lt;void&gt;</tt> so as not to require
+the member function's presence.
 </p>
 
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
 <p>
-Two, the special check for <tt>get() == p</tt> is generally not needed and such a
-situation usually indicates an error in the client code, which is being
-masked. As a data point, <tt>boost::shared_ptr</tt> was changed to assert on such
-self-resets in 2001 and there were no complaints.
+Jens: suggests to add a requires clause to avoid specializing on <tt>void</tt>.
 </p>
-
 <p>
-One might think that self-resets are necessary for operator= to work; it's specified to perform
+Alisdair: also consider cv-qualified <tt>void</tt>.
+</p>
+<p>
+Alberto provided proposed wording.
 </p>
+</blockquote>
 
-<blockquote><pre>reset( u.release() );
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-and the self-assignment
+Change definition of <tt>identity</tt> in 20.2.2 [forward], paragraph 2, to:
 </p>
 
-<blockquote><pre>p = move(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>
-might appear to result in a self-reset. But it doesn't; the <tt>release()</tt> is
-performed first, zeroing the stored pointer. In other words, <tt>p.reset(
-q.release() )</tt> works even when <tt>p</tt> and <tt>q</tt> are the same <tt>unique_ptr</tt>, and there
-is no need to special-case <tt>p.reset( q.get() )</tt> to work in a similar
-scenario, as it definitely doesn't when <tt>p</tt> and <tt>q</tt> are separate.
+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>
 
 
 
-<p><b>Proposed resolution:</b></p>
+
+
+<hr>
+<h3><a name="824"></a>824. rvalue ref issue with <tt>basic_string</tt> inserter</h3>
+<p><b>Section:</b> 21.3.8.9 [string.io] <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>Date:</b> 2008-04-10</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</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 the current working paper, the <tt>&lt;string&gt;</tt> header synopsis at the end of
+21.2 [string.classes] lists a single <tt>operator&lt;&lt;</tt> overload
+for <tt>basic_string</tt>.
+</p>
+
+<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
+ basic_ostream&lt;charT, traits&gt;&amp;
+   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
+              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
+</pre></blockquote>
 
 <p>
-Change 20.6.11.2.5 [unique.ptr.single.modifiers]:
+The definition in 21.3.8.9 [string.io] lists two:
 </p>
 
-<blockquote>
-<pre>void reset(T* p = 0);
-</pre>
-<blockquote>
--4- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
-</blockquote>
-</blockquote>
+<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
+ basic_ostream&lt;charT, traits&gt;&amp;
+   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
+              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
+
+template&lt;class charT, class traits, class Allocator&gt;
+ basic_ostream&lt;charT, traits&gt;&amp;
+   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
+              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
+</pre></blockquote>
 
 <p>
-Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]:
+I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two
+signatures in 21.3.8.9 [string.io] should be deleted.
 </p>
 
-<blockquote>
-<pre>void reset(T* p = 0);
-</pre>
-<blockquote>
-<p>...</p>
+
+<p><b>Proposed resolution:</b></p>
 <p>
--2- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
+Delete the first of the two signatures in 21.3.8.9 [string.io]:
 </p>
-</blockquote>
-</blockquote>
 
+<blockquote><pre><del>template&lt;class charT, class traits, class Allocator&gt;
+ basic_ostream&lt;charT, traits&gt;&amp;
+   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
+              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);</del>
+
+template&lt;class charT, class traits, class Allocator&gt;
+ basic_ostream&lt;charT, traits&gt;&amp;
+   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
+              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
+</pre></blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="807"></a>807. <tt>tuple</tt> construction should not fail unless its element's construction fails</h3>
-<p><b>Section:</b> 20.3.1.2 [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> Howard Hinnant <b>Date:</b> 2008-03-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>
+<h3><a name="825"></a>825. Missing rvalues reference stream insert/extract operators?</h3>
+<p><b>Section:</b> 19.4.2.1 [syserr.errcode.overview], 20.7.12.2.8
+[util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3
+[bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9
+[re.submatch] <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>Date:</b> 2008-04-10</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 href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> Added a throws clause to <tt>bind</tt> constructors.  I believe the same throws clause
-should be added to <tt>tuple</tt> except it ought to take into account move constructors as well.
+Should the following use rvalues references to stream in insert/extract
+operators?
 </p>
 
+<ul>
+<li>19.4.2.1 [syserr.errcode.overview]</li>
+<li>20.7.12.2.8 [util.smartptr.shared.io]</li>
+<li>22.2.8 [facets.examples]</li>
+<li>23.3.5.3 [bitset.operators]</li>
+<li>26.3.6 [complex.ops]</li>
+<li>Doubled signatures in 27.5 [stream.buffers] for character inserters
+(ref 27.6.2.6.4 [ostream.inserters.character])
++ definition 27.6.2.6.4 [ostream.inserters.character]</li>
+<li>28.9 [re.submatch]</li>
+</ul>
+
+<p><i>[
+Sophia Antipolis
+]</i></p>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to 20.3.1.2 [tuple.cnstr]:
-</p>
 
 <blockquote>
+Agree with the idea in the issue, Alisdair to provide wording.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-For each <tt>tuple</tt> constructor and assignment operator, an exception is thrown only if the construction
-or assignment of one of the types in <tt>Types</tt> throws an exception.
 </p>
-</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="808"></a>808. [forward] incorrect redundant specification</h3>
-<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-13</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="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3>
+<p><b>Section:</b> 20.7.12.2.1 [util.smartptr.shared.const] <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>Date:</b> 2008-04-11</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#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-p4 (forward) says:
+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.
 </p>
-<blockquote>
-<i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.
-</blockquote>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-First of all, lvalue-ness and rvalue-ness are properties of an expression,
-not of a type (see 3.10 [basic.lval]).  Thus, the phrasing "Return type" is wrong.
-Second, the phrase says exactly what the core language wording says for
-folding references in 14.3.1 [temp.arg.type]/p4  and for function return values
-in 5.2.2 [expr.call]/p10.  (If we feel the wording should be retained, it should
-at most be a note with cross-references to those sections.)
 </p>
+
+
+
+
+
+<hr>
+<h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3>
+<p><b>Section:</b> 30.3.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>Date:</b> 2008-04-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>
-The prose after the example talks about "forwarding as an <tt>int&amp;</tt> (an lvalue)" etc.
-In my opinion, this is a category error:  "<tt>int&amp;</tt>" is a type, "lvalue" is a
-property of an expression, orthogonal to its type.  (Btw, expressions cannot
-have reference type, ever.)
-</p>
-<p>
-Similar with move:
+[Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
 </p>
-<blockquote>
-Return type: an rvalue.
-</blockquote>
 <p>
-is just wrong and also redundant.
+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.
 </p>
 
+<p><i>[
+Sophia Antipolis:
+]</i></p>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.2.2 [forward] as indicated:
-</p>
-
-<blockquote>
-<pre>template &lt;class T&gt; T&amp;&amp; forward(typename identity&lt;T&gt;::type&amp;&amp; t);
-</pre>
 
 <blockquote>
-<p>...</p>
 <p>
-<del><i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.</del>
+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.
 </p>
-<p>...</p>
 <p>
--7- In the first call to <tt>factory</tt>, <tt>A1</tt> is deduced as <tt>int</tt>, so 2 is forwarded to <tt>A</tt>'s constructor
-as <del>an <tt>int&amp;&amp;</tt> (</del>an rvalue<del>)</del>. In the second call to factory, <tt>A1</tt> is deduced
-as <tt>int&amp;</tt>, so <tt>i</tt> is forwarded to <tt>A</tt>'s constructor as <del>an <tt>int&amp;</tt> (</del>an lvalue<del>)</del>.
-In both cases, <tt>A2</tt> is deduced as double, so 1.414 is forwarded to <tt>A</tt>'s constructor as
-<del><tt>double&amp;&amp;</tt> (</del>an rvalue<del>)</del>.
+If ubiquitous implementability cannot be assured, plan B is to introduce
+another constructor, make this constexpr, which is
+conditionally-supported. To avod ambiguities, this new constructor needs
+to have an additional parameter.
 </p>
 </blockquote>
 
-<pre>template &lt;class T&gt; typename remove_reference&lt;T&gt;::type&amp;&amp; move(T&amp;&amp; t);
-</pre>
 
-<blockquote>
-<p>...</p>
+<p><b>Proposed resolution:</b></p>
 <p>
-<del><i>Return type:</i>  an rvalue.</del>
+Change 30.3.1.1 [thread.mutex.class]:
 </p>
-</blockquote>
-
-</blockquote>
 
+<blockquote><pre>class mutex { 
+public: 
+  <ins>constexpr</ins> mutex(); 
+  ...
+</pre></blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="809"></a>809. std::swap should be overloaded for array types</h3>
-<p><b>Section:</b> 25.2.3 [alg.swap] <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>Date:</b> 2008-02-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</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="829"></a>829. current_exception wording unclear about exception type</h3>
+<p><b>Section:</b> 18.7.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> Beman Dawes <b>Date:</b> 2008-04-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>
-For the sake of generic programming, the header <code>&lt;algorithm&gt;</code> should provide an
-overload of <code>std::swap</code> for array types:
-</p><pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
-</pre>
+<p>Consider this code:</p>
 
+<blockquote>
+<pre>exception_ptr xp;</pre>
+<pre>try {do_something(); }
 
-<p>
-It became apparent to me that this overload is missing, when I considered how to write a swap
-function for a generic wrapper class template.
-(Actually I was thinking of Boost's <a href="http://www.boost.org/libs/utility/value_init.htm">value_initialized</a>.)
-Please look at the following template, <code>W</code>, and suppose that is intended to be a very
-<em>generic</em> wrapper:
-</p><pre>template&lt;class T&gt; class W {
-public:
-   T data;
-};
-</pre>
-Clearly <code>W&lt;T&gt;</code> is <em>CopyConstructible and CopyAssignable</em>, and therefore
-<em>Swappable</em>, whenever <code>T</code> is <em>CopyConstructible and CopyAssignable</em>.
-Moreover, <code>W&lt;T&gt;</code> is <em>also</em> Swappable when <code>T</code> is an array type
-whose element type is CopyConstructible and CopyAssignable.
-Still it is recommended to add a <em>custom</em> swap function template to such a class template,
-for the sake of efficiency and exception safety.
-(E.g., <em>Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing
-swap</em>.)
-This function template is typically written as follows:
-<pre>template&lt;class T&gt; void swap(W&lt;T&gt;&amp; x, W&lt;T&gt;&amp; y) {
-  using std::swap;
-  swap(x.data, y.data);
-}
-</pre>
-Unfortunately, this will introduce an undesirable inconsistency, when <code>T</code> is an array.
-For instance, <code>W&lt;std::string[8]&gt;</code> is Swappable, but the current Standard does not
-allow calling the custom swap function that was especially written for <code>W</code>!
-<pre>W&lt;std::string[8]&gt; w1, w2;  // Two objects of a Swappable type.
-std::swap(w1, w2);  // Well-defined, but inefficient.
-using std::swap;
-swap(w1, w2);  // Ill-formed, just because ADL finds W's swap function!!!
-</pre>
+catch (const runtime_error&amp; ) {xp = current_exception();}
 
-<code>W</code>'s <code>swap</code> function would try to call <code>std::swap</code> for an array,
-<code>std::string[8]</code>, which is not supported by the Standard Library.
-This issue is easily solved by providing an overload of <code>std::swap</code> for array types.
-This swap function should be implemented in terms of swapping the elements of the arrays, so that
-it would be non-throwing for arrays whose element types have a non-throwing swap.
+...
 
+rethrow_exception(xp);</pre>
+</blockquote>
 
 <p>
-Note that such an overload of <code>std::swap</code> should also support <em>multi-dimensional</em>
-arrays. Fortunately that isn't really an issue, because it would do so <i>automatically</i>, by
-means of recursion.
+Say <code>do_something()</code> throws an exception object of type <code>
+range_error</code>. What is the type of the exception object thrown by <code>
+rethrow_exception(xp)</code> above? It must have a type of <code>range_error</code>; 
+if it were of type <code>runtime_error</code> it still isn't possible to 
+propagate an exception and the exception_ptr/current_exception/rethrow_exception 
+machinery serves no useful purpose.
 </p>
 
 <p>
-For your information, there was a discussion on this issue at comp.lang.c++.moderated: <a href="http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/9341ebd3635c9c74">[Standard
-Library] Shouldn't std::swap be overloaded for C-style arrays?</a>
+Unfortunately, the current wording does not explicitly say that. Different 
+people read the current wording and come to different conclusions. While it may 
+be possible to deduce the correct type from the current wording, it would be 
+much clearer to come right out and explicitly say what the type of the referred 
+to exception is.
 </p>
 
+<p><i>[
+Peter adds:
+]</i></p>
 
-<p><b>Proposed resolution:</b></p>
+
+<blockquote>
 <p>
-Add an extra condition to the definition of Swappable requirements [swappable] in 20.1.1 [utility.arg.requirements]:
+I don't like the proposed resolution of 829. The normative text is
+unambiguous that the <tt>exception_ptr</tt> refers to the <em>currently handled
+exception</em>. This term has a standard meaning, see 15.3 [except.handle]/8; this is the
+exception that <tt>throw;</tt> would rethrow, see 15.1 [except.throw]/7.
+</p>
+<p>
+A better way to address this is to simply add the non-normative example
+in question as a clarification. The term <i>currently handled exception</i>
+should be italicized and cross-referenced. A [<i>Note:</i> the currently
+handled exception is the exception that a throw expression without an
+operand (15.1 [except.throw]/7) would rethrow. <i>--end note</i>] is also an option.
 </p>
-<blockquote>
-- <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose element type is <tt>Swappable</tt>.
 </blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
 <p>
-Add the following to 25.2.3 [alg.swap]:
+After 18.7.5 [propagation] , paragraph 7, add the indicated text:
 </p>
+
 <blockquote>
-<pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
-</pre>
-<blockquote>
-<i>Requires:</i> Type <code>T</code> shall be <tt>Swappable</tt>.
-</blockquote>
+<pre>exception_ptr current_exception();</pre>
+
 <blockquote>
-<i>Effects:</i> <code>swap_ranges(a, a + N, b);</code>
+<p>
+<i>Returns:</i> <code>exception_ptr</code> object that refers 
+to the currently handled exception <ins>(15.3 [except.handle])</ins> or a copy of the currently handled 
+exception, or a null <code>exception_ptr</code> object if no exception is being handled. If 
+the function needs to allocate memory and the attempt fails, it returns an
+<code>exception_ptr</code> object that refers to an instance of <code>bad_alloc</code>. 
+It is unspecified whether the return values of two successive calls to
+<code>current_exception</code> refer to the same exception object. 
+[<i>Note:</i> that is, it 
+is unspecified whether <code>current_exception</code>
+creates a new copy each time it is called.
+<i>-- end note</i>]
+</p>
+
+<p>
+<i>Throws:</i> nothing.
+</p>
+
 </blockquote>
 </blockquote>
 
@@ -17077,843 +15351,2727 @@ Add the following to 25.2.3 [alg.swap]:
 
 
 
+
 <hr>
-<h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3>
-<p><b>Section:</b> 27.6.4 [ext.manip] <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>Date:</b> 2008-03-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</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="830"></a>830. Incomplete list of char_traits specializations</h3>
+<p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</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 recent draft (as well as the original proposal n2072) uses an
-operational semantic
-for <tt>get_money</tt> ([ext.manip]/3) and <tt>put_money</tt> ([ext.manip]/5), which uses
+  Paragraph 4 of 21.1 [char.traits] mentions that this
+  section specifies two specializations (<code>char_traits&lt;char&gt;</code>
+  and (<code>char_traits&lt;wchar_t&gt;</code>). However, there are actually
+  four specializations provided, i.e. in addition to the two above also
+  <code>char_traits&lt;char16_t&gt;</code> and <code>char_traits&lt;char32_t&gt;</code>).
+  I guess this was just an oversight and there is nothing wrong with just
+  fixing this.
 </p>
 
-<blockquote><pre>istreambuf_iterator&lt;charT&gt;
-</pre></blockquote>
+<p><i>[
+Alisdair adds:
+]</i></p>
 
-<p>
-and
-</p>
+<blockquote>
+<tt>char_traits&lt; char16/32_t &gt;</tt>
+should also be added to <tt>&lt;ios_fwd&gt;</tt> in 27.2 [iostream.forward], and all the specializations
+taking a <tt>char_traits</tt> parameter in that header.
+</blockquote>
 
-<blockquote><pre>ostreambuf_iterator&lt;charT&gt;
-</pre></blockquote>
+<p><i>[
+Sophia Antipolis:
+]</i></p>
 
+
+<blockquote>
 <p>
-resp, instead of the iterator instances, with explicitly provided
-traits argument (The operational semantic defined by <tt>f</tt> is also traits
-dependent). This is an obvious oversight because both <tt>*stream_buf</tt>
-c'tors expect a <tt>basic_streambuf&lt;charT,traits&gt;</tt> as argument.
+Idea of the issue is ok.
 </p>
 <p>
-The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic (p.
-7 and p. 9)
-of n2071 incorporated in N2521, where additional to the problem we
-have an editorial issue in <tt>get_time</tt> (<tt>streambuf_iterator</tt> instead of
-<tt>istreambuf_iterator</tt>).
+Alisdair to provide wording, once that wording arrives, move to review.
 </p>
+</blockquote>
+
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-In 27.6.4 [ext.manip]/3 within function <tt>f</tt> replace the first line
+  Replace paragraph 4 of 21.1 [char.traits] by:
 </p>
-
-<blockquote><pre>template &lt;class charT, class traits, class moneyT&gt; 
-void f(basic_ios&lt;charT, traits&gt;&amp; str, moneyT&amp; mon, bool intl) { 
-   typedef istreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
-   ...
-</pre></blockquote>
-
+<blockquote>
 <p>
-In 27.6.4 [ext.manip]/4 remove the first template <tt>charT</tt> parameter:
+  This subclause specifies a struct template, <code>char_traits&lt;charT&gt;</code>,
+  and four explicit specializations of it, <code>char_traits&lt;char&gt;</code>,
+  <code>char_traits&lt;char16_t&gt;</code>, <code>char_traits&lt;char32_t&gt;</code>, and
+  <code>char_traits&lt;wchar_t&gt;</code>, all of which appear in the header
+  &lt;string&gt; and satisfy the requirements below.
 </p>
+</blockquote>
 
-<blockquote><pre>template &lt;<del>class charT, </del>class moneyT&gt; unspecified put_money(const moneyT&amp; mon, bool intl = false<ins>)</ins>;
-</pre></blockquote>
 
-<p>
-In 27.6.4 [ext.manip]/5 within function <tt>f</tt> replace the first line
-</p>
 
-<blockquote><pre>template &lt;class charT, class traits, class moneyT&gt; 
-void f(basic_ios&lt;charT, traits&gt;&amp; str, const moneyT&amp; mon, bool intl) { 
-  typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
-  ...
-</pre></blockquote>
 
-<p>
-In 27.6.4 [ext.manip]/7 within function <tt>f</tt> replace the first line
-</p>
-
-<blockquote><pre>template &lt;class charT, class traits&gt; 
-void f(basic_ios&lt;charT, traits&gt;&amp; str, struct tm *tmb, const charT *fmt) { 
-  typedef <ins>i</ins>streambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
-  ...
-</pre></blockquote>
 
+<hr>
+<h3><a name="832"></a>832. Applying constexpr to System error support</h3>
+<p><b>Section:</b> 19.4 [syserr] <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>Date:</b> 2008-05-14</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</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#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-In 27.6.4 [ext.manip]/8 add const:
+Initialization of objects of class <tt>error_code</tt>
+(19.4.2 [syserr.errcode]) and class
+<tt>error_condition</tt> (19.4.3 [syserr.errcondition]) can be made simpler and more reliable by use of
+the new <tt>constexpr</tt> feature 
+[<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>]
+of C++0x. Less code will need to be
+generated for both library implementations and user programs when
+manipulating constant objects of these types. 
 </p>
 
-<blockquote><pre>template &lt;class charT&gt; unspecified put_time(<ins>const</ins> struct tm *tmb, const charT *fmt);
-</pre></blockquote>
-
 <p>
-In 27.6.4 [ext.manip]/9 within function <tt>f</tt> replace the first line
+This was not proposed originally because the constant expressions
+proposal was moving into the standard at about the same time as the
+Diagnostics Enhancements proposal 
+[<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>],
+and it wasn't desirable to
+make the later depend on the former. There were also technical concerns
+as to how <tt>constexpr</tt> would apply to references. Those concerns are now
+resolved; <tt>constexpr</tt> can't be used for references, and that fact is
+reflected in the proposed resolution.
 </p>
 
-<blockquote><pre>template &lt;class charT, class traits&gt; 
-void f(basic_ios&lt;charT, traits&gt;&amp; str, const struct tm *tmb, const charT *fmt) { 
-  typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
-  ...
-</pre></blockquote>
-
 <p>
-Add to the <tt>&lt;iomanip&gt;</tt> synopsis in 27.6 [iostream.format]
+Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of <tt>constexpr</tt> requirements.
 </p>
 
-<blockquote><pre>template &lt;class moneyT&gt; unspecified get_money(moneyT&amp; mon, bool intl = false);
-template &lt;class moneyT&gt; unspecified put_money(const moneyT&amp; mon, bool intl = false);
-template &lt;class charT&gt; unspecified get_time(struct tm *tmb, const charT *fmt);
-template &lt;class charT&gt; unspecified put_time(const struct tm *tmb, const charT *fmt);
-</pre></blockquote>
-
-
+<p>
+LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a> is related in that it raises the question of whether the
+exposition only member <tt>cat_</tt> of class <tt>error_code</tt> (19.4.2 [syserr.errcode]) and class
+<tt>error_condition</tt> (19.4.3 [syserr.errcondition]) should be presented as a reference or pointer.
+While in the context of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a> that is arguably an editorial question,
+presenting it as a pointer becomes more or less required with this
+proposal, given <tt>constexpr</tt> does not play well with references. The
+proposed resolution thus changes the private member to a pointer, which
+also brings it in sync with real implementations.
+</p>
 
+<p><i>[
+Sophia Antipolis:
+]</i></p>
 
 
+<blockquote>
+On going question of extern pointer vs. inline functions for interface.
+</blockquote>
 
-<hr>
-<h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-03-14</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#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<blockquote><pre>#include &lt;utility&gt;
+<p><i>[
+Pre-San Francisco:
+]</i></p>
 
-int main()
-{
-   std::pair&lt;char *, char *&gt; p (0,0);
-}
-</pre></blockquote>
 
+<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:
+Beman Dawes reports that this proposal is unimplementable, and thus NAD.
 </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>):
+Implementation would require <tt>constexpr</tt> objects of classes derived
+from class <tt>error_category</tt>, which has virtual functions, and that is
+not allowed by the core language. This was determined when trying to
+implement the proposal using a constexpr enabled compiler provided
+by Gabriel Dos Reis, and subsequently verified in discussions with
+Gabriel and Jens Maurer.
 </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><b>Proposed resolution:</b></p>
 <p>
+The proposed wording assumes the LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> proposed wording has been
+applied to the WP, resulting in the former <tt>posix_category</tt> being renamed
+<tt>generic_category</tt>. If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> has not been applied, the names in this
+proposal must be adjusted accordingly.
 </p>
 
+<p>
+Change 19.4.1.1 [syserr.errcat.overview] Class
+<tt>error_category</tt> overview <tt>error_category</tt> synopsis  as
+indicated:
+</p>
 
+<blockquote><pre><del>const error_category&amp; get_generic_category();</del>
+<del>const error_category&amp; get_system_category();</del>
 
+<del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>;
+<del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>native_category</del> system_category<del> = get_system_category()</del>;
+</pre></blockquote>
 
-
-<hr>
-<h3><a name="812"></a>812. unsolicited multithreading considered harmful?</h3>
-<p><b>Section:</b> 25.3.1 [alg.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Paul McKenney <b>Date:</b> 2008-02-27</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>
-Multi-threading is a good thing, but unsolicited multi-threading can
-potentially be harmful.  For example, <tt>sort()</tt> performance might be
-greatly increased via a multithreaded implementation.  However, such
-a multithreaded implementation could result in concurrent invocations
-of the user-supplied comparator.  This would in turn result in problems
-given a caching comparator that might be written for complex sort keys.
-Please note that this is not a theoretical issue, as multithreaded
-implementations of <tt>sort()</tt> already exist.
+Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated:
 </p>
+
+<blockquote>
+<pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>;
+</pre>
 <p>
-Having a multithreaded <tt>sort()</tt> available is good, but it should not
-be the default for programs that are not explicitly multithreaded.
-Users should not be forced to deal with concurrency unless they have
-asked for it.
+<del><i>Returns:</i> A reference</del> <ins><tt>generic_category</tt> shall point</ins>
+to <del>an</del> <ins>a statically initialized</ins> object of a type derived from
+class <tt>error_category</tt>.
 </p>
 
-<p><i>[
-This may be covered by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2410.html">N2410</a>
-Thread-Safety in the Standard Library (Rev 1).
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
+<del><i>Remarks:</i></del> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
+functions shall behave as specified for the class <tt>error_category</tt>. The
+object's <tt>name</tt> virtual function shall return a pointer to the string
+<tt>"GENERIC"</tt>.
 </p>
 
+<pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>;
+</pre>
 
+<p>
+<del><i>Returns:</i> A reference</del> <ins><tt>system_category</tt> shall point</ins>
+to <del>an</del> <ins>a statically
+initialized</ins> object of a type derived from class <tt>error_category</tt>.
+</p>
 
+<p>
+<del><i>Remarks:</i></del>  The object's <tt>equivalent</tt> virtual functions shall behave as
+specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
+shall return a pointer to the string <tt>"system"</tt>. The object's
+<tt>default_error_condition</tt> virtual function shall behave as follows:
+</p>
 
-
-<hr>
-<h3><a name="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3>
-<p><b>Section:</b> 20.6.12.2 [util.smartptr.shared] <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>Date:</b> 2008-02-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#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-Several places in 20.6.12.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>.
-However, that term is nowhere defined. The closest thing we have to a
-definition is that the default constructor creates an empty <tt>shared_ptr</tt>
-and that a copy of a default-constructed <tt>shared_ptr</tt> is empty. Are any
-other <tt>shared_ptr</tt>s empty? For example, is <tt>shared_ptr((T*) 0)</tt> empty? What
-are the properties of an empty <tt>shared_ptr</tt>? We should either clarify this
-term or stop using it.
-</p><p>
+If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function
+shall return <tt>error_condition(posv, generic_category)</tt>. Otherwise, the
+function shall return <tt>error_condition(ev, system_category)</tt>. What
+constitutes correspondence for any given operating system is
+unspecified. [<i>Note:</i> The number of potential system error codes is large
+and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value.
+Thus implementations are given latitude in determining correspondence.
+<i>-- end note</i>]
 </p>
-One reason it's not good enough to leave this term up to the reader's
-intuition is that, in light of
-<a href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2007/n2351.htm">N2351</a>
-and issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, most readers'
-intuitive understanding is likely to be wrong. Intuitively one might
-expect that an empty <tt>shared_ptr</tt> is one that doesn't store a pointer,
-but, whatever the definition is, that isn't it.
+</blockquote>
 
+<p>
+Change 19.4.2.1 [syserr.errcode.overview] Class <tt>error_code</tt> overview as indicated:
+</p>
 
-<p><i>[
-Peter adds:
-]</i></p>
+<blockquote><pre>class error_code {
+public:
+  ...;
+  <ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+  ...
+  void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+  ...
+  const error_category<del>&amp;</del><ins>*</ins> category() const;
+  ...
+private:
+  int val_;                    // exposition only
+  const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
+</pre></blockquote>
 
+<p>
+Change 19.4.2.2 [syserr.errcode.constructors] Class <tt>error_code</tt> constructors as indicated:
+</p>
 
 <blockquote>
+<pre><ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+</pre>
 <p>
-Or, what is an "empty" <tt>shared_ptr</tt>?
+<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
 </p>
-
-<ul>
-<li>
 <p>
-Are any other <tt>shared_ptrs</tt> empty?
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
 </p>
 <p>
-Yes. Whether a given <tt>shared_ptr</tt> instance is empty or not is (*)
-completely specified by the last mutating operation on that instance.
-Give me an example and I'll tell you whether the <tt>shared_ptr</tt> is empty or
-not.
+<i>Throws:</i> Nothing.
 </p>
-<blockquote>
-(*) If it isn't, this is a legitimate defect.
 </blockquote>
-</li>
 
-<li>
-<p>
-For example, is <tt>shared_ptr((T*) 0)</tt> empty?
-</p>
 <p>
-No. If it were empty, it would have a <tt>use_count()</tt> of 0, whereas it is
-specified to have an <tt>use_count()</tt> of 1.
+Change 19.4.2.3 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers  as indicated:
 </p>
-</li>
 
-<li>
+<blockquote>
+<pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+</pre>
 <p>
-What are the properties of an empty <tt>shared_ptr</tt>?
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
 </p>
 <p>
-The properties of an empty <tt>shared_ptr</tt> can be derived from the
-specification. One example is that its destructor is a no-op. Another is
-that its <tt>use_count()</tt> returns 0. I can enumerate the full list if you
-really like.
+<i>Throws:</i> Nothing.
 </p>
-</li>
+</blockquote>
 
-<li>
 <p>
-We should either clarify this term or stop using it.
+Change 19.4.2.4 [syserr.errcode.observers] Class <tt>error_code</tt> observers  as indicated:
 </p>
+
+<blockquote>
+<pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
+</pre>
+
 <p>
-I don't agree with the imperative tone
+<i>Returns:</i> <tt>cat_</tt>.
 </p>
 <p>
-A clarification would be either a no-op - if it doesn't contradict the
-existing wording - or a big mistake if it does.
+<i>Throws:</i> Nothing.
 </p>
+</blockquote>
+
 <p>
-I agree that a clarification that is formally a no-op may add value.
+Change 19.4.3.1 [syserr.errcondition.overview] Class <tt>error_condition</tt> overview   as indicated:
 </p>
-</li>
 
-<li>
+<blockquote>
+<pre>class error_condition {
+public:
+  ...;
+  <ins>constexpr</ins> error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+  ...
+  void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+  ...
+  const error_category<del>&amp;</del><ins>*</ins> category() const;
+  ...
+private:
+  int val_;                    // exposition only
+  const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
+</pre>
+</blockquote>
+
 <p>
-However, that term is nowhere defined.
+Change 19.4.3.2 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated:
 </p>
+
+<blockquote>
+<pre><ins>constexpr</ins> error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+</pre>
 <p>
-Terms can be useful without a definition. Consider the following
-simplistic example. We have a type <tt>X</tt> with the following operations
-defined:
+<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
 </p>
-<blockquote><pre>X x;
-X x2(x);
-X f(X x);
-X g(X x1, X x2);
-</pre></blockquote>
 <p>
-A default-constructed value is green.<br>
-A copy has the same color as the original.<br>
-<tt>f(x)</tt> returns a red value if the argument is green, a green value otherwise.<br>
-<tt>g(x1,x2)</tt> returns a green value if the arguments are of the same color, a red value otherwise.
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
 </p>
-
 <p>
-Given these definitions, you can determine the color of every instance
-of type <tt>X</tt>, even if you have absolutely no idea what green and red mean.
+<i>Throws:</i> Nothing.
 </p>
+</blockquote>
 
 <p>
-Green and red are "nowhere defined" and completely defined at the same time.
+Change 19.4.3.3 [syserr.errcondition.modifiers] Class <tt>error_condition</tt> modifiers as indicated:
 </p>
-</li>
-</ul>
 
+<blockquote>
+<pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+</pre>
 <p>
-Alisdair's wording is fine.
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
 </p>
 </blockquote>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Append the following sentance to 20.6.12.2 [util.smartptr.shared]
+Change 19.4.3.4 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated:
 </p>
+
 <blockquote>
-The <code>shared_ptr</code> class template stores a pointer, usually obtained
-via <code>new</code>. <code>shared_ptr</code> implements semantics of
-shared ownership; the last remaining owner of the pointer is responsible for
-destroying the object, or otherwise releasing  the resources associated with
-the stored pointer. <ins>A <code>shared_ptr</code> object that does not own
-a pointer is said to be <i>empty</i>.</ins>
+<pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
+</pre>
+<p>
+<i>Returns:</i> <tt>cat_</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
 </blockquote>
 
+<p>
+Throughout 19.4 [syserr] System error support, change "<tt>category().</tt>"  to "<tt>category()-&gt;</tt>".
+Appears approximately six times.
+</p>
 
+<p>
+<i>[Partially Editorial]</i> In 19.4.4 [syserr.compare] Comparison operators,
+paragraphs 2 and 4, change "<tt>category.equivalent(</tt>"  to
+"<tt>category()-&gt;equivalent(</tt>".
+</p>
 
+<p>
+Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview as indicated:
+</p>
 
+<blockquote><pre>public:
+  system_error(error_code ec, const string&amp; what_arg);
+  system_error(error_code ec);
+  system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat,
+      const string&amp; what_arg);
+  system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat);
+</pre></blockquote>
 
-<hr>
-<h3><a name="814"></a>814. <tt>vector&lt;bool&gt;::swap(reference, reference)</tt> not defined</h3>
-<p><b>Section:</b> 23.2.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> Alisdair Meredith <b>Date:</b> 2008-03-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector.bool">active issues</a> in [vector.bool].</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>
-<tt>vector&lt;bool&gt;::swap(reference, reference)</tt> has no definition.
+Change 19.4.5.2 [syserr.syserr.members] Class system_error members as indicated:
 </p>
 
+<blockquote>
+<pre>system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat, const string&amp; what_arg);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
+<tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>.
+</p>
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
+<pre>system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
+</p>
 <p>
+<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
+<tt>strcmp(runtime_error::what(), "") == 0</tt>.
 </p>
+</blockquote>
+</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.5.15.2.4 [func.wrap.func.inv] <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>Date:</b> 2008-03-16</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="833"></a>833. Freestanding implementations header list needs review for C++0x</h3>
+<p><b>Section:</b> 17.4.1.3 [compliance] <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>Date:</b> 2008-05-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>
 <p>
-<tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as
-described in the rvalue core proposal.
+Once the C++0x standard library is feature complete, the LWG needs to
+review 17.4.1.3 [compliance] Freestanding implementations header list to
+ensure it reflects LWG consensus.
 </p>
 
 
 <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.5.11.1.3 [func.bind.bind] <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>Date:</b> 2008-02-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#New">New</a> status.</p>
+<h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3>
+<p><b>Section:</b> 20.7.11.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>Date:</b> 2008-05-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>
 <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.
+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-active.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>
-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.)
+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>
+
+<ol>
+<li>Operational fail-safety.</li>
+<li>(Well-)Definedness of expressions.</li>
+</ol>
+
 <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?
+<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-active.html#762">762</a>).
 </p>
 
 <p><i>[
-Howard adds:
+Sophia Antipolis:
 ]</i></p>
 
 
 <blockquote>
-<tt>tuple</tt> construction should probably have a similar guarantee.
+<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>.
+</p>
+<p>
+Howard will go through and enumerate the individual requirements wrt. <tt>pointer</tt> for each member function.
+</p>
 </blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
+Add the following sentence just at the end of the newly proposed
+20.7.11.2 [unique.ptr.single]/p. 3:
 </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>
+
 
 
 
 
 <hr>
-<h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3>
-<p><b>Section:</b> 20.5.11.1.3 [func.bind.bind] <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>Date:</b> 2008-03-17</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>
+<h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3>
+<p><b>Section:</b> 27.4.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> Martin Sebor <b>Date:</b> 2008-05-17</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>
-<p>
-The functor retureed 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><b>Proposed resolution:</b></p>
-<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>
 
-<hr>
-<h3><a name="818"></a>818. wording for memory ordering</h3>
-<p><b>Section:</b> 29.1 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-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>
-29.1 [atomics.order] p1 says in the table that
-</p>
+       </p>
+       <blockquote>
+           <pre>#include &lt;iostream&gt;
 
-<blockquote>
-<table border="1">
-<tbody><tr>
-<th>Element</th><th>Meaning</th>
-</tr>
-<tr>
-<td><tt>memory_order_acq_rel</tt></td>
-<td>the operation has both acquire and release semantics</td>
-</tr>
-</tbody></table>
+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>
+   
+   <p><b>Proposed resolution:</b></p>
+       <p>
+
+I think an easy way to plug the first hole is to add a requires clause
+to <code>ostream::tie(ostream *tiestr)</code> requiring the this
+pointer not be equal to any pointer on the list starting
+with <code>tiestr-&gt;tie()</code>
+through <code>tiestr()-&gt;tie()-&gt;tie()</code> and so on. I am not
+proposing that we require implementations to traverse this list,
+although I think we could since the list is unlikely to be very long.
+
+       </p>
+       <p>
+
+Add a <i>Requires</i> clause to 27.4.4.2 [basic.ios.members] withethe following
+text:
+
+       </p>
+       <blockquote>
+
+<i>Requires:</i> If <code>(tiestr != 0)</code> is
+true, <code>tiestr</code> must not be reachable by traversing the
+linked list of tied stream objects starting
+from <code>tiestr-&gt;tie()</code>.
+
+       </blockquote>
+       <p>
+
+In addition, to prevent the infinite recursion that Bo writes about in
+his comp.lang.c++.moderated post, I propose to change
+27.6.2.4 [ostream::sentry], p2 like so:
+
+       </p>
+       <blockquote>
+
+If <code>((os.flags() &amp; ios_base::unitbuf) &amp;&amp;
+!uncaught_exception())</code> is true,
+calls <del>os.flush()</del> <ins><code>os.rdbuf()-&gt;pubsync()</code></ins>.
+
+       </blockquote>
+   
+
+
+
+<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.2.6.1.2 [locale.money.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> Martin Sebor <b>Date:</b> 2008-05-17</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#New">New</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a></p>
+<p><b>Discussion:</b></p>
+       <p>
+
+In paragraph 2, 22.2.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>
+   
+
+   <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.2.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. In either case, any required followed by all optional white
+space (as recognized by <code>ct.is()</code>) is consumed.</ins>
+If <code>(str.flags() &amp; str.showbase)</code> is <code>false</code>, ...
+
+       </blockquote>
+   
+
+
+
+<hr>
+<h3><a name="837"></a>837. 
+   <code>basic_ios::copyfmt()</code> overly loosely specified
+ </h3>
+<p><b>Section:</b> 27.4.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> Martin Sebor <b>Date:</b> 2008-05-17</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>
+   <p>
+
+The <code>basic_ios::copyfmt()</code> member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects:
+
+   </p>
+   <blockquote>
+
+<i>Effects</i>: If <code>(this == &amp;rhs)</code> does
+nothing. Otherwise assigns to the member objects of <code>*this</code>
+the corresponding member objects of <code>rhs</code>, except that
+
+     <ul>
+       <li>
+
+<code>rdstate()</code> and <code>rdbuf()</code> are left unchanged;
+
+       </li>
+       <li>
+
+<code>exceptions()</code> is altered last by
+calling <code>exceptions(rhs.except)</code>
+
+       </li>
+       <li>
+
+the contents of arrays pointed at by <code>pword</code>
+and <code>iword</code> are copied not the pointers themselves
+
+       </li>
+     </ul>
+   </blockquote>
+   <p>
+
+Since the rest of the text doesn't specify what the member objects
+of <code>basic_ios</code> are this seems a little too loose.
+
+   </p>
+ 
+
+ <p><b>Proposed resolution:</b></p>
+   <p>
+
+I propose to tighten things up by adding a <i>Postcondition</i> clause
+to the function like so:
+
+   </p>
+   <blockquote>
+     <i>Postconditions:</i>
+
+     <table border="1">
+       <thead>
+         <tr>
+           <th colspan="2"><code>copyfmt()</code> postconditions</th>
+         </tr>
+         <tr>
+           <th>Element</th>
+           <th>Value</th>
+         </tr>
+       </thead>
+       <tbody>
+         <tr>
+           <td><code>rdbuf()</code></td>
+           <td><i>unchanged</i></td>
+         </tr>
+         <tr> 
+           <td><code>tie()</code></td>
+           <td><code>rhs.tie()</code></td>
+         </tr>
+         <tr> 
+           <td><code>rdstate()</code></td>
+           <td><i>unchanged</i></td>
+         </tr>
+         <tr> 
+           <td><code>exceptions()</code></td>
+           <td><code>rhs.exceptions()</code></td>
+         </tr>
+         <tr> 
+           <td><code>flags()</code></td>
+           <td><code>rhs.flags()</code></td>
+         </tr>
+         <tr> 
+           <td><code>width()</code></td>
+           <td><code>rhs.width()</code></td>
+         </tr>
+         <tr> 
+           <td><code>precision()</code></td>
+           <td><code>rhs.precision()</code></td>
+         </tr>
+         <tr> 
+           <td><code>fill()</code></td>
+           <td><code>rhs.fill()</code></td>
+         </tr>
+         <tr> 
+           <td><code>getloc()</code></td>
+           <td><code>rhs.getloc()</code></td>
+         </tr>
+       </tbody>
+     </table>
+   </blockquote>
+   <p>
+
+The format of the table follows Table 117 (as
+of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2588.pdf">N2588</a>): <code>basic_ios::init()</code>
+effects.
+
+   </p>
+   <p>
+
+The intent of the new table is not to impose any new requirements or
+change existing ones, just to be more explicit about what I believe is
+already there.
+
+   </p>
+ 
+
+
+
+<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.5.1 [istream.iterator] <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>Date:</b> 2008-05-17</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#New">New</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.5.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#836">836</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><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.5.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>
+ 
+
+
+
+<hr>
+<h3><a name="839"></a>839. Maps and sets missing splice operation</h3>
+<p><b>Section:</b> 23.3 [associative], 23.4 [unord] <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>Date:</b> 2008-05-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>
+<p><b>Discussion:</b></p>
+<p>
+Splice is a very useful feature of <tt>list</tt>. This functionality is also very
+useful for any other node based container, and I frequently wish it were
+available for maps and sets. It seems like an omission that these
+containers lack this capability. Although the complexity for a splice is
+the same as for an insert, the actual time can be much less since the
+objects need not be reallocated and copied. When the element objects are
+heavy and the compare operations are fast (say a <tt>map&lt;int, huge_thingy&gt;</tt>)
+this can be a big win.
+</p>
+
+<p>
+<b>Suggested resolution:</b>
+</p>
+
+<p>
+Add the following signatures to map, set, multimap, multiset, and the unordered associative containers:
+</p>
+<blockquote><pre> 
+void splice(list&lt;T,Allocator&gt;&amp;&amp; x);
+void splice(list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
+void splice(list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator first, const_iterator last);
+</pre></blockquote>
+
+<p>
+Hint versions of these are also useful to the extent hint is useful.
+(I'm looking for guidance about whether hints are in fact useful.)
+</p>
+ 
+<blockquote><pre> 
+void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x);
+void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
+void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator first, const_iterator last);
+</pre></blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Don't try to <tt>splice "list"</tt> into the other containers, it should be container-type.
+</p>
+<p>
+<tt>forward_list</tt> already has <tt>splice_after</tt>.
+</p>
+<p>
+Would "<tt>splice</tt>" make sense for an <tt>unordered_map</tt>?
+</p>
+<p>
+Jens, Robert: "<tt>splice</tt>" is not the right term, it implies maintaining ordering in <tt>list</tt>s.
+</p>
+<p>
+Howard: <tt>adopt</tt>?
+</p>
+<p>
+Jens: <tt>absorb</tt>?
+</p>
+<p>
+Alan: <tt>subsume</tt>?
+</p>
+<p>
+Robert: <tt>recycle</tt>?
+</p>
+<p>
+Howard: <tt>transfer</tt>? (but no direction)
+</p>
+<p>
+Jens: <tt>transfer_from</tt>. No.
+</p>
+<p>
+Alisdair: Can we give a nothrow guarantee? If your <tt>compare()</tt> and <tt>hash()</tt> doesn't throw, yes.
+</p>
+<p>
+Daniel: For <tt>unordered_map</tt>, we can't guarantee nothrow.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="841"></a>841. cstdint.syn inconsistent with C99</h3>
+<p><b>Section:</b> 18.3.1 [cstdint.syn] <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>Date:</b> 2008-05-17</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</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 specifying the names of macros and types defined in
+header <code>&lt;stdint.h&gt;</code>, C99 makes use of the
+symbol <code><i>N</i></code> to accommodate unusual platforms with
+word sizes that aren't powers of two. C99
+permits <code><i>N</i></code> to take on any positive integer value
+(including, for example, 24).
+
+   </p>
+   <p>
+
+In  cstdint.syn Header <code>&lt;cstdint&gt;</code>
+synopsis, C++ on the other hand, fixes the value
+of <code><i>N</i></code> to 8, 16, 32, and 64, and specifies only
+types with these exact widths. 
+
+   </p>
+   <p>
+   </p>
+
+In addition, paragraph 1 of the same section makes use of a rather
+informal shorthand notation to specify sets of macros. When
+interpreted strictly, the notation specifies macros such
+as <code>INT_8_MIN</code> that are not intended to be specified.
+
+   <p>
+
+Finally, the section is missing the usual table of symbols defined
+in that header, making it inconsistent with the rest of the
+specification.
+
+   </p>
+ 
+ <p><b>Proposed resolution:</b></p>
+   <p>
+
+I propose to use the same approach in the C++ spec as C99 uses, that
+is, to specify the header synopsis in terms of "exposition only" types
+that make use of the symbol <code><i>N</i></code> to denote one or
+more of a theoretically unbounded set of widths.
+
+   </p>
+   <p>
+
+Further, I propose to add a new table to section listing the symbols
+defined in the header using a more formal notation that avoids
+introducing inconsistencies.
+
+   </p>
+   <p>
+
+To this effect, in  cstdint.syn
+Header <code>&lt;cstdint&gt;</code> synopsis, replace both the
+synopsis and paragraph 1 with the following text:
+
+   </p>
+   <blockquote>
+     <p>
+       </p><ol>
+         <li>
+
+In the names defined in the <code>&lt;cstdint&gt;</code> header, the
+symbol <code><i>N</i></code> represents a positive decimal integer
+with no leading zeros (e.g., 8 or 24, but not 0, 04, or 048). With the
+exception of exact-width types, macros and types for values
+of <code><i>N</i></code> in the set of 8, 16, 32, and 64 are
+required. Exact-width types, and any macros and types for values
+of <code><i>N</i></code> other than 8, 16, 32, and 64 are
+optional. However, if an implementation provides integer types with
+widths of 8, 16, 32, or 64 bits, the corresponding exact-width types
+and macros are required.
+
+         </li>
+       </ol>
+     
+     <pre>namespace std {
+
+   // required types
+
+   // Fastest minimum-width integer types
+   typedef <i>signed integer type</i>   int_fast8_t;
+   typedef <i>signed integer type</i>   int_fast16_t;
+   typedef <i>signed integer type</i>   int_fast32_t;
+   typedef <i>signed integer type</i>   int_fast64_t;
+
+   typedef <i>unsigned integer type</i> uint_fast8_t;
+   typedef <i>unsigned integer type</i> uint_fast16_t;
+   typedef <i>unsigned integer type</i> uint_fast32_t;
+   typedef <i>unsigned integer type</i> uint_fast64_t;
+
+   // Minimum-width integer types
+   typedef <i>signed integer type</i>   int_least8_t;
+   typedef <i>signed integer type</i>   int_least16_t;
+   typedef <i>signed integer type</i>   int_least32_t;
+   typedef <i>signed integer type</i>   int_least64_t;
+
+   typedef <i>unsigned integer type</i> uint_least8_t;
+   typedef <i>unsigned integer type</i> uint_least16_t;
+   typedef <i>unsigned integer type</i> uint_least32_t;
+   typedef <i>unsigned integer type</i> uint_least64_t;
+
+   // Greatest-width integer types
+   typedef <i>signed integer type</i>   intmax_t;
+   typedef <i>unsigned integer type</i> uintmax_t;
+
+   // optionally defined types
+
+   // Exact-width integer types
+   typedef <i>signed integer type</i>   int<i>N</i>_t;
+   typedef <i>unsigned integer type</i> uint<i>N</i>_t;
+
+   // Fastest minimum-width integer types for values
+   // of <i>N</i> other than 8, 16, 32, and 64
+   typedef <i>signed integer type</i>   uint_fast<i>N</i>_t;
+   typedef <i>unsigned integer type</i> uint_fast<i>N</i>_t;
+
+   // Minimum-width integer types for values
+   // of <i>N</i> other than 8, 16, 32, and 64
+   typedef <i>signed integer type</i>   uint_least<i>N</i>_t;
+   typedef <i>unsigned integer type</i> uint_least<i>N</i>_t;
+
+   // Integer types capable of holding object pointers
+   typedef <i>signed integer type</i>   intptr_t;
+   typedef <i>signed integer type</i>   intptr_t;
+
+}</pre>
+   </blockquote>
+   <p>
+
+[Note to editor: Remove all of the existing paragraph 1 from  cstdint.syn.]
+
+   </p>
+   <blockquote>
+     Table ??: Header <code>&lt;cstdint&gt;</code> synopsis
+     <table border="1">
+       <thead>
+         <tr>
+           <th>Type</th>
+           <th colspan="3">Name(s)</th>
+         </tr>
+       </thead>
+       <tbody>
+         <tr>
+           <td rowspan="11"><b>Macros:</b></td>
+           <td><tt>INT<i>N</i>_MIN</tt></td>
+           <td><tt>INT<i>N</i>_MAX</tt></td>
+           <td><tt>UINT<i>N</i>_MAX</tt></td>
+         </tr>
+         <tr>
+           <td><tt>INT_FAST<i>N</i>_MIN</tt></td>
+           <td><tt>INT_FAST<i>N</i>_MAX</tt></td>
+           <td><tt>UINT_FAST<i>N</i>_MAX</tt></td>
+         </tr>
+         <tr>
+           <td><tt>INT_LEAST<i>N</i>_MIN</tt></td>
+           <td><tt>INT_LEAST<i>N</i>_MAX</tt></td>
+           <td><tt>UINT_LEAST<i>N</i>_MAX</tt></td>
+         </tr>
+         <tr>
+           <td><tt>INTPTR_MIN</tt></td>
+           <td><tt>INTPTR_MAX</tt></td>
+           <td><tt>UINTPTR_MAX</tt></td>
+         </tr>
+         <tr>
+           <td><tt>INTMAX_MIN</tt></td>
+           <td><tt>INTMAX_MAX</tt></td>
+           <td><tt>UINTMAX_MAX</tt></td>
+         </tr>
+         <tr>
+           <td><tt>PTRDIFF_MIN</tt></td>
+           <td><tt>PTRDIFF_MAX</tt></td>
+           <td><tt>PTRDIFF_MAX</tt></td>
+         </tr>
+         <tr>
+           <td><tt>SIG_ATOMIC_MIN</tt></td>
+           <td><tt>SIG_ATOMIC_MAX</tt></td>
+           <td><tt>SIZE_MAX</tt></td>
+         </tr>
+         <tr>
+           <td><tt>WCHAR_MIN</tt></td>
+           <td><tt>WCHAR_MAX</tt></td>
+         <td></td>
+         </tr>
+         <tr>
+           <td><tt>WINT_MIN</tt></td>
+           <td><tt>WINT_MAX</tt></td>
+           <td></td>
+         </tr>
+         <tr>
+           <td><tt>INT<i>N</i>_C()</tt></td>
+           <td><tt>UINT<i>N</i>_C()</tt></td>
+           <td></td>
+         </tr>
+         <tr>
+           <td><tt>INTMAX_C()</tt></td>
+           <td><tt>UINTMAX_C()</tt></td>
+           <td></td>
+         </tr>
+         <tr>
+           <td rowspan="5"><b>Types:</b></td>
+           <td><tt>int<i>N</i>_t</tt></td>
+           <td><tt>uint<i>N</i>_t</tt></td>
+           <td></td>
+         </tr>
+         <tr>
+           <td><tt>int_fast<i>N</i>_t</tt></td>
+           <td><tt>uint_fast<i>N</i>_t</tt></td>
+           <td></td>
+         </tr>
+         <tr>
+           <td><tt>int_least<i>N</i>_t</tt></td>
+           <td><tt>uint_least<i>N</i>_t</tt></td>
+           <td></td>
+         </tr>
+         <tr>
+           <td><tt>intptr_t</tt></td>
+           <td><tt>uintptr_t</tt></td>
+           <td></td>
+         </tr>
+         <tr>
+           <td><tt>intmax_t</tt></td>
+           <td><tt>uintmax_t</tt></td>
+           <td></td>
+         </tr>
+       </tbody>
+     </table>
+   </blockquote>
+ 
+
+
+
+
+<hr>
+<h3><a name="842"></a>842. ConstructibleAsElement and bit containers</h3>
+<p><b>Section:</b> 23.1 [container.requirements], 23.2.7 [vector.bool], 23.3.5 [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> Howard Hinnant <b>Date:</b> 2008-06-03</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#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+23.1 [container.requirements]/p3 says:
+</p>
+
+<blockquote>
+Objects stored in these components shall be constructed using
+<tt>construct_element</tt> (20.6.9). For each operation that inserts an
+element of type <tt>T</tt> into a container (<tt>insert</tt>,
+<tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
+arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
+as described in table 88. [<i>Note:</i> If the component is instantiated
+with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
+<tt>is_scoped_allocator&lt;A&gt;::value</tt> is <tt>true</tt>), then
+<tt>construct_element</tt> may pass an inner allocator argument to
+<tt>T</tt>'s constructor. <i>-- end note</i>]
+</blockquote>
+
+<p>
+However <tt>vector&lt;bool, A&gt;</tt> (23.2.7 [vector.bool]) and <tt>bitset&lt;N&gt;</tt> 
+(23.3.5 [template.bitset]) store bits, not <tt>bool</tt>s, and <tt>bitset&lt;N&gt;</tt>
+does not even have an allocator.  But these containers are governed by this clause.  Clearly this
+is not implementable.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 23.1 [container.requirements]/p3:
+</p>
+
+<blockquote>
+Objects stored in these components shall be constructed using
+<tt>construct_element</tt> (20.6.9)<ins>, unless otherwise specified</ins>.
+For each operation that inserts an
+element of type <tt>T</tt> into a container (<tt>insert</tt>,
+<tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
+arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
+as described in table 88. [<i>Note:</i> If the component is instantiated
+with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
+<tt>is_scoped_allocator&lt;A&gt;::value</tt> is <tt>true</tt>), then
+<tt>construct_element</tt> may pass an inner allocator argument to
+<tt>T</tt>'s constructor. <i>-- end note</i>]
+</blockquote>
+
+<p>
+Change 23.2.7 [vector.bool]/p2:
+</p>
+
+<blockquote>
+Unless described below, all operations have the same requirements and semantics as the primary <tt>vector</tt> template, 
+except that operations dealing with the <tt>bool</tt> value type map to bit values in the container storage<ins>,
+and <tt>construct_element</tt> (23.1 [container.requirements]) is not used to construct these values</ins>.
+</blockquote>
+
+<p>
+Move 23.3.5 [template.bitset] to clause 20.
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="843"></a>843.  Reference Closure</h3>
+<p><b>Section:</b> 20.6.17.1 [func.referenceclosure.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-06-02</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>std::reference_closure</tt> type has a deleted copy assignment operator
+under the theory that references cannot be assigned, and hence the
+assignment of its reference member must necessarily be ill-formed.
+</p>
+<p>
+However, other types, notably <tt>std::reference_wrapper</tt> and <tt>std::function</tt>
+provide for the "copying of references", and thus the current definition
+of <tt>std::reference_closure</tt> seems unnecessarily restrictive.  In particular,
+it should be possible to write generic functions using both <tt>std::function</tt>
+and <tt>std::reference_closure</tt>, but this generality is much harder when
+one such type does not support assignment.
+</p>
+<p>
+The definition of <tt>reference_closure</tt> does not necessarily imply direct
+implementation via reference types.  Indeed, the <tt>reference_closure</tt> is
+best implemented via a frame pointer, for which there is no standard
+type.
+</p>
+<p>
+The semantics of assignment are effectively obtained by use of the
+default destructor and default copy assignment operator via
+</p>
+
+<blockquote><pre>x.~reference_closure(); new (x) reference_closure(y);
+</pre></blockquote>
+
+<p>
+So the copy assignment operator generates no significant real burden
+to the implementation.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.6.17 [func.referenceclosure] Class template reference_closure,
+replace the <tt>=delete</tt> in the copy assignment operator in the synopsis
+with <tt>=default</tt>.
+</p>
+
+<blockquote><pre>template&lt;class R , class... ArgTypes &gt; 
+  class reference_closure&lt;R (ArgTypes...)&gt; { 
+  public:
+     ...
+     reference_closure&amp; operator=(const reference_closure&amp;) = <del>delete</del> <ins>default</ins>;
+     ...
+</pre></blockquote>
+
+<p>
+In 20.6.17.1 [func.referenceclosure.cons] Construct, copy, destroy,
+add the member function description
+</p>
+
+<blockquote>
+<pre>reference_closure&amp; operator=(const reference_closure&amp; f)
+</pre>
+<blockquote>
+<p>
+<i>Postcondition:</i> <tt>*this</tt> is a copy of <tt>f</tt>.
+</p>
+<p>
+<i>Returns:</i> <tt>*this</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="844"></a>844. <tt>complex pow</tt> return type is ambiguous</h3>
+<p><b>Section:</b> 26.3.9 [cmplx.over] <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>Date:</b> 2008-06-03</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 current working draft is in an inconsistent state.
+</p>
+
+<p>
+26.3.8 [complex.transcendentals] says that:
+</p>
+
+<blockquote>
+<tt>pow(complex&lt;float&gt;(), int())</tt> returns a <tt>complex&lt;float&gt;</tt>.
+</blockquote>
+
+<p>
+26.3.9 [cmplx.over] says that:
+</p>
+
+<blockquote>
+<tt>pow(complex&lt;float&gt;(), int())</tt> returns a <tt>complex&lt;double&gt;</tt>.
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Since <tt>int</tt> promotes to <tt>double</tt>, and C99 doesn't have an <tt>int</tt>-based
+overload for <tt>pow</tt>, the C99 result is <tt>complex&lt;double&gt;</tt>, see also C99
+7.22, see also library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>.
+</p>
+<p>
+Special note: ask P.J. Plauger.
+</p>
+<blockquote>
+Looks fine.
+</blockquote>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Strike this <tt>pow</tt> overload in 26.3.1 [complex.synopsis] and in 26.3.8 [complex.transcendentals]:
+</p>
+
+<blockquote><pre><del>template&lt;class T&gt; complex&lt;T&gt; pow(const complex&lt;T&gt;&amp; x, int y);</del>
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="845"></a>845. atomics cannot support aggregate initialization</h3>
+<p><b>Section:</b> 29.3 [atomics.types] <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>Date:</b> 2008-06-03</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types">active issues</a> in [atomics.types].</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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The atomic classes (and class templates) are required to support aggregate
+initialization (29.3.1 [atomics.types.integral]p2 / 29.3.2 [atomics.types.address]p1)
+yet also have user declared constructors, so cannot be aggregates.
+</p>
+<p>
+This problem might be solved with the introduction of the proposed
+initialization syntax at Antipolis, but the wording above should be altered.
+Either strike the sentence as redundant with new syntax, or refer to 'brace
+initialization'.
+</p>
+
+<p><i>[
+Jens adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+Note that
+</p>
+<blockquote><pre>atomic_itype a1 = { 5 };
+</pre></blockquote>
+<p>
+would be aggregate-initialization syntax (now coming under the disguise
+of brace initialization), but would be ill-formed, because the corresponding
+constructor for atomic_itype is explicit.  This works, though:
+</p>
+<blockquote><pre>atomic_itype a2 { 6 };
+</pre></blockquote>
+
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 29.3.1 [atomics.types.integral], strike the following sentence from paragraph 2:
+</p>
+
+<blockquote>
+The atomic integral types shall have standard layout. They shall each have a trivial default constructor, a constexpr 
+explicit value constructor, a deleted copy constructor, a deleted copy assignment operator, and a trivial destructor.
+<del>They shall each support aggregate initialization syntax.</del>
+</blockquote>
+
+<p><i>[
+2008-08-18, Lawrence adds:
+]</i></p>
+
+<blockquote>
+The syntactic compatibility of initialization with C is important.
+I suggest a different resolution; remove the explicit from the
+constructor.  For the same reasons we can have implicit conversions,
+we can also have implicit constructors.
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="846"></a>846. No definition for constructor</h3>
+<p><b>Section:</b> 29.3 [atomics.types] <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>Date:</b> 2008-06-03</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types">active issues</a> in [atomics.types].</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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The atomic classes and class templates (29.3.1 [atomics.types.integral] /
+29.3.2 [atomics.types.address]) have a constexpr
+constructor taking a value of the appropriate type for that atomic.
+However, neither clause provides semantics or a definition for this
+constructor.  I'm not sure if the initialization is implied by use of
+constexpr keyword (which restricts the form of a constructor) but even if
+that is the case, I think it is worth spelling out explicitly as the
+inference would be far too subtle in that case.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="847"></a>847. string exception safety guarantees</h3>
+<p><b>Section:</b> 21.3.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Hervé Brönnimann <b>Date:</b> 2008-06-05</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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<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.3 [basic.string], para 3:
+</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).
+</blockquote>
+
+<p>
+However, the chapter 23 only says, on the topic of exceptions:  23.1 [container.requirements],
+para 10:
+</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>
+</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-active.html#718">718</a> proposes to remove 23.1 [container.requirements], para 3.
+</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.
+</p>
+
+<p>
+The reaction in that group by Niels Dekker, Martin Sebor, and
+Bo Persson, was all that this would be worth an LWG issue.
+</p>
+
+<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.1 [container.requirements], para 1
+applies here).
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a blanket statement in 21.3.1 [string.require]:
+</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>
+</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.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="848"></a>848. missing <tt>std::hash</tt> specializations for <tt>std::bitset/std::vector&lt;bool&gt;</tt></h3>
+<p><b>Section:</b> 20.6.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> Thorsten Ottosen <b>Date:</b> 2008-06-05</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 the current working draft, <tt>std::hash&lt;T&gt;</tt> is specialized for builtin
+types and a few other types. Bitsets seems like one that is missing from
+the list, not because it cannot not be done by the user, but because it
+is hard or impossible to write an efficient implementation that works on
+32bit/64bit chunks at a time. For example, <tt>std::bitset</tt> is too much
+encapsulated in this respect.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following to the synopsis in 20.6 [function.objects]/2:
+</p>
+
+<blockquote><pre>template&lt;class Allocator&gt; struct hash&lt;std::vector&lt;bool,Allocator&gt;&gt;;
+template&lt;size_t N&gt; struct hash&lt;std::bitset&lt;N&gt;&gt;;
+</pre></blockquote>
+
+<p>
+Modify the last sentence of 20.6.16 [unord.hash]/1 to end with:
+</p>
+
+<blockquote>
+... and <tt>std::string</tt>, <tt>std::u16string</tt>, <tt>std::u32string</tt>, <tt>std::wstring</tt>,
+<tt>std::error_code</tt>, <tt>std::thread::id</tt>, <tt>std::bitset</tt>, <tt>and std::vector&lt;bool&gt;</tt>.
 </blockquote>
 
+
+
+
+
+
+<hr>
+<h3><a name="849"></a>849. missing type traits to compute root class and derived class of types in a class hierachy</h3>
+<p><b>Section:</b> 20.5.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> Thorsten Ottosen <b>Date:</b> 2008-06-05</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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The type traits library contains various traits to dealt with
+polymorphic types, e.g. <tt>std::has_virtual_destructor</tt>, <tt>std::is_polymorphic</tt>
+and <tt>std::is_base_of</tt>. However, there is no way to compute the unique
+public base class of a type  if such  one exists.  Such a trait could be
+very useful if one needs to instantiate a specialization made for the
+root class whenever a derived class is passed as parameter. For example,
+imagine that you wanted to specialize <tt>std::hash</tt> for a class
+hierarchy---instead of specializing each class, you could specialize the
+<tt>std::hash&lt;root_class&gt;</tt> and provide a partial specialization that worked
+for all derived classes.
+</p>
+
 <p>
-To my naked eye, that seems to imply that even an atomic read has both
-acquire and release semantics.
+This ability---to specify operations in terms of their equivalent in the
+root class---can be done with e.g. normal functions, but there is,
+AFAIK, no way to do it for class templates. Being able to access
+compile-time information about the type-hierachy can be very powerful,
+and I therefore also suggest traits that computes the directly derived
+class whenever that is possible.
 </p>
 
 <p>
-Then, p1 says in the table:
+If the computation can not be done, the traits should fall back on an
+identity transformation. I expect this gives the best overall usability.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following to the synopsis in 20.5.2 [meta.type.synop] under "other transformations":
+</p>
+
+<blockquote><pre>template&lt; class T &gt; struct direct_base_class;
+template&lt; class T &gt; struct direct_derived_class;
+template&lt; class T &gt; struct root_base_class;
+</pre></blockquote>
+
+<p>
+Add three new entries to table 51 (20.5.7 [meta.trans.other]) with the following content
 </p>
 
 <blockquote>
 <table border="1">
 <tbody><tr>
-<th>Element</th><th>Meaning</th>
+<th>Template</th><th>Condition</th><th>Comments</th>
 </tr>
 <tr>
-<td><tt>memory_order_seq_cst</tt></td>
-<td>the operation has both acquire and release semantics,
-    and, in addition, has sequentially-consistent operation ordering</td>
+<td><tt>template&lt; class T &gt; struct direct_base_class;</tt></td>
+<td><tt>T</tt> shall be a complete type.</td>
+<td>The member typedef <tt>type</tt> shall equal the accessible unambiguous direct base class of <tt>T</tt>.
+If no such type exists, the member typedef <tt>type</tt> shall equal <tt>T</tt>.</td>
+</tr>
+<tr>
+<td><tt>template&lt; class T &gt; struct direct_derived_class;</tt></td>
+<td><tt>T</tt> shall be a complete type.</td>
+<td>The member typedef <tt>type</tt> shall equal the unambiguous type which has <tt>T</tt>
+as an accessible unambiguous direct base class. If no such type exists, the member typedef
+<tt>type</tt> shall equal <tt>T</tt>.</td>
+</tr>
+<tr>
+<td><tt>template&lt; class T &gt; struct root_base_class;</tt></td>
+<td><tt>T</tt> shall be a complete type.</td>
+<td>The member typedef <tt>type</tt> shall equal the accessible unambiguous most indirect base class of
+<tt>T</tt>. If no such type exists, the member typedef type shall equal <tt>T</tt>.</td>
 </tr>
 </tbody></table>
 </blockquote>
 
+
+
+
+
+
+<hr>
+<h3><a name="850"></a>850. Should <tt>shrink_to_fit</tt> apply to <tt>std::deque</tt>?</h3>
+<p><b>Section:</b> 23.2.2.2 [deque.capacity] <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>Date:</b> 2008-06-05</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#deque.capacity">active issues</a> in [deque.capacity].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</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>
-So that seems to be "the same thing" as <tt>memory_order_acq_rel</tt>, with additional
-constraints.
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a> added a <tt>shrink_to_fit</tt> function to <tt>std::vector</tt> and <tt>std::string</tt>.
+It did not yet deal with <tt>std::deque</tt>, because of the fundamental
+difference between <tt>std::deque</tt> and the other two container types. The
+need for <tt>std::deque</tt> may seem less evident, because one might think that
+for this container, the overhead is a small map, and some number of
+blocks that's bounded by a small constant.
+</p>
+<p>
+The container overhead can in fact be arbitrarily large (i.e. is not
+necessarily O(N) where N is the number of elements currently held by the
+<tt>deque</tt>).  As Bill Plauger noted in a reflector message, unless the map of
+block pointers is shrunk, it must hold at least maxN/B pointers where
+maxN is the maximum of N over the lifetime of the <tt>deque</tt> since its
+creation.  This is independent of how the map is implemented
+(<tt>vector</tt>-like circular buffer and all), and maxN bears no relation to N,
+the number of elements it currently holds.
+</p>
+<p>
+Hervé Brönnimann reports a situation where a <tt>deque</tt> of requests grew very
+large due to some temporary backup (the front request hanging), and the
+map of the <tt>deque</tt> grew quite large before getting back to normal.  Just
+to put some color on it, assuming a <tt>deque</tt> with 1K pointer elements in
+steady regime, that held, at some point in its lifetime, maxN=10M
+pointers, with one block holding 128 elements, the spine must be at
+least (maxN / 128), in that case 100K.   In that case, shrink-to-fit
+would allow to reuse about 100K which would otherwise never be reclaimed
+in the lifetime of the <tt>deque</tt>.
+</p>
+<p>
+An added bonus would be that it *allows* implementations to hang on to
+empty blocks at the end (but does not care if they do or not).  A
+<tt>shrink_to_fit</tt> would take care of both shrinks, and guarantee that at
+most O(B) space is used in addition to the storage to hold the N
+elements and the N/B block pointers.
 </p>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-I'm then reading p2, where it says:
+To Class template deque 23.2.2 [deque] synopsis, add:
+</p>
+<blockquote><pre>void shrink_to_fit();
+</pre></blockquote>
+
+<p>
+To deque capacity 23.2.2.2 [deque.capacity], add:
 </p>
+<blockquote><pre>void shrink_to_fit();
+</pre>
 
 <blockquote>
-The <tt>memory_order_seq_cst</tt> operations that load a value are acquire operations
-on the affected locations. The <tt>memory_order_seq_cst</tt> operations that store a value
-are release operations on the affected locations.
+<i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce memory
+use. [<i>Note:</i> The request is non-binding to allow latitude for
+implementation-specific optimizations. -- <i>end note</i>]
+</blockquote>
 </blockquote>
 
+
+
+
+
+<hr>
+<h3><a name="851"></a>851. simplified array construction</h3>
+<p><b>Section:</b> 23.2.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> Benjamin Kosnik <b>Date:</b> 2008-06-05</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>
+This is an issue that came up on the libstdc++ list, where a
+discrepency between "C" arrays and C++0x's <tt>std::array</tt> was pointed
+out.
+</p>
+
 <p>
-That seems to imply that atomic reads only have acquire semantics.  If that
-is intended, does this also apply to <tt>memory_order_acq_rel</tt> and the individual
-load/store operations as well?
+In "C," this array usage is possible:
+</p>
+
+<blockquote><pre>int ar[] = {1, 4, 6};
+</pre></blockquote>
+
+<p>
+But for C++, 
+</p>
+
+<blockquote><pre>std::array&lt;int&gt; a = { 1, 4, 6 }; // error
+</pre></blockquote>
+
+<p>
+Instead, the second parameter of the <tt>array</tt> template must be
+explicit, like so:
+</p>
+
+<blockquote><pre>std::array&lt;int, 3&gt; a = { 1, 4, 6 };
+</pre></blockquote>
+
+<p>
+Doug Gregor proposes the following solution, that assumes
+generalized initializer lists.
+</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>
+
+<p>
+Then, the way to build an <tt>array</tt> from a list of unknown size is:
+</p>
+
+<blockquote><pre>auto a = make_array&lt;T&gt;(1, 4, 6);
+</pre></blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to the <tt>array</tt> synopis in 23.2 [sequences]:
+</p>
+
+<blockquote><pre>template&lt;typename T, typename... Args&gt;
+  requires Convertible&lt;Args, T&gt;...
+  array&lt;T, sizeof...(Args)&gt; 
+  make_array(Args&amp;&amp;... args);
+</pre></blockquote>
+
+<p>
+Append after 23.2.1.6 [array.tuple] Tuple interface to class template <tt>array</tt> the
+following new section.
+</p>
+
+<blockquote>
+<p>
+23.2.1.7 Convenience interface to class template <tt>array</tt> [array.tuple]
+</p>
+
+<pre>template&lt;typename T, typename... Args&gt;
+  requires Convertible&lt;Args, T&gt;...
+  array&lt;T, sizeof...(Args)&gt; 
+  make_array(Args&amp;&amp;... args);
+</pre>
+
+<blockquote>
+<p>
+<i>Returns:</i> <tt>{std::forward&lt;Args&gt;(args)...}</tt>
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="852"></a>852. unordered containers <tt>begin(n)</tt> mistakenly <tt>const</tt></h3>
+<p><b>Section:</b> 23.4 [unord] <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>Date:</b> 2008-06-12</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</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#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In 3 of the four unordered containers the local <tt>begin</tt> member is mistakenly declared <tt>const</tt>:
+</p>
+
+<blockquote><pre>local_iterator begin(size_type n) const;
+</pre></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 23.4.1 [unord.map], 23.4.2 [unord.multimap], and 23.4.4 [unord.multiset]:
+</p>
+
+<blockquote><pre>local_iterator begin(size_type n)<del> const</del>;
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="853"></a>853. <tt>to_string</tt> needs updating with <tt>zero</tt> and <tt>one</tt></h3>
+<p><b>Section:</b> 23.3.5 [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> Howard Hinnant <b>Date:</b> 2008-06-18</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#396">396</a> adds defaulted arguments to the <tt>to_string</tt> member, but neglects to update
+the three newer <tt>to_string</tt> overloads.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 23.3.5 [template.bitset], and the signatures in 23.3.5.2 [bitset.members] to:
+</p>
+
+<blockquote><pre>template &lt;class charT, class traits&gt; 
+  basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt; to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const; 
+template &lt;class charT&gt; 
+  basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt; to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const; 
+basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt; to_string(<ins>char zero = '0', char one = '1'</ins>) const; 
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="854"></a>854. <tt>default_delete</tt> converting constructor underspecified</h3>
+<p><b>Section:</b> 20.7.11.1.1 [unique.ptr.dltr.dflt] <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>Date:</b> 2008-06-18</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>
+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>
+The requirements for <tt>unique_ptr</tt> conversions should be the same as those on the deleter.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.7.11.1.1 [unique.ptr.dltr.dflt]:
+</p>
+
+<blockquote><pre>namespace std { 
+  template &lt;class T&gt; struct default_delete { 
+    default_delete(); 
+    template &lt;class U&gt;
+      <ins>requires Convertible&lt;U*, T*&gt; &amp;&amp; HasVirtualDestructor&lt;T&gt;</ins>
+      default_delete(const default_delete&lt;U&gt;&amp;); 
+    void operator()(T*) const; 
+  }; 
+}
+</pre></blockquote>
+
+<p>
+...
+</p>
+
+<blockquote><pre>template &lt;class U&gt;
+  <ins>requires Convertible&lt;U*, T*&gt; &amp;&amp; HasVirtualDestructor&lt;T&gt;</ins>
+  default_delete(const default_delete&lt;U&gt;&amp; other);
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="855"></a>855. capacity() and reserve() for deque?</h3>
+<p><b>Section:</b> 23.2.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Hervé Brönnimann <b>Date:</b> 2008-06-11</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#deque.capacity">active issues</a> in [deque.capacity].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.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>
+The main point is that <tt>capacity</tt> can be viewed as a mechanism to  
+guarantee the validity of <tt>iterators</tt> when only <tt>push_back/pop_back</tt>
+operations are used.  For <tt>vector</tt>, this goes with reallocation.  For  
+<tt>deque</tt>, this is a bit more subtle:  <tt>capacity()</tt> of a <tt>deque</tt> may shrink,  
+whereas that of <tt>vector</tt> doesn't.   In a circular buffer impl. of the  
+map, as Howard did, there is very similar notion of capacity: as long  
+as <tt>size()</tt> is less than <tt>B * (</tt>total size of the map <tt>- 2)</tt>, it is  
+guaranteed that no <tt>iterator</tt> is invalidated after any number of  
+<tt>push_front/back</tt> and <tt>pop_front/back</tt> operations.  But this does not  
+hold for other implementations.
+</p>
+<p>
+Still, I believe, <tt>capacity()</tt> can be defined by <tt>size() +</tt>  how many  
+<tt>push_front/back</tt> minus <tt>pop_front/back</tt> that can be performed before  
+terators are invalidated.  In a classical impl., <tt>capacity() = size()
++ </tt> the min distance to either "physical" end of the deque (i.e.,  
+counting the empty space in the last block plus all the blocks until  
+the end of the map of block pointers).  In Howard's circular buffer  
+impl., <tt>capacity() = B * (</tt>total size of the map <tt>- 2)</tt> still works with  
+this definition, even though the guarantee could be made stronger.
+</p>
+<p>
+A simple picture of a deque:
+</p>
+<blockquote><pre>A-----|----|-----|---F+|++++|++B--|-----|-----Z
+</pre></blockquote>
+<p>
+(A,Z mark the beginning/end, | the block boundaries, F=front, B=back,  
+and - are uninitialized, + are initialized)
+In that picture:  <tt>capacity = size() + min(dist(A,F),dist(B,Z)) = min 
+(dist(A,B),dist(F,Z))</tt>.
+</p>
+<p>
+<tt>Reserve(n)</tt> can grow the map of pointers and add possibly a number of  
+empty blocks to it, in order to guarantee that the next <tt>n-size()
+push_back/push_front</tt> operations will not invalidate iterators, and  
+also will not allocate (i.e. cannot throw).  The second guarantee is  
+not essential and can be left as a QoI.  I know well enough existing  
+implementations of <tt>deque</tt> (sgi/stl, roguewave, stlport, and  
+dinkumware) to know that either can be implemented with no change to  
+the existing class layout and code, and only a few modifications if  
+blocks are pre-allocated (instead of always allocating a new block,  
+check if the next entry in the map of block pointers is not zero).
+</p>
+<p>
+Due to the difference with <tt>vector</tt>, wording is crucial.  Here's a  
+proposed wording to make things concrete;  I tried to be reasonably  
+careful but please double-check me:
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Add new signatures to synopsis in 23.2.2 [deque]:
+</p>
+
+<blockquote><pre>size_type capacity() const;
+bool reserve(size_type n);
+</pre></blockquote>
+
+<p>
+Add new signatures to 23.2.2.2 [deque.capacity]:
+</p>
+
+<blockquote>
+<pre>size_type capacity() const;
+</pre>
+<blockquote>
+<p>
+1 <i>Returns:</i> An upper bound on <tt>n + max(n_f - m_f, n_b - m_b)</tt>  such  
+that, for any sequence of <tt>n_f push_front</tt>, <tt>m_f pop_front</tt>, <tt>n_b  
+push_back</tt>, and <tt>m_b pop_back</tt> operations, interleaved in any order,  
+starting with the current <tt>deque</tt> of size <tt>n</tt>, the <tt>deque</tt> does not  
+invalidate any of its iterators except to the erased elements.
+</p>
+<p>
+2 <i>Remarks:</i>  Unlike a <tt>vector</tt>'s capacity, the capacity of a <tt>deque</tt> can  
+decrease after a sequence of insertions at both ends, even if none of  
+the operations caused the <tt>deque</tt> to invalidate any of its iterators  
+except to the erased elements.
+</p>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>bool reserve(size_type n);
+</pre>
+<blockquote>
+<p>
+2 <i>Effects:</i> A directive that informs a <tt>deque</tt> of a planned sequence of  
+<tt>push_front</tt>, <tt>pop_front</tt>, <tt>push_back</tt>, and <tt>pop_back</tt> operations, so that it  
+can manage iterator invalidation accordingly. After <tt>reserve()</tt>,  
+<tt>capacity()</tt> is greater or equal to the argument of <tt>reserve</tt> if this  
+operation returns <tt>true</tt>; and equal to the previous value of <tt>capacity()</tt>
+otherwise.  If an exception is thrown, there are no effects.
+</p>
+<p>
+3 <i>Returns:</i> <tt>true</tt> if iterators are invalidated as a result of this  
+operation, and false otherwise.
+</p>
+<p>
+4 <i>Complexity:</i> It does not change the size of the sequence and takes  
+at most linear time in <tt>n</tt>.
 </p>
-
 <p>
-Also, the table in p1 contains phrases with "thus" that seem to indicate
-consequences of normative wording in 1.10 [intro.multithread].  That shouldn't be in
-normative text, for the fear of redundant or inconsistent specification with
-the other normative text.
+5 <i>Throws:</i> <tt>length_error</tt> if <tt>n &gt; max_size()</tt>.
 </p>
-
 <p>
-Double-check 29.4.4 [atomics.types.operations] that each
-operation clearly says whether it's a load or a store operation, or
-both.  (It could be clearer, IMO.  Solution not in current proposed resolution.)
+6 <i>Remarks:</i> It is guaranteed that no invalidation takes place during a  
+sequence of <tt>insert</tt> or <tt>erase</tt> operations at either end that happens  
+after a call to <tt>reserve()</tt> except to the erased elements, until the  
+time when an insertion would make <tt>max(n_f-m_f, n_b-m_b)</tt> larger than  
+<tt>capacity()</tt>, where <tt>n_f</tt> is the number of <tt>push_front</tt>, <tt>m_f</tt> of <tt>pop_front</tt>,  
+<tt>n_b</tt> of <tt>push_back</tt>, and <tt>m_b</tt> of <tt>pop_back</tt> operations since the call to  
+<tt>reserve()</tt>.
 </p>
-
 <p>
-29.1 [atomics.order] p2:  What's a "consistent execution"?  It's not defined in
-1.10 [intro.multithread], it's just used in notes there.
+7        An implementation is free to pre-allocate buffers so as to  
+offer the additional guarantee that no exception will be thrown  
+during such a sequence other than by the element constructors.
 </p>
+</blockquote>
+</blockquote>
 
 <p>
-And why does 29.4.4 [atomics.types.operations] p9 for "load" say:
+And 23.2.2.3 [deque.modifiers] para 1, can be enhanced:
 </p>
 
-
 <blockquote>
-<i>Requires:</i> The order argument shall not be <tt>memory_order_acquire</tt>
-nor <tt>memory_order_acq_rel</tt>.
+1 <i>Effects:</i> An insertion in the middle of the deque invalidates all the iterators and references to elements of the
+deque. An insertion at either end of the deque invalidates all the iterators to the deque,
+<ins>unless provisions have been made with reserve,</ins>
+but has no effect on the validity of references to elements of the deque.
 </blockquote>
 
-<p>
-(Since this is exactly the same restriction as for "store", it seems to be a typo.)
-</p>
 
-<p>
-And then: 29.4.4 [atomics.types.operations] p12:
-</p>
 
-<blockquote>
-These operations are read-modify-write operations in the sense of the
-"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the
-evaluation that produced the input value synchronize with any evaluation
-that reads the updated value.
-</blockquote>
 
+
+<hr>
+<h3><a name="856"></a>856. Removal of <tt>aligned_union</tt></h3>
+<p><b>Section:</b> 20.5.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> Jens Maurer <b>Date:</b> 2008-06-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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-This is redundant with 1.10 [intro.multithread], see above for the reasoning.
+With the arrival of extended unions 
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf">N2544</a>),
+there is no
+known use of <tt>aligned_union</tt> that couldn't be handled by
+the "extended unions" core-language facility.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Replace the cross-reference in p1 to refer to 1.1 [intro.scope] instead of
-1.7 [intro.memory].
-Rephrase the table in as follows (maybe don't use a table):
+Remove the following signature from 20.5.2 [meta.type.synop]:
 </p>
+<blockquote><pre>template &lt;std::size_t Len, class... Types&gt; struct aligned_union;
+</pre></blockquote>
 
-<blockquote>
 <p>
-For <tt>memory_order_relaxed</tt>, no operation orders memory.
+Remove the second row from table 51 in 20.5.7 [meta.trans.other],
+starting with:
 </p>
 
+<blockquote><pre>template &lt;std::size_t Len,
+class... Types&gt;
+struct aligned_union;
+</pre></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.4.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> Beman Dawes <b>Date:</b> 2008-06-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>
-For <tt>memory_order_release</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>,
-a store operation performs a release operation on the affected memory location.
+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>
-For <tt>memory_order_acquire</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>,
-a load operation performs an acquire operation on the affected memory location.
+It might be simpler to change the return type to a scoped enum:
 </p>
-</blockquote>
+<blockquote><pre>enum class timeout { not_reached, reached };
+</pre></blockquote>
 
 <p>
-Rephrase 29.1 [atomics.order] p2:
+That's the same cost as returning a <tt>bool</tt>, but not subject to mistakes. Your example below would be:
 </p>
 
-<blockquote>
-<del>The <tt>memory_order_seq_cst</tt> operations that load a value are
-acquire operations on the affected locations. The
-<tt>memory_order_seq_cst</tt> operations that store a value are release
-operations on the affected locations.</del>
-<del>In addition, in a consistent
-execution, t</del><ins>T</ins>here <del>must be</del> <ins>is</ins> a single
-total order <tt>S</tt> on all
-<tt>memory_order_seq_cst</tt> operations, consistent with the happens before
-order and modification orders for all affected locations, such that each
-<tt>memory_order_seq_cst</tt> operation observes either the last preceding
-modification according to this order <tt>S</tt>, or the result of an operation
-that is not <tt>memory_order_seq_cst</tt>. [<i>Note:</i> Although it is not explicitly
-required that <tt>S</tt> include locks, it can always be extended to an order
-that does include lock and unlock operations, since the ordering between
-those is already included in the happens before ordering. <i>-- end note</i>]
-</blockquote>
+<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><b>Proposed resolution:</b></p>
 
+
+
+
+
+<hr>
+<h3><a name="858"></a>858. Wording for Minimal Support for Garbage Collection</h3>
+<p><b>Section:</b> X [garbage.collection] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Pete Becker  <b>Date:</b> 2008-06-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>
-Rephrase 29.4.4 [atomics.types.operations] p12 as:
+The first sentence of the Effects clause for <tt>undeclare_reachable</tt> seems
+to be missing some words. I can't parse
 </p>
-
 <blockquote>
-<i>Effects:</i> Atomically replaces the value pointed to by object or by
-this with desired. Memory is affected according to the value of order.
-These operations are read-modify-write operations <del>in the sense of the
-"synchronizes with" definition</del> (1.10 [intro.multithread])<del>, so both such an operation and the
-evaluation that produced the input value synchronize with any evaluation
-that reads the updated value</del>.
+... for all non-null <tt>p</tt> referencing the argument is no longer declared reachable...
 </blockquote>
+<p>
+I take it the intent is that <tt>undeclare_reachable</tt> should be called only
+when there has been a corresponding call to <tt>declare_reachable</tt>. In
+particular, although the wording seems to allow it, I assume that code
+shouldn't call <tt>declare_reachable</tt> once then call <tt>undeclare_reachable</tt>
+twice.
+</p>
+<p>
+I don't know what "shall be live" in the Requires clause means.
+</p>
+<p>
+In the final Note for <tt>undeclare_reachable</tt>, what does "cannot be
+deallocated" mean? Is this different from "will not be able to collect"?
+</p>
 
 <p>
-Same in p15, p20, p22.
+For the wording on nesting of <tt>declare_reachable</tt> and
+<tt>undeclare_reachable</tt>, the words for locking and unlocking recursive
+mutexes probably are a good model.
 </p>
 
 
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
 
 
 
 
 <hr>
-<h3><a name="819"></a>819. rethrow_if_nested</h3>
-<p><b>Section:</b> 18.7.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> Alisdair Meredith <b>Date:</b> 2008-03-25</p>
+<h3><a name="859"></a>859. Monotonic Clock is Conditionally Supported?</h3>
+<p><b>Section:</b> X [datetime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Pete Becker <b>Date:</b> 2008-06-23</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>
-Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I
-got it quite right.
+<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>
+
 <p>
-The current wording says:
+when <tt>monotonic_clock</tt> is not required to exist?
 </p>
 
-<blockquote>
-<pre>template &lt;class E&gt; void rethrow_if_nested(const E&amp; e);
-</pre>
-<blockquote>
+
+<p><b>Proposed resolution:</b></p>
 <p>
-<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>
 
+
+
+
+
+<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#New">New</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-06-23</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 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.
+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><b>Proposed resolution:</b></p>
+<p>
+</p>
 
 
 
 
 
 <hr>
-<h3><a name="820"></a>820. <tt>current_exception()</tt>'s interaction with throwing copy ctors</h3>
-<p><b>Section:</b> 18.7.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> Stephan T. Lavavej <b>Date:</b> 2008-03-26</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="861"></a>861. Incomplete specification of EqualityComparable for std::forward_list</h3>
+<p><b>Section:</b> 23.1 [container.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>Date:</b> 2008-06-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#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-As of N2521, the Working Paper appears to be silent about what
-<tt>current_exception()</tt> should do if it tries to copy the currently handled
-exception and its copy constructor throws.  18.7.5 [propagation]/7 says "If the
-function needs to allocate memory and the attempt fails, it returns an
-<tt>exception_ptr</tt> object that refers to an instance of <tt>bad_alloc</tt>.", but
-doesn't say anything about what should happen if memory allocation
-succeeds but the actual copying fails.
+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>
-I see three alternatives: (1) return an <tt>exception_ptr</tt> object that refers
-to an instance of some fixed exception type, (2) return an <tt>exception_ptr</tt>
-object that refers to an instance of the copy ctor's thrown exception
-(but if that has a throwing copy ctor, an infinite loop can occur), or
-(3) call <tt>terminate()</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>
+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>
+<p>
+I propose to apply one of the following resolutions, which are described as:
 </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>
-I believe that <tt>terminate()</tt> is the most reasonable course of action, but
-before we go implement that, I wanted to raise this issue.
+Both proposal choices are discussed, the preferred choice of the author is
+to apply (A).
 </p>
 
-<p><i>[
-Peter's summary:
-]</i></p>
 
+<p><b>Proposed resolution:</b></p>
+<p>
+Common part:
+</p>
+<ul>
+<li>
+<p>
+Just betwen 23.2.3.5 [forwardlist.ops] and 23.2.3.6 [forwardlist.spec]
+add a new
+section "forwardlist comparison operators" [forwardlist.compare] (and
+also add the
+new section number to 23.2.3 [forwardlist]/2 in front of "Comparison operators"):
+</p>
+<blockquote>
+forwardlist comparison operators [forwardlist.compare]
+</blockquote>
+</li>
+</ul>
 
+<p>
+Option (A):
+</p>
 <blockquote>
+<ul>
+<li>
 <p>
-The current practice is to not have throwing copy constructors in
-exception classes, because this can lead to <tt>terminate()</tt> as described in
-15.5.1 [except.terminate]. Thus calling <tt>terminate()</tt> in this situation seems
-consistent and does not introduce any new problems.
+Add to the new section [forwardlist.compare] the following paragraphs:
 </p>
 
+<blockquote>
+<pre>template &lt;class T, class Allocator&gt;
+bool operator==(const forward_list&lt;T,Allocator&gt;&amp; x, const forward_list&lt;T,Allocator&gt;&amp; y);
+</pre>
+<blockquote>
 <p>
-However, the resolution of core issue 475 may relax this requirement:
+<i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]).
+</p>
+<p>
+<i>Returns:</i> <tt>true</tt> if
+</p>
+<ul>
+<li>
+<p>
+for every iterator <tt>i</tt> in the range <tt>[x.begin(), E)</tt>, where <tt>E ==
+x.begin() + M</tt> and <tt>M ==
+   min(distance(x.begin(), x.end()), distance(y.begin(), y.end()))</tt>,
+the following condition holds:
+</p>
+<blockquote><pre>*i == *(y.begin() + (i - x.begin())).
+</pre></blockquote>
+</li>
+<li>
+if <tt>i == E</tt> then <tt>i == x.end() &amp;&amp; (y.begin() + (i - x.begin())) == y.end()</tt>.
+</li>
+<li>
+Otherwise, returns <tt>false</tt>.
+</li>
+</ul>
+<p>
+<i>Throws:</i> Nothing unless an exception is thrown by the equality comparison.
+</p>
+<p>
+<i>Complexity:</i> At most <tt>M</tt> comparisons.
 </p>
+</blockquote>
+<pre>template &lt;class T, class Allocator&gt;
+bool operator!=(const forward_list&lt;T,Allocator&gt;&amp; x, const forward_list&lt;T,Allocator&gt;&amp; y);
+</pre>
+<blockquote>
+<i>Returns:</i> <tt>!(x == y)</tt>.
+</blockquote>
+</blockquote>
+</li>
+</ul>
+</blockquote>
 
+<p>
+Option (B):
+</p>
 <blockquote>
-The CWG agreed with the position that <tt>std::uncaught_exception()</tt> should
-return <tt>false</tt> during the copy to the exception object and that <tt>std::terminate()</tt>
-should not be called if that constructor exits with an exception.
+<ul>
+<li>
+<p>
+Add to the new section [forwardlist.compare] the following paragraphs:
+</p>
+<blockquote>
+<pre>template &lt;class T, class Allocator&gt;
+bool operator==(const forward_list&lt;T,Allocator&gt;&amp; x, const forward_list&lt;T,Allocator&gt;&amp; y);
+</pre>
+<blockquote>
+<p>
+<i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]).
+</p>
+<p>
+<i>Returns:</i> <tt>distance(x.begin(), x.end()) == distance(y.begin(), y.end())
+&amp;&amp; equal(x.begin(), x.end(), y.begin())</tt>.
+</p>
+</blockquote>
+<pre>template &lt;class T, class Allocator&gt;
+bool operator!=(const forward_list&lt;T,Allocator&gt;&amp; x, const forward_list&lt;T,Allocator&gt;&amp; y);
+</pre>
+<blockquote>
+<i>Returns:</i> <tt>!(x == y)</tt>.
+</blockquote>
+</blockquote>
+</li>
+</ul>
 </blockquote>
 
+
+
+
+
+<hr>
+<h3><a name="862"></a>862. Impossible complexity for 'includes'</h3>
+<p><b>Section:</b> 25.3.5.1 [includes] <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>Date:</b> 2008-07-02</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>
-Since throwing copy constructors will no longer call <tt>terminate()</tt>, option
-(3) doesn't seem reasonable as it is deemed too drastic a response in a
-recoverable situation.
+In 25.3.5.1 [includes] the complexity is "at most -1 comparisons" if passed
+two empty ranges.  I don't know how to perform a negative number of
+comparisions!
 </p>
 
 <p>
-Option (2) cannot be adopted by itself, because a potential infinite
-recursion will need to be terminated by one of the other options.
+This same issue also applies to:
 </p>
 
-</blockquote>
+<ul>
+<li><tt>set_union</tt></li>
+<li><tt>set_intersection</tt></li>
+<li><tt>set_difference</tt></li>
+<li><tt>set_symmetric_difference</tt></li>
+<li><tt>merge</tt></li>
+</ul>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add the following paragraph after 18.7.5 [propagation]/7:
 </p>
 
-<blockquote>
+
+
+
+
+<hr>
+<h3><a name="863"></a>863. What is the state of a stream after close() succeeds</h3>
+<p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Steve Clamage <b>Date:</b> 2008-07-08</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</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>Returns (continued):</i> If the attempt to copy the current exception
-object throws an exception, the function returns an <tt>exception_ptr</tt> that
-refers to the thrown exception or, if this is not possible, to an
-instance of <tt>bad_exception</tt>.
+Suppose writing to an <tt>[o]fstream</tt> fails and you later close the <tt>stream</tt>.
+The <tt>overflow()</tt> function is called to flush the buffer (if it exists).
+Then the file is unconditionally closed, as if by calling <tt>flcose</tt>.
 </p>
 <p>
-[<i>Note:</i> The copy constructor of the thrown exception may also fail, so
-the implementation is allowed to substitute a <tt>bad_exception</tt> to avoid
-infinite recursion. <i>-- end note.</i>]
+If either <tt>overflow</tt> or <tt>fclose</tt> fails, <tt>close()</tt> reports failure, and clearly
+the <tt>stream</tt> should be in a failed or bad state.
+</p>
+<p>
+Suppose the buffer is empty or non-existent (so that <tt>overflow()</tt> does not
+fail), and <tt>fclose</tt> succeeds. The <tt>close()</tt> function reports success, but
+what is the state of the <tt>stream</tt>?
 </p>
-</blockquote>
 
 
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
 
 
 
 
 <hr>
-<h3><a name="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3>
-<p><b>Section:</b> 20.6.11.3.3 [unique.ptr.runtime.modifiers] <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>Date:</b> 2008-03-30</p>
+<h3><a name="864"></a>864. Defect in atomic wording</h3>
+<p><b>Section:</b> 29.4 [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> Anthony Williams <b>Date:</b> 2008-07-10</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#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Reading resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> I noticed the following:
+There's an error in 29.4 [atomics.types.operations]/p9:
 </p>
 
 <blockquote>
-<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
+<pre>C atomic_load(const volatile A * object);
+C atomic_load_explicit(const volatile A * object, memory_order);
+C A ::load(memory_order order = memory_order_seq_cst) const volatile;
 </pre>
-
+<blockquote>
 <p>
--1- <i>Requires:</i> Does not accept pointer types which are convertible
-to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
-required). [<i>Note:</i> One implementation technique is to create a private
-templated overload. <i>-- end note</i>]
+<i>Requires:</i> The <tt>order</tt> argument shall not be <tt>memory_order_acquire</tt> nor
+<tt>memory_order_acq_rel</tt>.
 </p>
 </blockquote>
+</blockquote>
 
 <p>
-This could be cleaned up by mandating the overload as a public deleted
-function.  In addition, we should probably overload <tt>reset</tt> on <tt>nullptr_t</tt>
-to be a stronger match than the deleted overload. Words...
+I believe that this should state
 </p>
+<blockquote>
+shall not be <tt>memory_order_release</tt>.
+</blockquote>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Add to class template definition in 20.6.11.3 [unique.ptr.runtime]
+There's also an error in 29.4 [atomics.types.operations]/p17:
 </p>
 
 <blockquote>
-<pre>// modifiers 
-T* release(); 
-void reset(T* p = 0); 
-<ins>void reset( nullptr_t );</ins>
-<ins>template&lt; typename T &gt; void reset( T ) = delete;</ins>
-void swap(unique_ptr&amp;&amp; u);
-</pre>
+... When only one <tt>memory_order</tt> argument is supplied, the value of success
+is <tt>order</tt>, and
+the value of failure is <tt>order</tt> except that a value of
+<tt>memory_order_acq_rel</tt> shall be replaced by the value
+<tt>memory_order_require</tt> ...
+</blockquote>
+<p>
+I believe this should state
+</p>
+<blockquote>
+shall be replaced by the value <tt>memory_order_acquire</tt> ...
 </blockquote>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-Update 20.6.11.3.3 [unique.ptr.runtime.modifiers]
+Change 29.4 [atomics.types.operations]/p9:
 </p>
 
 <blockquote>
-<pre>void reset(pointer p = pointer());
-<ins>void reset(nullptr_t);</ins>
+<pre>C atomic_load(const volatile A * object);
+C atomic_load_explicit(const volatile A * object, memory_order);
+C A ::load(memory_order order = memory_order_seq_cst) const volatile;
 </pre>
-
+<blockquote>
 <p>
-<del>-1- <i>Requires:</i> Does not accept pointer types which are convertible
-to <tt>pointer</tt> (diagnostic
-required). [<i>Note:</i> One implementation technique is to create a private
-templated overload. <i>-- end note</i>]</del>
+<i>Requires:</i> The <tt>order</tt> argument shall not be <del><tt>memory_order_acquire</tt></del>
+<ins><tt>memory_order_release</tt></ins> nor <tt>memory_order_acq_rel</tt>.
 </p>
+</blockquote>
+</blockquote>
+
 <p>
-<i>Effects:</i> If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>. 
+Change 29.4 [atomics.types.operations]/p17:
 </p>
-<p>...</p>
-</blockquote>
 
-<p><i>[
-Note this wording incorporates resolutions for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a> (New) and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> (Ready).
-]</i></p>
+<blockquote>
+... When only one <tt>memory_order</tt> argument is supplied, the value of success
+is <tt>order</tt>, and
+the value of failure is <tt>order</tt> except that a value of
+<tt>memory_order_acq_rel</tt> shall be replaced by the value
+<del><tt>memory_order_require</tt></del> <ins><tt>memory_order_acquire</tt></ins> ...
+</blockquote>
 
 
 
@@ -17921,1295 +18079,1639 @@ Note this wording incorporates resolutions for <a href="http://www.open-std.org/
 
 
 <hr>
-<h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3>
-<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <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>Date:</b> 2008-04-01</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="865"></a>865. More algorithms that throw away information</h3>
+<p><b>Section:</b> 25.2.6 [alg.fill], 25.2.7 [alg.generate] <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>Date:</b> 2008-07-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>
-I just noticed that the following program is legal in C++03, but
-is forbidden in the current draft:
+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>
 
-<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>
+<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>
-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.)
+In both cases the minimum requirements on the iterator are
+<tt>OutputIterator</tt>, which means according to the requirements of
+24.1.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><b>Proposed resolution:</b></p>
+<ol>
+<li>
 <p>
-In 20.1.1 [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]:
+Replace the current declaration of <tt>fill_n</tt> in 25 [algorithms]/2, header
+<tt>&lt;algorithm&gt;</tt> synopsis and in 25.2.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 p.2 add a new returns clause saying:
+</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>
+<i>Returns:</i> <tt>first + n</tt> for <tt>fill_n</tt>.
 </blockquote>
-
+</li>
+<li>
 <p>
-In 20.1.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]:
+Replace the current declaration of <tt>generate_n</tt> in 25 [algorithms]/2, header
+<tt>&lt;algorithm&gt;</tt> synopsis and in 25.2.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 p.1 add a new returns clause saying:
 </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>
+<i>Returns:</i> <tt>first + n</tt> for <tt>generate_n</tt>.
 </blockquote>
+</li>
+</ol>
 
 
 
 
 
 <hr>
-<h3><a name="823"></a>823. <tt>identity&lt;void&gt;</tt> seems broken</h3>
-<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2008-04-09</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="866"></a>866. Qualification of placement new-expressions</h3>
+<p><b>Section:</b> 20.7.10 [specialized.algorithms], 20.7.12.2.6 [util.smartptr.shared.create] <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>Date:</b> 2008-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>
 <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.2.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.
+LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> replaced "<tt>new</tt>" with "<tt>::new</tt>" in the placement
+new-expression in 20.7.5.1 [allocator.members]. I believe the rationale
+given in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> applies also to the following other contexts:
 </p>
-
-
-<p><b>Proposed resolution:</b></p>
+<ul>
+<li>
 <p>
+in 20.7.10 [specialized.algorithms], all four algorithms <tt>unitialized_copy</tt>,
+<tt>unitialized_copy_n</tt>, <tt>unitialized_fill</tt> and <tt>unitialized_fill_n</tt> use
+the unqualified placement new-expression in some variation of the form:
 </p>
-
-
-
-
-
-<hr>
-<h3><a name="824"></a>824. rvalue ref issue with <tt>basic_string</tt> inserter</h3>
-<p><b>Section:</b> 21.3.8.9 [string.io] <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>Date:</b> 2008-04-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</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>
+<blockquote><pre>new  (static_cast&lt;void*&gt;(&amp;*result)) typename  iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
+</pre></blockquote>
+</li>
+<li>
 <p>
-In the current working paper, the <tt>&lt;string&gt;</tt> header synopsis at the end of
-21.2 [string.classes] lists a single <tt>operator&lt;&lt;</tt> overload
-for <tt>basic_string</tt>.
+in 20.7.12.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression:
 </p>
-
-<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
- basic_ostream&lt;charT, traits&gt;&amp;
-   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
-              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
+<blockquote><pre>new  (pv)  T(std::forward&lt;Args&gt;(args)...),
 </pre></blockquote>
-
+</li>
+</ul>
 <p>
-The definition in 21.3.8.9 [string.io] lists two:
+I suggest to add qualification in all those places. As far as I know,
+these are all the remaining places in the whole library that explicitly
+use a placement new-expression. Should other uses come out, they should
+be qualified as well.
 </p>
-
-<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
- basic_ostream&lt;charT, traits&gt;&amp;
-   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
-              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
-
-template&lt;class charT, class traits, class Allocator&gt;
- basic_ostream&lt;charT, traits&gt;&amp;
-   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
-              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
-</pre></blockquote>
-
 <p>
-I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two
-signatures in 21.3.8.9 [string.io] should be deleted.
+As an aside, a qualified placement new-expression does not need
+additional requirements to be compiled in a constrained context. By
+adding qualification, the <tt>HasPlacementNew</tt> concept introduced recently in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2677.pdf">N2677 (Foundational Concepts)</a>
+would no longer be needed by library and
+should therefore be removed.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
+Replace "<tt>new</tt>" with "<tt>::new</tt>" in:
 </p>
+<ul>
+<li>
+20.7.10.1 [uninitialized.copy], paragraphs 1 and 3
+</li>
+<li>
+20.7.10.2 [uninitialized.fill]  paragraph 1
+</li>
+<li>
+20.7.10.3 [uninitialized.fill.n] paragraph 1
+</li>
+<li>
+20.7.12.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2.
+</li>
+</ul>
+
 
 
 
 
 
 <hr>
-<h3><a name="825"></a>825. Missing rvalues reference stream insert/extract operators?</h3>
-<p><b>Section:</b> 19.4.2.1 [syserr.errcode.overview], 20.6.12.2.8
-[util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3
-[bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9
-[re.submatch] <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>Date:</b> 2008-04-10</p>
+<h3><a name="867"></a>867. Valarray and value-initialization</h3>
+<p><b>Section:</b> 26.5.2.1 [valarray.cons] <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>Date:</b> 2008-07-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</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#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Should the following use rvalues references to stream in insert/extract
-operators?
+From 26.5.2.1 [valarray.cons], paragraph 2:
 </p>
 
-<ul>
-<li>19.4.2.1 [syserr.errcode.overview]</li>
-<li>20.6.12.2.8 [util.smartptr.shared.io]</li>
-<li>22.2.8 [facets.examples]</li>
-<li>23.3.5.3 [bitset.operators]</li>
-<li>26.3.6 [complex.ops]</li>
-<li>Doubled signatures in 27.5 [stream.buffers] for character inserters
-(ref 27.6.2.6.4 [ostream.inserters.character])
-+ definition 27.6.2.6.4 [ostream.inserters.character]</li>
-<li>28.9 [re.submatch]</li>
-</ul>
-
+<blockquote><pre>explicit  valarray(size_t);
+</pre>
+<blockquote>
+The array created by this constructor has a length equal to the value of the argument. The elements
+of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
+</blockquote>
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
+The problem is that the most obvious <tt>T</tt>s for <tt>valarray</tt> are <tt>float</tt>
+and <tt>double</tt>, they don't have a default constructor. I guess the intent is to value-initialize
+the elements, so I suggest replacing:
 </p>
 
-
-
-
-
-<hr>
-<h3><a name="826"></a>826. Equivalent of <tt>%'d</tt>, or rather, lack thereof?</h3>
-<p><b>Section:</b> 22.2.2.2 [locale.nm.put] <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>Date:</b> 2008-04-07</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>
+<blockquote>
+The elements of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
+</blockquote>
 <p>
-In the spirit of <tt>printf vs iostream</tt>...
+with
 </p>
+<blockquote>
+The elements of the array are value-initialized.
+</blockquote>
 
 <p>
-POSIX <tt>printf</tt> says that <tt>%'d</tt> should insert grouping characters (and the
-implication is that in the absence of <tt>'</tt> no grouping characters are
-inserted). The <tt>num_put</tt> facet, on the other hand, seems to always insert
-grouping characters. Can this be considered a defect worth fixing for
-C++0x? Maybe <tt>ios_base</tt> needs an additional flag?
+There is another reference to the default constructor of <tt>T</tt> in the non-normative note in paragraph 9.
+That reference should also be replaced. (The normative wording in paragraph 8 refers to <tt>T()</tt>
+and so it doesn't need changes).
 </p>
 
-<p><i>[
-Pablo Halpern:
-]</i></p>
 
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 26.5.2.1 [valarray.cons], paragraph 2:
+</p>
 
 <blockquote>
-I'm not sure it constitutes a defect, but I would be in favor of adding
-another flag (and corresponding manipulator).
+<pre>explicit  valarray(size_t);
+</pre>
+<blockquote>
+The array created by this constructor has a length equal to the value of the argument. The elements
+of the array are <del>constructed using the default constructor for the instantiating type <tt>T</tt></del>
+<ins>value-initialized (8.5 [dcl.init])</ins>.
+</blockquote>
 </blockquote>
 
-<p><i>[
-Martin Sebor:
-]</i></p>
-
+<p>
+Change 26.5.2.7 [valarray.members], paragraph 9:
+</p>
 
 <blockquote>
-I don't know if it qualifies as a defect but I agree that there
-should be an easy way to control whether the thousands separator
-should or shouldn't be inserted. A new flag would be in line with
-the current design of iostreams (like <tt>boolalpha</tt>, <tt>showpos</tt>, or
-<tt>showbase</tt>).
+[<i>Example:</i> If the argument has the value -2, the first two elements of the result will be <del>constructed using the 
+default constructor</del>
+<ins>value-initialized (8.5 [dcl.init])</ins>;
+the third element of the result will be assigned the value of the first element of the argument; etc. <i>-- end example</i>]
 </blockquote>
 
 
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
 
 
 
 
 <hr>
-<h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3>
-<p><b>Section:</b> 20.6.12.2.1 [util.smartptr.shared.const] <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>Date:</b> 2008-04-11</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>
+<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#New">New</a>
+ <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-22</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#New">New</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.
+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-active.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><b>Proposed resolution:</b></p>
 <p>
+Change 20.1.1 [utility.arg.requirements], paragraph 2:
+</p>
+
+<blockquote>
+In general, a default constructor is not required. Certain container class member function signatures specify 
+<del>the default constructor</del>
+<ins><tt>T()</tt></ins>
+as a default argument. <tt>T()</tt> shall be a well-defined expression (8.5 [dcl.init]) if one of
+those signatures is called using  the default argument (8.3.6 [dcl.fct.default]).
+</blockquote>
+
+<p>
+In all the following paragraphs in clause 23 [containers], replace "default constructed" with "value-initialized
+(8.5 [dcl.init])":
 </p>
 
+<ul>
+<li>23.2.2.1 [deque.cons] para 2</li>
+<li>23.2.2.2 [deque.capacity] para 1</li>
+<li>23.2.3.1 [forwardlist.cons] para 3</li>
+<li>23.2.3.4 [forwardlist.modifiers] para 21</li>
+<li>23.2.4.1 [list.cons] para 3</li>
+<li>23.2.4.2 [list.capacity] para 1</li>
+<li>23.2.6.1 [vector.cons] para 3</li>
+<li>23.2.6.2 [vector.capacity] para 10</li>
+</ul>
+
 
 
 
 
 <hr>
-<h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3>
-<p><b>Section:</b> 30.3.1.1 [thread.mutex.class] <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>Date:</b> 2008-04-18</p>
+<h3><a name="869"></a>869. Bucket (local) iterators and iterating past end</h3>
+<p><b>Section:</b> 23.1.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> Sohail Somani <b>Date:</b> 2008-07-22</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>
-[Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
+Is there any language in the current draft specifying the behaviour of the following snippet?
 </p>
+
+<blockquote><pre>unordered_set&lt;int&gt; s;
+unordered_set&lt;int&gt;::local_iterator it = s.end(0);
+
+// Iterate past end - the unspecified part
+it++;
+</pre></blockquote>
+
 <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.
+I don't think there is anything about <tt>s.end(n)</tt> being considered an
+iterator for the past-the-end value though (I think) it should be.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
+Change Table 97 "Unordered associative container requirements" in 23.1.5 [unord.req]:
 </p>
 
+<blockquote>
+<table border="1">
+<caption>Table 97: Unordered associative container requirements</caption>
+<tbody><tr>
+<th>expression</th><th>return type</th><th>assertion/note pre/post-condition</th><th>complexity</th>
+</tr>
+<tr>
+<td><tt>b.begin(n)</tt></td>
+<td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
+<td>Pre: n shall be in the range [0,b.bucket_count()). <del>Note: [b.begin(n), b.end(n)) is a
+valid range containing all of the elements in the n<sup>th</sup> bucket.</del>
+<ins><tt>b.begin(n)</tt> returns an iterator referring to the first element in the bucket.
+If the bucket is empty, then <tt>b.begin(n) == b.end(n)</tt>.</ins></td>
+<td>Constant</td>
+</tr>
+<tr>
+<td><tt>b.end(n)</tt></td>
+<td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
+<td>Pre: n shall be in the range <tt>[0, b.bucket_count())</tt>.
+<ins><tt>b.end(n)</tt> returns an iterator which is the past-the-end value for the bucket.</ins></td>
+<td>Constant</td>
+</tr>
+</tbody></table>
+</blockquote>
+
+
 
 
 
 
 <hr>
-<h3><a name="829"></a>829. current_exception wording unclear about exception type</h3>
-<p><b>Section:</b> 18.7.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> Beman Dawes <b>Date:</b> 2008-04-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>
+<h3><a name="870"></a>870. Do unordered containers not support function pointers for predicate/hasher?</h3>
+<p><b>Section:</b> 23.1.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> Daniel Krügler <b>Date:</b> 2008-08-17</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>Consider this code:</p>
+<p>
+Good ol' associative containers allow both function pointers and
+function objects as feasible
+comparators, as described in 23.1.4 [associative.reqmts]/2:
+</p>
 
 <blockquote>
-<pre>exception_ptr xp;</pre>
-<pre>try {do_something(); }
-
-catch (const runtime_error&amp; ) {xp = current_exception();}
-
-...
-
-rethrow_exception(xp);</pre>
+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>
-Say <code>do_something()</code> throws an exception object of type <code>
-range_error</code>. What is the type of the exception object thrown by <code>
-rethrow_exception(xp)</code> above? It must have a type of <code>range_error</code>; 
-if it were of type <code>runtime_error</code> it still isn't possible to 
-propagate an exception and the exception_ptr/current_exception/rethrow_exception 
-machinery serves no useful purpose.
+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.1.5 [unord.req]/3+4+5:
 </p>
 
+<blockquote>
 <p>
-Unfortunately, the current wording does not explicitly say that. Different 
-people read the current wording and come to different conclusions. While it may 
-be possible to deduce the correct type from the current wording, it would be 
-much clearer to come right out and explicitly say what the type of the referred 
-to exception is.
+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><i>[
-Peter adds:
-]</i></p>
-
-
-<blockquote>
 <p>
-I don't like the proposed resolution of 829. The normative text is
-unambiguous that the <tt>exception_ptr</tt> refers to the <em>currently handled
-exception</em>. This term has a standard meaning, see 15.3 [except.handle]/8; this is the
-exception that <tt>throw;</tt> would rethrow, see 15.1 [except.throw]/7.
+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>
-A better way to address this is to simply add the non-normative example
-in question as a clarification. The term <i>currently handled exception</i>
-should be italicized and cross-referenced. A [<i>Note:</i> the currently
-handled exception is the exception that a throw expression without an
-operand (15.1 [except.throw]/7) would rethrow. <i>--end note</i>] is also an option.
+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><b>Proposed resolution:</b></p>
-
 <p>
-After 18.7.5 [propagation] , paragraph 7, add the indicated text:
+and table 97 says in the column "assertion...post-condition" for the
+expression X::hasher:
 </p>
 
 <blockquote>
-<pre>exception_ptr current_exception();</pre>
+<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>
 
-<blockquote>
 <p>
-<i>Returns:</i> <code>exception_ptr</code> object that refers 
-to the currently handled exception or a copy of the currently handled 
-exception, or a null <code>exception_ptr</code> object if no exception is being handled. If 
-the function needs to allocate memory and the attempt fails, it returns an
-<code>exception_ptr</code> object that refers to an instance of <code>bad_alloc</code>. 
-It is unspecified whether the return values of two successive calls to
-<code>current_exception</code> refer to the same exception object. 
-[<i>Note:</i> that is, it 
-is unspecified whether <code>current_exception</code>
-creates a new copy each time it is called.
-<i>-- end note</i>]
+Note that 20.6 [function.objects]/1 defines as "Function objects are
+objects with an <tt>operator()</tt> defined.[..]"
 </p>
-
 <p>
-<ins><i>Remarks:</i> The type of the exception object 
-referred to by the returned <code>exception_ptr</code> is the most-derived 
-type of the currently handled exception.</ins>
+Does this restriction exist by design or is it an oversight? If an
+oversight, I suggest that to apply
+the following
 </p>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-<i>Throws:</i> nothing.
+In 23.1.5 [unord.req]/3, just after the second sentence which is written as
 </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>
+add one further sentence:
+</p>
+
+<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>
+[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>
+<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]
+</p>
 
 
 
 
 
 <hr>
-<h3><a name="830"></a>830. Incomplete list of char_traits specializations</h3>
-<p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#char.traits">active issues</a> in [char.traits].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p>
+<h3><a name="871"></a>871. Iota's requirements on T are too strong</h3>
+<p><b>Section:</b> 26.6.5 [numeric.iota] <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>Date:</b> 2008-08-20</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>
-  Paragraph 4 of 21.1 [char.traits] mentions that this
-  section specifies two specializations (<code>char_traits&lt;char&gt;</code>
-  and (<code>char_traits&lt;wchar_t&gt;</code>). However, there are actually
-  four specializations provided, i.e. in addition to the two above also
-  <code>char_traits&lt;char16_t&gt;</code> and <code>char_traits&lt;char32_t&gt;</code>).
-  I guess this was just an oversight and there is nothing wrong with just
-  fixing this.
+According to the recent WP
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>,
+26.6.5 [numeric.iota]/1, the requires clause
+of <tt>std::iota</tt> says:
 </p>
 
-<p><i>[
-Alisdair adds:
-]</i></p>
-
 <blockquote>
-<tt>char_traits&lt; char16/32_t &gt;</tt>
-should also be added to <tt>&lt;ios_fwd&gt;</tt> in 27.2 [iostream.forward], and all the specializations
-taking a <tt>char_traits</tt> parameter in that header.
+<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>
+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><b>Proposed resolution:</b></p>
 <p>
-  Replace paragraph 4 of 21.1 [char.traits] by:
+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><b>Proposed resolution:</b></p>
+
 <p>
-  This subclause specifies a struct template, <code>char_traits&lt;charT&gt;</code>,
-  and four explicit specializations of it, <code>char_traits&lt;char&gt;</code>,
-  <code>char_traits&lt;char16_t&gt;</code>, <code>char_traits&lt;char32_t&gt;</code>, and
-  <code>char_traits&lt;wchar_t&gt;</code>, all of which appear in the header
-  &lt;string&gt; and satisfy the requirements below.
+Change the first sentence of 26.6.5 [numeric.iota]/1:
 </p>
+
+<blockquote>
+<i>Requires:</i> <tt>T</tt> shall <del>meet the requirements of
+<tt>CopyConstructible</tt> and <tt>Assignable</tt> types,</del>
+<ins>
+be <tt>MoveConstructible</tt> (Table 34)
+</ins>
+and shall be
+convertible to <tt>ForwardIterator</tt>'s value type. [..]
 </blockquote>
 
 
 
 
 
+
 <hr>
-<h3><a name="831"></a>831. wrong type for not_eof()</h3>
-<p><b>Section:</b> 21.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p>
+<h3><a name="872"></a>872. <tt>move_iterator::operator[]</tt> has wrong return type</h3>
+<p><b>Section:</b> 24.4.3.3.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-08-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>
-  In Table 56 (Traits requirements) the <tt>not_eof()</tt> member function
-  is using an argument of type <i>e</i> which denotes an object of
-  type <code>X::int_type</code>. However, the specializations in
-  21.1.3 [char.traits.specializations] all use <code>char_type</code>.
-  This would effectively mean that the argument type actually can't
-  represent EOF in the first place. I'm pretty sure that the type used
-  to be <code>int_type</code> which is quite obviously the only sensible
-  argument.
+<tt>move_iterator</tt>'s <tt>operator[]</tt> is declared as:
 </p>
+
+<blockquote><pre>reference operator[](difference_type n) const;
+</pre></blockquote>
+
 <p>
-  This issue is close to being editorial. I suspect that the proposal
-  changing this section to include the specializations for <code>char16_t</code>
-  and <code>char32_t</code> accidentally used the wrong type.
+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><b>Proposed resolution:</b></p>
 <p>
-  In 21.1.3.1 [char.traits.specializations.char],
-  21.1.3.2 [char.traits.specializations.char16_t],
-  21.1.3.3 [char.traits.specializations.char32_t], and
-   [char.traits.specializations.wchar_t] correct the
-  argument type from <code>char_type</code> to <code>int_type</code>.
+In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the declaration of
+<tt>move_iterator</tt>'s <tt>operator[]</tt> to:
 </p>
 
+<blockquote><pre><del>reference</del> <ins><i>unspecified</i></ins> operator[](difference_type n) const;
+</pre></blockquote>
+
+
 
 
 
 
 <hr>
-<h3><a name="832"></a>832. Applying constexpr to System error support</h3>
-<p><b>Section:</b> 19.4 [syserr] <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>Date:</b> 2008-05-14</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</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>
+<h3><a name="873"></a>873. signed integral type and unsigned integral type are not clearly defined</h3>
+<p><b>Section:</b> 3.9.1 [basic.fundamental] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Travis Vitek <b>Date:</b> 2008-06-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>
-Initialization of objects of class <tt>error_code</tt>
-(19.4.2 [syserr.errcode]) and class
-<tt>error_condition</tt> (19.4.3 [syserr.errcondition]) can be made simpler and more reliable by use of
-the new <tt>constexpr</tt> feature 
-[<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>]
-of C++0x. Less code will need to be
-generated for both library implementations and user programs when
-manipulating constant objects of these types. 
-</p>
+    <p>
+      Neither the term "signed integral type" nor the term "unsigned
+      integral type" is defined in the core language section of the
+      standard, therefore the library section should avoid its use.  The
+      terms <i>signed integer type</i> and <i>unsigned integer type</i> are
+      indeed defined (in 3.9.1 [basic.fundamental]), thus the usages should be
+      replaced accordingly.
+    </p>
 
-<p>
-This was not proposed originally because the constant expressions
-proposal was moving into the standard at about the same time as the
-Diagnostics Enhancements proposal 
-[<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>],
-and it wasn't desirable to
-make the later depend on the former. There were also technical concerns
-as to how <tt>constexpr</tt> would apply to references. Those concerns are now
-resolved; <tt>constexpr</tt> can't be used for references, and that fact is
-reflected in the proposed resolution.
-</p>
+    <p>
+      Note that the key issue here is that "signed" + "integral type" !=
+      "signed integral type".
+      
+      The types <code>bool</code>, <code>char</code>, <code>char16_t</code>,
+      <code>char32_t</code> and <code>wchar_t</code> are all listed as
+      integral types, but are neither of <i>signed integer type</i> or
+      <i>unsigned integer type</i>. According to 3.9 [basic.types] p7, a synonym for
+      integral type is <i>integer type</i>.
+      
+      Given this, one may choose to assume that an <i>integral type</i> that
+      can represent values less than zero is a <i>signed integral type</i>.
+      Unfortunately this can cause ambiguities.
+      
+      As an example, if <code>T</code> is <code>unsigned char</code>, the
+      expression <code>make_signed&lt;T&gt;::type</code>, is supposed to
+      name a signed integral type. There are potentially two types that
+      satisfy this requirement, namely <code>signed char</code> and
+      <code>char</code> (assuming <code>CHAR_MIN &lt; 0</code>).
+    </p>
+  
+
+  <p><b>Proposed resolution:</b></p>
+    <p>
+      I propose to use the terms "signed integer type" and "unsigned integer
+      type" in place of "signed integral type" and "unsigned integral type"
+      to eliminate such ambiguities.
+    </p>
+    
+    <p>
+      The proposed change makes it absolutely clear that the difference
+      between two pointers cannot be <tt>char</tt> or <tt>wchar_t</tt>,
+      but could be any of the signed integer types.
+      5.7 [expr.add] paragraph 6...
+    </p>
+    <blockquote>
+      <p>
+        </p><ol>
+          <li>
+            When two pointers to elements of the same array object are
+            subtracted, the result is the difference of the subscripts of
+            the two array elements. The type of the result is an
+            implementation-defined <del>signed integral
+            type</del><ins>signed integer type</ins>; this type shall be the
+            same type that is defined as <code>std::ptrdiff_t</code> in the
+            <code>&lt;cstdint&gt;</code> header (18.1)...
+          </li>
+        </ol>
+      
+    </blockquote>
+
+    <p>
+      The proposed change makes it clear that <tt>X::size_type</tt> and
+      <tt>X::difference_type</tt> cannot be <tt>char</tt> or
+      <tt>wchar_t</tt>, but could be one of the signed or unsigned integer
+      types as appropriate.
+      20.1.2 [allocator.requirements] table 40...
+    </p>
+    <blockquote>
+      Table 40: Allocator requirements
+      <table border="1">
+        <thead>
+          <tr>
+            <th>expression</th>
+            <th>return type</th>
+            <th>assertion/note/pre/post-condition</th>
+          </tr>
+        </thead>
+        <tbody>
+          <tr>
+            <td><tt>X::size_type</tt></td>
+            <td>
+              <del>unsigned integral type</del>
+              <ins>unsigned integer type</ins>
+            </td>
+            <td>a type that can represent the size of the largest object in
+            the allocation model.</td>
+          </tr>
+          <tr>
+            <td><tt>X::difference_type</tt></td>
+            <td>
+              <del>signed integral type</del>
+              <ins>signed integer type</ins>
+            </td>
+            <td>a type that can represent the difference between any two
+            pointers in the allocation model.</td>
+          </tr>
+        </tbody>
+      </table>
+    </blockquote>
+
+    <p>
+      The proposed change makes it clear that <tt>make_signed&lt;T&gt;::type</tt>
+      must be one of the signed integer types as defined in 3.9.1. Ditto for
+      <tt>make_unsigned&lt;T&gt;type</tt> and unsigned integer types.
+      20.5.6.3 [meta.trans.sign] table 48...
+    </p>
+    <blockquote>
+      Table 48: Sign modifications
+      <table border="1">
+        <thead>
+          <tr>
+            <th>Template</th>
+            <th>Comments</th>
+          </tr>
+        </thead>
+        <tbody>
+          <tr>
+            <td>
+              <tt>template &lt;class T&gt; struct make_signed;</tt>
+            </td>
+            <td>
+              If <code>T</code> names a (possibly cv-qualified) <del>signed
+              integral type</del><ins>signed integer type</ins> (3.9.1) then
+              the member typedef <code>type</code> shall name the type
+              <code>T</code>; otherwise, if <code>T</code> names a (possibly
+              cv-qualified) <del>unsigned integral type</del><ins>unsigned
+              integer type</ins> then <code>type</code> shall name the
+              corresponding <del>signed integral type</del><ins>signed
+              integer type</ins>, with the same cv-qualifiers as
+              <code>T</code>; otherwise, <code>type</code> shall name the
+              <del>signed integral type</del><ins>signed integer type</ins>
+              with the smallest rank (4.13) for which <code>sizeof(T) ==
+              sizeof(type)</code>, with the same cv-qualifiers as
+              <code>T</code>.
+
+              <i>Requires:</i> <code>T</code> shall be a (possibly
+              cv-qualified) integral type or enumeration but not a
+              <code>bool</code> type.
+            </td>
+          </tr>
+          <tr>
+            <td>
+              <tt>template &lt;class T&gt; struct make_unsigned;</tt>
+            </td>
+            <td>
+              If <code>T</code> names a (possibly cv-qualified)
+              <del>unsigned integral type</del><ins>unsigned integer
+              type</ins> (3.9.1) then the member typedef <code>type</code>
+              shall name the type <code>T</code>; otherwise, if
+              <code>T</code> names a (possibly cv-qualified) <del>signed
+              integral type</del><ins>signed integer type</ins> then
+              <code>type</code> shall name the corresponding <del>unsigned
+              integral type</del><ins>unsigned integer type</ins>, with the
+              same cv-qualifiers as <code>T</code>; otherwise,
+              <code>type</code> shall name the <del>unsigned integral
+              type</del><ins>unsigned integer type</ins> with the smallest
+              rank (4.13) for which <code>sizeof(T) == sizeof(type)</code>,
+              with the same cv-qualifiers as <code>T</code>.
+
+              <i>Requires:</i> <code>T</code> shall be a (possibly
+              cv-qualified) integral type or enumeration but not a
+              <code>bool</code> type.
+            </td>
+          </tr>
+        </tbody>
+      </table>
+    </blockquote>
+
+
+    <p>
+      Note: I believe that the basefield values should probably be
+      prefixed with <tt>ios_base::</tt> as they are in 22.2.2.2.2 [facet.num.put.virtuals]
+
+      The listed virtuals are all overloaded on signed and unsigned integer
+      types, the new wording just maintains consistency.
+
+      22.2.2.1.2 [facet.num.get.virtuals] table 78...
+    </p>
+    <blockquote>
+      Table 78: Integer Conversions
+      <table border="1">
+        <thead>
+          <tr>
+            <th>State</th>
+            <th><tt>stdio</tt> equivalent</th>
+          </tr>
+        </thead>
+        <tbody>
+          <tr>
+            <td><tt>basefield == oct</tt></td>
+            <td><tt>%o</tt></td>
+          </tr>
+          <tr>
+            <td><tt>basefield == hex</tt></td>
+            <td><tt>%X</tt></td>
+          </tr>
+          <tr>
+            <td><tt>basefield == 0</tt></td>
+            <td><tt>%i</tt></td>
+          </tr>
+          <tr>
+            <td><del>signed integral type</del><ins>signed integer
+            type</ins></td>
+            <td><tt>%d</tt></td>
+          </tr>
+          <tr>
+            <td><del>unsigned integral type</del><ins>unsigned integer
+            type</ins></td>
+            <td><tt>%u</tt></td>
+          </tr>
+        </tbody>
+      </table>
+    </blockquote>
 
+    
+    
+    <p>
+      Rationale is same as above.
+      22.2.2.2.2 [facet.num.put.virtuals] table 80...
+    </p>
+    <blockquote>
+      Table 80: Integer Conversions
+      <table border="1">
+        <thead>
+          <tr>
+            <th>State</th>
+            <th><tt>stdio</tt> equivalent</th>
+          </tr>
+        </thead>
+        <tbody>
+          <tr>
+            <td><tt>basefield == ios_base::oct</tt></td>
+            <td><tt>%o</tt></td>
+          </tr>
+          <tr>
+            <td><tt>(basefield == ios_base::hex) &amp;&amp;
+            !uppercase</tt></td>
+            <td><tt>%x</tt></td>
+          </tr>
+          <tr>
+            <td><tt>(basefield == ios_base::hex)</tt></td>
+            <td><tt>%X</tt></td>
+          </tr>
+          <tr>
+            <td><tt>basefield == 0</tt></td>
+            <td><tt>%i</tt></td>
+          </tr>
+          <tr>
+            <td>for a <del>signed integral type</del><ins>signed integer
+            type</ins></td>
+            <td><tt>%d</tt></td>
+          </tr>
+          <tr>
+            <td>for a <del>unsigned integral type</del><ins>unsigned integer
+            type</ins></td>
+            <td><tt>%u</tt></td>
+          </tr>
+        </tbody>
+      </table>
+    </blockquote>
+
+    
+    <p>
+      23.1 [container.requirements] table 80...
+    </p>
+    <blockquote>
+      Table 89: Container requirements
+      <table border="1">
+        <thead>
+          <tr>
+            <th>expression</th>
+            <th>return type</th>
+            <th>operational semantics</th>
+            <th>assertion/note/pre/post-condition</th>
+            <th>complexity</th>
+          </tr>
+        </thead>
+        <tbody>
+          <tr>
+            <td><tt>X::difference_type</tt></td>
+            <td><del>signed integral type</del><ins>signed integer type</ins></td>
+            <td>&nbsp;</td>
+            <td>is identical to the difference type of <tt>X::iterator</tt>
+            and <tt>X::const_iterator</tt></td>
+            <td>compile time</td>
+          </tr>
+          <tr>
+            <td><tt>X::size_type</tt></td>
+            <td><del>unsigned integral type</del><ins>unsigned integer type</ins></td>
+            <td>&nbsp;</td>
+            <td><tt>size_type</tt> can represent any non-negative value of
+            <tt>difference_type</tt></td>
+            <td>compile time</td>
+          </tr>
+        </tbody>
+      </table>
+    </blockquote>
+
+    <p>
+      24.1 [iterator.requirements] paragraph 1...
+    </p>
+    <blockquote>
+      Iterators are a generalization of pointers that allow a C++ program to
+      work with different data structures (containers) in a uniform manner.
+      To be able to construct template algorithms that work correctly and
+      efficiently on different types of data structures, the library
+      formalizes not just the interfaces but also the semantics and
+      complexity assumptions of iterators. All input iterators
+      <code>i</code> support the expression <code>*i</code>, resulting in a
+      value of some class, enumeration, or built-in type <code>T</code>,
+      called the <i>value type</i> of the iterator. All output iterators
+      support the expression <code>*i = o</code> where <code>o</code> is a
+      value of some type that is in the set of types that are
+      <i>writable</i> to the particular iterator type of <code>i</code>. All
+      iterators <code>i</code> for which the expression <code>(*i).m</code>
+      is well-defined, support the expression <code>i-&gt;m</code> with the
+      same semantics as <code>(*i).m</code>. For every iterator type
+      <code>X</code> for which equality is defined, there is a corresponding
+      <del>signed integral type</del> <ins>signed integer type</ins> called
+      the <i>difference type</i> of the iterator.
+    </blockquote>
+    
+    <p>
+      I'm a little unsure of this change. Previously this paragraph would
+      allow instantiations of <tt>linear_congruential_engine</tt> on
+      <tt>char</tt>, <tt>wchar_t</tt>, <tt>bool</tt>, and other types. The
+      new wording prohibits this.
+      26.4.3.1 [rand.eng.lcong] paragraph 2...
+    </p>
+    <blockquote>
+      The template parameter <code>UIntType</code> shall denote an
+      <del>unsigned integral type</del><ins>unsigned integer type</ins>
+      large enough to store values as large as <code>m - 1</code>. If the
+      template parameter <code>m</code> is 0, the modulus <code>m</code>
+      used throughout this section 26.4.3.1 is
+      <code>numeric_limits&lt;result_type&gt;::max()</code> plus 1.  [Note:
+      The result need not be representable as a value of type
+      <code>result_type</code>. --end note] Otherwise, the following
+      relations shall hold: <code>a &lt; m</code> and <code>c &lt;
+      m</code>.
+    </blockquote>
+    
+    <p>
+      Same rationale as the previous change.
+      26.4.4.4 [rand.adapt.xor] paragraph 6...
+    </p>
+    <blockquote>
+      Both <code>Engine1::result_type</code> and
+      <code>Engine2::result_type</code> shall denote (possibly different)
+      <del>unsigned integral types</del><ins>unsigned integer types</ins>.
+      The member <i>result_type</i> shall denote either the type
+      <i>Engine1::result_type</i> or the type <i>Engine2::result_type</i>,
+      whichever provides the most storage according to clause 3.9.1.
+    </blockquote>
+    
+    <p>
+      26.4.7.1 [rand.util.seedseq] paragraph 7...
+    </p>
+    <blockquote>
+      <i>Requires:</i><code>RandomAccessIterator</code> shall meet the
+      requirements of a random access iterator (24.1.5) such that
+      <code>iterator_traits&lt;RandomAccessIterator&gt;::value_type</code>
+      shall denote an <del>unsigned integral type</del><ins>unsigned integer
+      type</ins> capable of accomodating 32-bit quantities.  
+    </blockquote>
+
+    <p>
+      By making this change, integral types that happen to have a signed
+      representation, but are not signed integer types, would no longer be
+      required to use a two's complement representation. This may go against
+      the original intent, and should be reviewed.
+      29.4 [atomics.types.operations] paragraph 24...
+    </p>
+    <blockquote>
+      <i>Remark:</i> For <del>signed integral types</del><ins>signed integer
+      types</ins>, arithmetic is defined using two's complement
+      representation. There are no undefined results. For address types, the
+      result may be an undefined address, but the operations otherwise have
+      no undefined behavior.
+    </blockquote>
+    
+  
+
+
+
+
+<hr>
+<h3><a name="874"></a>874. Missing <tt>initializer_list</tt> constructor for <tt>discrete_distribution</tt></h3>
+<p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <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>Date:</b> 2008-08-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</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>
-Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of <tt>constexpr</tt> requirements.
+During the Sophia Antipolis meeting it was decided to separate from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a> a
+subrequest that adds initializer list support to
+<tt>discrete_distribution</tt>, specifically,
+the issue proposed to add a c'tor taking a <tt>initializer_list&lt;double&gt;</tt>.
 </p>
 
-<p>
-LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a> is related in that it raises the question of whether the
-exposition only member <tt>cat_</tt> of class <tt>error_code</tt> (19.4.2 [syserr.errcode]) and class
-<tt>error_condition</tt> (19.4.3 [syserr.errcondition]) should be presented as a reference or pointer.
-While in the context of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a> that is arguably an editorial question,
-presenting it as a pointer becomes more or less required with this
-proposal, given <tt>constexpr</tt> does not play well with references. The
-proposed resolution thus changes the private member to a pointer, which
-also brings it in sync with real implementations.
-</p>
 
 
 <p><b>Proposed resolution:</b></p>
+<ol>
+<li>
 <p>
-The proposed wording assumes the LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> proposed wording has been
-applied to the WP, resulting in the former <tt>posix_category</tt> being renamed
-<tt>generic_category</tt>. If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> has not been applied, the names in this
-proposal must be adjusted accordingly.
+In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>,
+just <em>before</em> the member declaration
 </p>
 
+<blockquote><pre>explicit discrete_distribution(const param_type&amp; parm);
+</pre></blockquote>
+
 <p>
-Change 19.4.1.1 [syserr.errcat.overview] Class
-<tt>error_category</tt> overview <tt>error_category</tt> synopsis  as
-indicated:
+insert
 </p>
 
-<blockquote><pre><del>const error_category&amp; get_generic_category();</del>
-<del>const error_category&amp; get_system_category();</del>
-
-<del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>;
-<del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>native_category</del> system_category<del> = get_system_category()</del>;
+<blockquote><pre>discrete_distribution(initializer_list&lt;double&gt; wl);
 </pre></blockquote>
+</li>
 
+<li>
 <p>
-Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated:
+Between p.4 and p.5 of the same section insert a new
+paragraph as part of the new member description:
 </p>
 
-<blockquote>
-<pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>;
+<blockquote><pre>discrete_distribution(initializer_list&lt;double&gt; wl);
 </pre>
-<p>
-<del><i>Returns:</i> A reference</del> <ins><tt>generic_category</tt> shall point</ins>
-to <del>an</del> <ins>a statically initialized</ins> object of a type derived from
-class <tt>error_category</tt>.
-</p>
 
-<p>
-<del><i>Remarks:</i></del> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
-functions shall behave as specified for the class <tt>error_category</tt>. The
-object's <tt>name</tt> virtual function shall return a pointer to the string
-<tt>"GENERIC"</tt>.
-</p>
+<blockquote>
+<i>Effects:</i> Same as <tt>discrete_distribution(wl.begin(), wl.end())</tt>.
+</blockquote>
+</blockquote>
+</li>
+</ol>
 
-<pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>;
-</pre>
 
-<p>
-<del><i>Returns:</i> A reference</del> <ins><tt>system_category</tt> shall point</ins>
-to <del>an</del> <ins>a statically
-initialized</ins> object of a type derived from class <tt>error_category</tt>.
-</p>
 
-<p>
-<del><i>Remarks:</i></del>  The object's <tt>equivalent</tt> virtual functions shall behave as
-specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
-shall return a pointer to the string <tt>"system"</tt>. The object's
-<tt>default_error_condition</tt> virtual function shall behave as follows:
-</p>
 
+
+<hr>
+<h3><a name="875"></a>875. Missing <tt>initializer_list</tt> constructor for <tt>piecewise_constant_distribution</tt></h3>
+<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <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>Date:</b> 2008-08-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</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 the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function
-shall return <tt>error_condition(posv, generic_category)</tt>. Otherwise, the
-function shall return <tt>error_condition(ev, system_category)</tt>. What
-constitutes correspondence for any given operating system is
-unspecified. [<i>Note:</i> The number of potential system error codes is large
-and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value.
-Thus implementations are given latitude in determining correspondence.
-<i>-- end note</i>]
+During the Sophia Antipolis meeting it was decided to separate from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a> a subrequest that adds initializer list support to
+<tt>piecewise_constant_distribution</tt>, specifically, the issue proposed
+to add a c'tor taking a <tt>initializer_list&lt;double&gt;</tt> and a <tt>Callable</tt> to evaluate
+weight values. For consistency with the remainder of this class and
+the remainder of the <tt>initializer_list</tt>-aware library the author decided to
+change the list argument type to the template parameter <tt>RealType</tt>
+instead. For the reasoning to use <tt>Func</tt> instead of <tt>Func&amp;&amp;</tt> as c'tor
+function argument see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>.
 </p>
-</blockquote>
 
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
 <p>
-Change 19.4.2.1 [syserr.errcode.overview] Class <tt>error_code</tt> overview as indicated:
+In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
+just <em>before</em> the member declaration
 </p>
 
-<blockquote><pre>class error_code {
-public:
-  ...;
-  <ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
-  ...
-  void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
-  ...
-  const error_category<del>&amp;</del><ins>*</ins> category() const;
-  ...
-private:
-  int val_;                    // exposition only
-  const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
+<blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
 </pre></blockquote>
 
 <p>
-Change 19.4.2.2 [syserr.errcode.constructors] Class <tt>error_code</tt> constructors as indicated:
+insert
 </p>
 
-<blockquote>
-<pre><ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
-</pre>
-<p>
-<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
+<blockquote><pre>template&lt;typename Func&gt;
+piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
+</pre></blockquote>
+</li>
 
+<li>
 <p>
-Change 19.4.2.3 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers  as indicated:
+Between p.4 and p.5 of the same section insert a series of
+new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
+as part of the new member description:
 </p>
 
-<blockquote>
-<pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+<blockquote><pre>template&lt;typename Func&gt;
+piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
 </pre>
+
+<blockquote>
+
 <p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
+[p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>.
 </p>
-</blockquote>
 
 <p>
-Change 19.4.2.4 [syserr.errcode.observers] Class <tt>error_code</tt> observers  as indicated:
+[p5_2] <i>Requires:</i>
 </p>
 
-<blockquote>
-<pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
-</pre>
+<ol type="a">
+<li>
+<tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
+   return values of a type convertible to <tt>double</tt>;
+</li>
+<li>
+The relation <tt>0 &lt; S = w<sub>0</sub>+. . .+w<sub>n-1</sub></tt> shall hold. 
+For all sampled values <tt><i>x<sub>k</sub></i></tt> defined below, <tt>fw(<i>x<sub>k</sub></i>)</tt> shall return a weight
+   value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
+</li>
+<li>
+If <tt>nf &gt; 0</tt> let <tt>b<sub><i>k</i></sub> = *(bl.begin() + k), k = 0, . . . , bl.size()-1</tt> and the
+following relations shall hold for <tt>k = 0, . . . , nf-1: b<sub><i>k</i></sub> &lt; b<sub><i>k+1</i></sub></tt>.
+</li>
+</ol>
 
 <p>
-<i>Returns:</i> <tt>cat_</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
+[p5_3] <i>Effects:</i>
 </p>
-</blockquote>
 
+<ol type="a">
+<li>
+<p>If <tt>nf == 0</tt>,</p>
+<ol type="a">
+<li>
+lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
+     value <tt>w<sub>0</sub> = 1</tt>, and
+</li>
+<li>
+lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt>b<sub>0</sub> = 0</tt> and <tt>b<sub>1</sub> = 1</tt>.
+</li>
+</ol>
+</li>
+
+<li>
+<p>Otherwise,</p>
+<ol type="a">
+<li>
+sets <tt>n = nf</tt>, and <tt>[bl.begin(), bl.end())</tt> shall form the sequence <tt>b</tt> of
+length <tt>n+1</tt>, and
+</li>
+<li>
+<p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>,
+     calculates:</p>
+<blockquote><pre>x<sub><i>k</i></sub> = 0.5*(b<sub><i>k+1</i></sub> + b<sub><i>k</i></sub>)
+w<sub><i>k</i></sub> = fw(x<sub><i>k</i></sub>)
+</pre></blockquote>
+</li>
+</ol>
+</li>
+
+<li>
 <p>
-Change 19.4.3.1 [syserr.errcondition.overview] Class <tt>error_condition</tt> overview   as indicated:
+Constructs a <tt>piecewise_constant_distribution</tt> object with
+the above computed sequence <tt>b</tt> as the interval boundaries
+and with the probability densities:
 </p>
+<blockquote><pre>&#961;<sub><i>k</i></sub> = w<sub><i>k</i></sub>/(S * (b<sub><i>k+1</i></sub> - b<sub><i>k</i></sub>)) for k = 0, . . . , n-1.
+</pre></blockquote>
+
+</li>
+</ol>
 
-<blockquote>
-<pre>class error_condition {
-public:
-  ...;
-  <ins>constexpr</ins> error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
-  ...
-  void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
-  ...
-  const error_category<del>&amp;</del><ins>*</ins> category() const;
-  ...
-private:
-  int val_;                    // exposition only
-  const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
-</pre>
 </blockquote>
+</blockquote>
+</li>
+</ol>
 
-<p>
-Change 19.4.3.2 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated:
-</p>
 
-<blockquote>
-<pre>constexpr error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
-</pre>
+
+
+
+<hr>
+<h3><a name="876"></a>876. <tt>basic_string</tt> access operations should give stronger guarantees</h3>
+<p><b>Section:</b> 21.3 [basic.string] <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>Date:</b> 2008-08-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
+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>
 <p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
+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.
 </p>
 <p>
-<i>Throws:</i> Nothing.
+Due to earlier support for copy-on-write, we find the following
+unnecessary limitations for C++0x:
 </p>
-</blockquote>
+
+<ol>
+<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.
+</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.
+</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.
+</li>
+</ol>
 
 <p>
-Change 19.4.3.3 [syserr.errcondition.modifiers] Class <tt>error_condition</tt> modifiers as indicated:
+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.
 </p>
 
-<blockquote>
-<pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
-</pre>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
+
+<p><b>Proposed resolution:</b></p>
+<ol type="A">
+<li>
+<ol>
+<li>
+<p>In 21.3.4 [string.capacity], just after p. 1 add a new paragraph:
 </p>
-<p>
+<blockquote>
 <i>Throws:</i> Nothing.
-</p>
 </blockquote>
 
+</li>
+<li>
 <p>
-Change 19.4.3.4 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated:
+In 21.3.5 [string.access] <em>replace</em> p. 1 by the following <em>4</em> paragraghs:
 </p>
 
 <blockquote>
-<pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
-</pre>
-<p>
-<i>Returns:</i> <tt>cat_</tt>.
-</p>
 <p>
-<i>Throws:</i> Nothing.
+<i>Requires:</i> <tt>pos &#8804; size()</tt>.
 </p>
-</blockquote>
-
 <p>
-Throughout 19.4 [syserr] System error support, change "<tt>category().</tt>"  to "<tt>category()-&gt;</tt>".
-Appears approximately six times.
+<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.
 </p>
-
 <p>
-<i>[Partially Editorial]</i> In 19.4.4 [syserr.compare] Comparison operators,
-paragraphs 2 and 4, change "<tt>category.equivalent(</tt>"  to
-"<tt>category()-&gt;equivalent(</tt>".
+<i>Throws:</i> Nothing.
 </p>
-
-
-
-
-
-<hr>
-<h3><a name="833"></a>833. Freestanding implementations header list needs review for C++0x</h3>
-<p><b>Section:</b> 17.4.1.3 [compliance] <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>Date:</b> 2008-05-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>
-Once the C++0x standard library is feature complete, the LWG needs to
-review 17.4.1.3 [compliance] Freestanding implementations header list to
-ensure it reflects LWG consensus.
+<p>
+<i>Complexity:</i> Constant time.
 </p>
+</blockquote>
 
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3>
-<p><b>Section:</b> 20.6.11.2 [unique.ptr.single] <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>Date:</b> 2008-05-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>
+</li>
+<li>
 <p>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> (including recent updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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 21.3.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:
 </p>
+<blockquote>
 <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>:
+<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>.
 </p>
-
-<ol>
-<li>Operational fail-safety.</li>
-<li>(Well-)Definedness of expressions.</li>
-</ol>
-
 <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-active.html#762">762</a>).
+<i>Throws:</i> Nothing.
 </p>
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Add the following sentence just at the end of the newly proposed
-20.6.11.2 [unique.ptr.single]/p. 3:
+<i>Complexity:</i> Constant time.
+</p>
+</blockquote>
+</li>
+</ol>
+</li>
+<li>
+<ol start="4">
+<li>
+<p>
+In 21.3.5 [string.access] <em>replace</em> p.2 and p.3 by:
 </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.
+<p>
+<i>Requires:</i> <tt>pos &#8804; size()</tt>
+</p>
+<p>
+<i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; size()</tt>.
+</p>
 </blockquote>
+</li>
+</ol>
+</li>
+</ol>
+
 
 
 
 
 
 <hr>
-<h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3>
-<p><b>Section:</b> 27.4.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> Martin Sebor <b>Date:</b> 2008-05-17</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>
+<h3><a name="877"></a>877. to <tt>throw()</tt> or to <i>Throw:</i> Nothing.</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> Martin Sebor <b>Date:</b> 2008-08-23</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>
 
-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.
+Recent changes to
+the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">working
+draft</a> have introduced a gratuitous inconsistency with the C++ 2003
+version of the specification with respect to exception guarantees
+provided by standard functions. While the C++ 2003 standard
+consistenly uses the empty exception specification, <tt>throw()</tt>,
+to declare functions that are guaranteed not to throw exceptions, the
+current working draft contains a number of "<i>Throws:</i> Nothing."
+clause to specify essentially the same requirement. The difference
+between the two approaches is that the former specifies the behavior
+of programs that violate the requirement (<tt>std::unexpected()</tt>
+is called) while the latter leaves the behavior undefined.
 
        </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>
+A survey of the working draft reveals that there are a total of 209
+occurrences of <tt>throw()</tt> in the library portion of the spec,
+the majority in clause 18, a couple (literally) in 19, a handful in
+20, a bunch in 22, four in 24, one in 27, and about a dozen in D.9.
 
        </p>
-       <blockquote>
-           <pre>#include &lt;iostream&gt;
-
-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>
-   
-   <p><b>Proposed resolution:</b></p>
        <p>
 
-I think an easy way to plug the first hole is to add a requires clause
-to <code>ostream::tie(ostream *tiestr)</code> requiring the this
-pointer not be equal to any pointer on the list starting
-with <code>tiestr-&gt;tie()</code>
-through <code>tiestr()-&gt;tie()-&gt;tie()</code> and so on. I am not
-proposing that we require implementations to traverse this list,
-although I think we could since the list is unlikely to be very long.
+There are also 203 occurrences of "<i>Throws:</i> Nothing." scattered
+throughout the spec.
 
        </p>
        <p>
 
-Add a <i>Requires</i> clause to 27.4.4.2 [basic.ios.members] withethe following
-text:
+While sometimes there are good reasons to use the "<i>Throws:</i>
+Nothing."  approach rather than making use of <tt>throw()</tt>, these
+reasons do not apply in most of the cases where this new clause has
+been introduced and the empty exception specification would be a
+better approach.
 
        </p>
-       <blockquote>
-
-<i>Requires:</i> If <code>(tiestr != 0)</code> is
-true, <code>tiestr</code> must not be reachable by traversing the
-linked list of tied stream objects starting
-from <code>tiestr-&gt;tie()</code>.
-
-       </blockquote>
        <p>
 
-In addition, to prevent the infinite recursion that Bo writes about in
-his comp.lang.c++.moderated post, I propose to change
-27.6.2.4 [ostream::sentry], p2 like so:
+First, functions declared with the empty exception specification
+permit compilers to generate better code for calls to such
+functions. In some cases, the compiler might even be able to eliminate
+whole chunks of user-written code when instantiating a generic
+template on a type whose operations invoked from the template
+specialization are known not to throw. The prototypical example are
+the <tt>std::uninitialized_copy()</tt>
+and <tt>std::uninitialized_fill()</tt> algorithms where the
+entire <tt>catch(...)</tt> block can be optimized away.
 
        </p>
-       <blockquote>
-
-If <code>((os.flags() &amp; ios_base::unitbuf) &amp;&amp;
-!uncaught_exception())</code> is true,
-calls <del>os.flush()</del> <ins><code>os.rdbuf()-&gt;pubsync()</code></ins>.
-
-       </blockquote>
-   
-
-
-
-<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.2.6.1.2 [locale.money.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> Martin Sebor <b>Date:</b> 2008-05-17</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#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
        <p>
 
-In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following:
+For example, given the following definition of
+the <tt>std::uninitialized_copy</tt> function template and a
+user-defined type <tt>SomeType</tt>:
 
        </p>
        <blockquote>
+           <pre>template &lt;class InputIterator, class ForwardIterator&gt;
+ForwardIterator
+uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res)
+{
+   typedef iterator_traits&lt;ForwardIterator&gt;::value_type ValueType;
+
+   ForwardIterator start = res;
+
+   try {
+       for (; first != last; ++first, ++res)
+           ::new (&amp;*res) ValueType (*first);
+   }
+   catch (...) {
+       for (; start != res; --start)
+           (&amp;*start)-&gt;~ValueType ();
+       throw;
+   }
+   return res;
+}
 
-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.
-
+struct SomeType {
+   SomeType (const SomeType&amp;) <ins>throw ()</ins>;
+}</pre>
        </blockquote>
        <p>
 
-This requirement can be (and has been) interpreted two mutually
-exclusive ways by different readers. One possible interpretation
-is that:
+compilers are able to emit the following efficient specialization
+of <tt>std::uninitialized_copy&lt;const SomeType*, SomeType*&gt;</tt>
+(note that the <tt>catch</tt> block has been optimized away):
 
        </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.
+           <pre>template &lt;&gt; SomeType*
+uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res)
+{
+   for (; first != last; ++first, ++res)
+       ::new (res) SomeType (*first);
 
-               </li>
-           </ol>
+   return res;
+}</pre>
        </blockquote>
        <p>
 
-The other is that:
+Another general example is default constructors which, when decorated
+with <tt>throw()</tt>, allow the compiler to eliminate the
+implicit <tt>try</tt> and <tt>catch</tt> blocks that it otherwise must
+emit around each the invocation of the constructor
+in <i>new-expressions</i>.
 
        </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><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.2.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. In either case, any required followed by all optional white
-space (as recognized by <code>ct.is()</code>) is consumed.</ins>
-If <code>(str.flags() &amp; str.showbase)</code> is <code>false</code>, ...
-
-       </blockquote>
-   
-
-
-
-<hr>
-<h3><a name="837"></a>837. 
-   <code>basic_ios::copyfmt()</code> overly loosely specified
- </h3>
-<p><b>Section:</b> 27.4.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> Martin Sebor <b>Date:</b> 2008-05-17</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>
-   <p>
-
-The <code>basic_ios::copyfmt()</code> member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects:
-
-   </p>
-   <blockquote>
-
-<i>Effects</i>: If <code>(this == &amp;rhs)</code> does
-nothing. Otherwise assigns to the member objects of <code>*this</code>
-the corresponding member objects of <code>rhs</code>, except that
-
-     <ul>
-       <li>
-
-<code>rdstate()</code> and <code>rdbuf()</code> are left unchanged;
-
-       </li>
-       <li>
-
-<code>exceptions()</code> is altered last by
-calling <code>exceptions(rhs.except)</code>
-
-       </li>
-       <li>
-
-the contents of arrays pointed at by <code>pword</code>
-and <code>iword</code> are copied not the pointers themselves
-
-       </li>
-     </ul>
-   </blockquote>
-   <p>
-
-Since the rest of the text doesn't specify what the member objects
-of <code>basic_ios</code> are this seems a little too loose.
-
-   </p>
- 
+For example, given the following definitions of
+class <tt>MayThrow</tt> and <tt>WontThrow</tt> and the two
+statements below:
 
- <p><b>Proposed resolution:</b></p>
-   <p>
+       </p>
+       <blockquote>
+           <pre>struct MayThrow {
+   MayThrow ();
+};
 
-I propose to tighten things up by adding a <i>Postcondition</i> clause
-to the function like so:
+struct WontThrow {
+   WontThrow () <ins>throw ()</ins>;
+};
 
-   </p>
-   <blockquote>
-     <i>Postconditions:</i>
+MayThrow  *a = new MayThrow [N];
+WontThrow *b = new WontThrow [N];</pre>
 
-     <table border="1">
-       <thead>
-         <tr>
-           <th colspan="2"><code>copyfmt()</code> postconditions</th>
-         </tr>
-         <tr>
-           <th>Element</th>
-           <th>Value</th>
-         </tr>
-       </thead>
-       <tbody>
-         <tr>
-           <td><code>rdbuf()</code></td>
-           <td><i>unchanged</i></td>
-         </tr>
-         <tr> 
-           <td><code>tie()</code></td>
-           <td><code>rhs.tie()</code></td>
-         </tr>
-         <tr> 
-           <td><code>rdstate()</code></td>
-           <td><i>unchanged</i></td>
-         </tr>
-         <tr> 
-           <td><code>exceptions()</code></td>
-           <td><code>rhs.exceptions()</code></td>
-         </tr>
-         <tr> 
-           <td><code>flags()</code></td>
-           <td><code>rhs.flags()</code></td>
-         </tr>
-         <tr> 
-           <td><code>width()</code></td>
-           <td><code>rhs.width()</code></td>
-         </tr>
-         <tr> 
-           <td><code>precision()</code></td>
-           <td><code>rhs.precision()</code></td>
-         </tr>
-         <tr> 
-           <td><code>fill()</code></td>
-           <td><code>rhs.fill()</code></td>
-         </tr>
-         <tr> 
-           <td><code>getloc()</code></td>
-           <td><code>rhs.getloc()</code></td>
-         </tr>
-       </tbody>
-     </table>
-   </blockquote>
-   <p>
+       </blockquote>
+       <p>
 
-The format of the table follows Table 117 (as
-of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2588.pdf">N2588</a>): <code>basic_ios::init()</code>
-effects.
+the compiler generates the following code for the first statement:
 
-   </p>
-   <p>
+       </p>
+       <blockquote>
+           <pre>MayThrow *a;
+{
+   MayThrow *first = operator new[] (N * sizeof (*a));
+   MayThrow *last  = first + N;
+   MayThrow *next  = first;
+   try {
+       for ( ; next != last; ++next)
+           new (next) MayThrow;
+   }
+   catch (...) {
+       for ( ; first != first; --next)
+           next-&gt;~MayThrow ();
+       operator delete[] (first);
+       throw;
+   }
+   a = first;
+}</pre>
+       </blockquote>
+       <p>
 
-The intent of the new table is not to impose any new requirements or
-change existing ones, just to be more explicit about what I believe is
-already there.
+but it is can generate much more compact code for the second statement:
 
-   </p>
- 
+       </p>
+       <blockquote>
+           <pre>WontThrow *b    = operator new[] (N * sizeof (*b));
+WontThrow *last = b + N;
+for (WontThrow *next = b; next != last; ++next)
+   new (next) WontThrow;
+</pre>
+       </blockquote>
+       <p>
 
+Second, in order for users to get the maximum benefit out of the new
+<tt>std::has_nothrow_xxx</tt> traits when using standard library types
+it will be important for implementations to decorate all non throwing
+copy constructors and assignment operators with <tt>throw()</tt>. Note
+that while an optimizer may be able to tell whether a function without
+an explicit exception specification can throw or not based on its
+definition, it can only do so when it can see the source code of the
+definition. When it can't it must assume that the function may
+throw. To prevent violating the One Definition Rule,
+the <tt>std::has_nothrow_xxx</tt> trait must return the most
+pessimistic guess across all translation units in the program, meaning
+that <tt>std::has_nothrow_xxx&lt;T&gt;::value</tt> must evaluate to
+<tt>false</tt> for any <tt>T</tt> whose <tt>xxx</tt>
+(where <tt>xxx</tt> is default or copy ctor, or assignment operator)
+is defined out-of-line.
 
+       </p>
+       <p>
 
-<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.5.1 [istream.iterator] <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>Date:</b> 2008-05-17</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#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-   <p>
+<b>Counterarguments:</b>
 
-From message c++std-lib-20003...
+       </p>
+       <p>
 
-   </p>
-   <p>
+During the discussion of this issue
+on <a href="mailto:c++std-lib@accu.org">c++std-lib@accu.org</a>
+(starting with post <tt>c++std-lib-21950</tt>) the following arguments
+in favor of the "<i>Throws:</i> Nothing." style have been made.
 
-The description of <code>istream_iterator</code> in
-24.5.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#836">836</a> another problem
-with this paragraph):
+       </p>
+       <p>
+         </p><ol>
+           <li>
+
+Decorating functions that cannot throw with the empty exception
+specification can cause the compiler to generate suboptimal code for
+the implementation of the function when it calls other functions that
+aren't known to the compiler not to throw (i.e., that aren't decorated
+with <tt>throw()</tt> even if they don't actually throw). This is a
+common situation when the called function is a C or POSIX function.
+
+           </li>
+           <li>
+
+Alternate, proprietary mechanisms exist (such as
+GCC <a href="http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#index-g_t_0040code_007bnothrow_007d-function-attribute-2160"><tt>__attribute__((nothrow))</tt></a>
+or Visual
+C++ <a href="http://msdn.microsoft.com/en-us/library/49147z04%28VS.80%29.aspx"><tt>__declspec(nothrow)</tt></a>)
+that let implementers mark up non-throwing functions, often without
+the penalty mentioned in (1) above. The C++ standard shouldn't
+preclude the use of these potentially more efficient mechanisms.
+
+           </li>
+           <li>
+
+There are functions, especially function templates, that invoke
+user-defined functions that may or may not be
+declared <tt>throw()</tt>. Declaring such functions with the empty
+exception specification will cause compilers to generate suboptimal
+code when the user-defined function isn't also declared not to throw.
+
+           </li>
+        </ol>
+       
+       <p>
 
-   </p>
-   <blockquote>
+The answer to point (1) above is that implementers can (and some have)
+declare functions with <tt>throw()</tt> to indicate to the compiler
+that calls to the function can safely be assumed not to throw in order
+to allow it to generate efficient code at the call site without also
+having to define the functions the same way and causing the compiler
+to generate suboptimal code for the function definition. That is, the
+function is declared with <tt>throw()</tt> in a header but it's
+defined without it in the source file. The <tt>throw()</tt>
+declaration is suppressed when compiling the definition to avoid
+compiler errors. This technique, while strictly speaking no permitted
+by the language, is safe and has been employed in practice. For
+example, the GNU C library takes this approach. Microsoft Visual C++
+takes a similar approach by simply assuming that no function with C
+language linkage can throw an exception unless it's explicitly
+declared to do so using the language extension <tt>throw(...)</tt>.
 
-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.
+       </p>
+       <p>
 
-   </blockquote>
-   <p>
+Our answer to point (2) above is that there is no existing practice
+where C++ Standard Library implementers have opted to make use of the
+proprietary mechanisms to declare functions that don't throw. The
+language provides a mechanism specifically designed for this
+purpose. Avoiding its use in the specification itself in favor of
+proprietary mechanisms defeats the purpose of the feature. In
+addition, making use of the empty exception specification
+inconsistently, in some areas of the standard, while conspicuously
+avoiding it and making use of the "<i>Throws:</i> Nothing." form in
+others is confusing to users.
 
-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>
 
-   </p>
-   <p>
+The answer to point (3) is simply to exercise caution when declaring
+functions and especially function templates with the empty exception
+specification. Functions that required not to throw but that may call
+back into user code are poor candidates for the empty exception
+specification and should instead be specified using "<i>Throws:</i>
+Nothing." clause.
 
-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><b>Proposed resolution:</b></p>
+       <p>
 
-   </p>
-   <p>
+We propose two possible solutions. Our recommendation is to adopt
+Option 1 below.
 
-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>
 
-   </p>
-   <p>
+<b>Option 1:</b>
 
-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>
+       <p>
 
-   </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>
+Except for functions or function templates that make calls back to
+user-defined functions that may not be declared <tt>throw()</tt>
+replace all occurrences of the "<i>Throws:</i> Nothing." clause with
+the empty exception specification. Functions that are required not to
+throw but that make calls back to user code should be specified to
+"<i>Throw:</i> Nothing."
 
-Or is it intended that once an iterator becomes EOS it stays EOS until
-the end of its lifetime?
+       </p>
+       <p>
 
-   </p>
- 
+<b>Option 2:</b>
 
- <p><b>Proposed resolution:</b></p>
-   <p>
+       </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.
+For consistency, replace all occurrences of the empty exception
+specification with a "<i>Throws:</i> Nothing." clause.
 
-   </p>
-   <p>
+       </p>
+   
 
-To this end we propose to change 24.5.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...
+<hr>
+<h3><a name="878"></a>878. <tt>forward_list</tt> preconditions</h3>
+<p><b>Section:</b> 23.2.3 [forwardlist] <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>Date:</b> 2008-08-23</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>
 
-   </blockquote>
-   <p>
+<tt>forward_list</tt> member functions that take
+a <tt>forward_list::iterator</tt> (denoted <tt>position</tt> in the
+function signatures) argument have the following precondition:
 
-Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so:
+       </p>
+       <blockquote>
 
-   </p>
-   <blockquote>
+<i>Requires:</i> <tt>position</tt> is dereferenceable or equal
+to <tt>before_begin()</tt>.
 
-<pre>istream_iterator();</pre>
+       </blockquote>
+       <p>
 
-<i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br>
-<ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins>
+I believe what's actually intended is this:
 
-<pre>istream_iterator(istream_type &amp;s);</pre>
+       </p>
+       <blockquote>
 
-<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>
+<i>Requires:</i> <tt>position</tt> is in the range
+[<tt>before_begin()</tt>, <tt>end()</tt>).
 
-<pre>istream_iterator(const istream_iterator &amp;x);</pre>
+       </blockquote>
+       <p>
 
-<i>Effects</i>: Constructs a copy of <code>x</code>.<br>
-<ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins>
+That is, when it's dereferenceable, <tt>position</tt> must point
+into <tt>*this</tt>, not just any <tt>forward_list</tt> object.
 
-<pre>istream_iterator&amp; operator++();</pre>
+       </p>
+   
+   <p><b>Proposed resolution:</b></p>
+       <p>
 
-<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
-<i>Effects</i>: <code>*in_stream &gt;&gt; value</code>.
+Change the <i>Requires</i> clause as follows:
 
-<pre>istream_iterator&amp; operator++(int);</pre>
+       </p>
+       <blockquote>
 
-<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>
- 
+<i>Requires:</i> <tt>position</tt> is <ins>in the range
+[<tt>before_begin()</tt>, <tt>end()</tt>)</ins> <del>dereferenceable
+or equal to <tt>before_begin()</tt></del>.
 
+       </blockquote>
+   
 
 
 
diff --git a/libstdc++-v3/doc/html/ext/lwg-closed.html b/libstdc++-v3/doc/html/ext/lwg-closed.html
index 68bca50..a056c3e 100644 (file)
--- a/libstdc++-v3/doc/html/ext/lwg-closed.html
+++ b/libstdc++-v3/doc/html/ext/lwg-closed.html
@@ -1,22 +1,24 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
-<html><head><title>C++ Standard Library Closed Issues List</title>
-
+<html><head>
+<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
 
 
+<title>C++ Standard Library Closed Issues List</title>
 <style type="text/css">
 p {text-align:justify}
 li {text-align:justify}
 ins {background-color:#A0FFA0}
 del {background-color:#FFA0A0}
-</style></head><body>
+</style>
+</head><body>
 <table>
 <tbody><tr>
 <td align="left">Doc. no.</td>
-<td align="left">N2614=08-0124</td>
+<td align="left">N2729=08-0239</td>
 </tr>
 <tr>
 <td align="left">Date:</td>
-<td align="left">2008-05-18</td>
+<td align="left">2008-08-24</td>
 </tr>
 <tr>
 <td align="left">Project:</td>
@@ -27,7 +29,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 Closed Issues List (Revision R56)</h1>
+<h1>C++ Standard Library Closed Issues List (Revision R59)</h1>
 
   <p>Reference ISO/IEC IS 14882:1998(E)</p>
   <p>Also see:</p>
@@ -49,6 +51,67 @@ del {background-color:#FFA0A0}
 
 <h2>Revision History</h2>
 <ul>
+<li>R59: 
+2008-08-22 pre-San Francisco mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>192 open issues, up by 9.</li>
+<li>686 closed issues, up by 0.</li>
+<li>878 issues total, up by 9.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="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-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R58: 
+2008-07-28 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>183 open issues, up by 12.</li>
+<li>686 closed issues, down by 4.</li>
+<li>869 issues total, up by 8.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#864">864</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#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</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#869">869</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#393">393</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#592">592</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 Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
+<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>.</li>
+<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R57: 
+2008-06-27 post-Sophia Antipolis mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>171 open issues, down by 20.</li>
+<li>690 closed issues, up by 43.</li>
+<li>861 issues total, up by 23.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following NAD issues: <a href="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-active.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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 Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li>
+<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>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-active.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-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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 New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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>
+</ul></li>
+</ul>
+</li>
 <li>R56: 
 2008-05-16 pre-Sophia Antipolis mailing.
 <ul>
@@ -58,7 +121,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-active.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-active.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-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
@@ -76,7 +139,7 @@ del {background-color:#FFA0A0}
 <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-active.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-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>.</li>
 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#803">803</a>.</li>
-<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#798">798</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>
 <li>Changed the following issues from NAD Future to NAD: <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#323">323</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#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</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>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li>
@@ -85,13 +148,13 @@ 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-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-closed.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 New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-closed.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#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</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-active.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-active.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-active.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-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
@@ -108,7 +171,7 @@ del {background-color:#FFA0A0}
 <li>787 issues total, up by 23.</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#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <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#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</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-closed.html#767">767</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-active.html#769">769</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-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</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-active.html#776">776</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-active.html#779">779</a>, <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-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-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <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-active.html#787">787</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#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</li>
 <li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</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#697">697</a>.</li>
@@ -126,7 +189,7 @@ del {background-color:#FFA0A0}
 <li>764 issues total, up by 10.</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#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>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-active.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-active.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-active.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 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>
@@ -141,16 +204,16 @@ del {background-color:#FFA0A0}
 <li>754 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#724">724</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-active.html#726">726</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#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</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#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</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#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li>
+<li>Added the following New issues: <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#725">725</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-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</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#739">739</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-closed.html#741">741</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-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-closed.html#745">745</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-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</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-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</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#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-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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#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-active.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-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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#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-active.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-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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-active.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>
+<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-active.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-active.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>
 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</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#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</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-active.html#672">672</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-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</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#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-closed.html#645">645</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-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-active.html#691">691</a>.</li>
 <li>Changed the following issues from New to WP: <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#634">634</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#678">678</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#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>.</li>
 <li>Changed the following issues from Open to WP: <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#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</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#488">488</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#660">660</a>.</li>
@@ -166,7 +229,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-closed.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
 </ul></li>
 </ul>
 </li>
@@ -187,10 +250,10 @@ 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#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-closed.html#633">633</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#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-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-closed.html#656">656</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#579">579</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-defects.html#680">680</a>.</li>
 <li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
-<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#644">644</a>.</li>
+<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</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#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</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#488">488</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#518">518</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#518">518</a>.</li>
 <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
 <li>Changed the following issues from DR to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</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#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#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-defects.html#646">646</a>.</li>
@@ -206,7 +269,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-active.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-active.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-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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 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>
@@ -223,7 +286,7 @@ 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-active.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-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-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-active.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-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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 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>
@@ -233,7 +296,7 @@ del {background-color:#FFA0A0}
 <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-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-closed.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-defects.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 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-active.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>
 <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</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#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>.</li>
@@ -250,9 +313,9 @@ 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-active.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-active.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-active.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-defects.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-active.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-active.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-active.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-closed.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-active.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-active.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-active.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-closed.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-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>
@@ -284,7 +347,7 @@ del {background-color:#FFA0A0}
 <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#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#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> to WP.</li>
 <li>Moved issues <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#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#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-closed.html#558">558</a> to NAD.</li>
 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</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#542">542</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-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
+<li>Moved issues <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-active.html#523">523</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#542">542</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-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
 <li>Moved issues <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-closed.html#549">549</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#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a> to Ready.</li>
 <li>Moved issues <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> to Review.</li>
 <li>Added new issues <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#609">609</a>.</li>
@@ -373,7 +436,7 @@ Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.ht
 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#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-active.html#518">518</a> from New to Review.
+Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
 </li>
 <li>R38: 
 2005-07-03 pre-Mont Tremblant mailing.
@@ -617,7 +680,7 @@ exists.)</p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Change 20.4.4.3 [meta.unary.prop] paragraph 1 Effects from 
+<p>Change 20.5.4.3 [meta.unary.prop] paragraph 1 Effects from 
 "Calls p-&gt;release()" to "Calls p.release()".</p>
 
 
@@ -980,7 +1043,7 @@ otherwise possible. </p>
 
 <hr>
 <h3><a name="82"></a>82. Missing constant for set elements</h3>
-<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</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#NAD">NAD</a> status.</p>
@@ -1212,7 +1275,7 @@ may be provided by a non-Standard implementation class:</p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Add a new subclause [presumably 17.4.4.9] following 17.4.4.8 [res.on.exception.handling]:</p>
+<p>Add a new subclause [presumably 17.4.4.9] following 17.4.4.9 [res.on.exception.handling]:</p>
 
 <blockquote>
   <p>17.4.4.9 Template Parameters</p> <p>A specialization of a
@@ -1385,7 +1448,7 @@ expressed in a single line of code (where <tt>v</tt> is
 
 <hr>
 <h3><a name="102"></a>102. Bug in insert range in associative containers</h3>
-<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</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#Dup">Dup</a> status.</p>
@@ -1579,7 +1642,7 @@ desired functionality.</p>
  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-11-06</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#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a></p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a></p>
 <p><b>Discussion:</b></p>
 
 
@@ -1958,7 +2021,7 @@ set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 [facet.num.put.virtu
 
 <hr>
 <h3><a name="149"></a>149. Insert should return iterator to first element inserted</h3>
-<p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
+<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-06-28</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#NAD%20Future">NAD Future</a> status.</p>
@@ -2297,7 +2360,7 @@ iterators.</p>
 
 <hr>
 <h3><a name="192"></a>192. a.insert(p,t) is inefficient and overconstrained</h3>
-<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Ed Brey <b>Date:</b> 1999-06-06</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#NAD">NAD</a> status.</p>
@@ -2343,7 +2406,7 @@ providing no disadvantage to the container implementation.</p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>In 23.1.2 [associative.reqmts] paragraph 7, replace the row in table 69
+<p>In 23.1.4 [associative.reqmts] paragraph 7, replace the row in table 69
 for a.insert(p,t) with the following two rows:</p>
 <table border="1" cellpadding="5">
   <tbody><tr>
@@ -2703,7 +2766,6 @@ paragraphs.</p>
 <h3><a name="213"></a>213. Math function overloads ambiguous</h3>
 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 2000-02-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -2728,7 +2790,7 @@ or write floating point expressions as arguments.</p>
 
 <hr>
 <h3><a name="215"></a>215. Can a map's key_type be const?</h3>
-<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-02-29</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#NAD">NAD</a> status.</p>
@@ -2753,7 +2815,7 @@ too.</p>
 
 <p><b>Rationale:</b></p>
 <p>The "key is assignable" requirement from table 69 in
-23.1.2 [associative.reqmts] already implies the key cannot be const.</p>
+23.1.4 [associative.reqmts] already implies the key cannot be const.</p>
 
 
 
@@ -2847,7 +2909,7 @@ operator&lt;.</p>
 
 <hr>
 <h3><a name="219"></a>219. find algorithm missing version that takes a binary predicate argument</h3>
-<p><b>Section:</b> 25.1.2 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
+<p><b>Section:</b> 25.1.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
  <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2000-03-06</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
@@ -2863,7 +2925,7 @@ simple, alternative interface to find.</p>
 
 <p><b>Proposed resolution:</b></p>
 <blockquote>
-<p>In section 25.1.2 [alg.find], add a second prototype for find
+<p>In section 25.1.5 [alg.find], add a second prototype for find
 (between the existing prototype and the prototype for find_if), as
 follows:</p>
 <pre>    template&lt;class InputIterator, class T, class BinaryPredicate&gt;
@@ -2928,7 +2990,7 @@ ie. the <tt>do_is()</tt> method as described in 22.2.1.1.2 [locale.ctype.virtual
 
 <hr>
 <h3><a name="244"></a>244. Must <tt>find</tt>'s third argument be CopyConstructible?</h3>
-<p><b>Section:</b> 25.1.2 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 25.1.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-05-02</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
@@ -3003,7 +3065,7 @@ how many times find may invoke operator++.</p>
 
 <hr>
 <h3><a name="246"></a>246. <tt>a.insert(p,t)</tt> is incorrectly specified</h3>
-<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
  <b>Submitter:</b> Mark Rodgers <b>Date:</b> 2000-05-19</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#Dup">Dup</a> status.</p>
@@ -3133,7 +3195,7 @@ code.</p>
 
 <hr>
 <h3><a name="257"></a>257. STL functional object and iterator inheritance.</h3>
-<p><b>Section:</b> 20.5.3 [base], 24.3.2 [iterator.basic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 20.6.3 [base], 24.3.2 [iterator.basic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Robert Dick  <b>Date:</b> 2000-08-17</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
@@ -3558,7 +3620,6 @@ version of <tt>setf</tt>, to avoid unexpected behavior.
 <h3><a name="289"></a>289. &lt;cmath&gt; requirements missing C float and long double versions</h3>
 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -3941,7 +4002,6 @@ about when terminate() is called; it merely specifies which
 <h3><a name="323"></a>323. abs() overloads in different headers</h3>
 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-06-04</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -4228,7 +4288,7 @@ operator&lt; on any pair type which contains a pointer.
 
 <hr>
 <h3><a name="350"></a>350. allocator&lt;&gt;::address</h3>
-<p><b>Section:</b> 20.6.5.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+<p><b>Section:</b> 20.7.5.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
  <b>Submitter:</b> Nathan Myers <b>Date:</b> 2001-10-25</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
@@ -4313,15 +4373,15 @@ exhibiting a problem.</p>
 
 <hr>
 <h3><a name="351"></a>351. unary_negate and binary_negate: struct or class?</h3>
-<p><b>Section:</b> 20.5 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Dale Riley <b>Date:</b> 2001-11-12</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-In 20.5 [function.objects] the header &lt;functional&gt; synopsis declares
+In 20.6 [function.objects] the header &lt;functional&gt; synopsis declares
 the unary_negate and binary_negate function objects as struct.
-However in 20.5.10 [negators] the unary_negate and binary_negate
+However in 20.6.10 [negators] the unary_negate and binary_negate
 function objects are defined as class.  Given the context, they are
 not "basic function objects" like negate, so this is either a typo or
 an editorial oversight.
@@ -4332,7 +4392,7 @@ an editorial oversight.
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Change the synopsis to reflect the useage in 20.5.10 [negators]</p>
+<p>Change the synopsis to reflect the useage in 20.6.10 [negators]</p>
 
 <p><i>[Curaçao: Since the language permits "struct", the LWG
 views this as NAD. They suggest, however, that the Project Editor
@@ -4558,7 +4618,6 @@ to see which interpretation is being used.</p>
 <h3><a name="357"></a>357. &lt;cmath&gt; float functions cannot return HUGE_VAL</h3>
 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-02-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -4865,13 +4924,13 @@ part of the "Effects" paragraph.
 
 <hr>
 <h3><a name="372"></a>372. Inconsistent description of stdlib exceptions</h3>
-<p><b>Section:</b> 17.4.4.8 [res.on.exception.handling], 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 17.4.4.9 [res.on.exception.handling], 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Randy Maddox <b>Date:</b> 2002-07-22</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.exception.handling">issues</a> in [res.on.exception.handling].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
 
-<p>Paragraph 3 under clause 17.4.4.8 [res.on.exception.handling], Restrictions on
+<p>Paragraph 3 under clause 17.4.4.9 [res.on.exception.handling], Restrictions on
 Exception Handling, states that "Any other functions defined in the
 C++ Standard Library that do not have an exception-specification may
 throw implementation-defined exceptions unless otherwise specified."
@@ -5021,7 +5080,7 @@ out of scope?
 <p>
 Many function templates have parameters that are passed by value;
 a typical example is <tt>find_if</tt>'s <i>pred</i> parameter in
-25.1.2 [alg.find].  Are the corresponding template parameters
+25.1.5 [alg.find].  Are the corresponding template parameters
 (<tt>Predicate</tt> in this case) implicitly required to be
 CopyConstructible, or does that need to be spelled out explicitly?
 </p>
@@ -5296,10 +5355,10 @@ of input iterators.</p>
 
 <hr>
 <h3><a name="393"></a>393. do_in/do_out operation on state unclear</h3>
-<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Alberto Barbati <b>Date:</b> 2002-12-24</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 this DR follows the discussion on the previous thread "codecvt::do_in
@@ -5427,8 +5486,8 @@ is not so clear (see list 3).
 List 1 -- Examples of (presumably) normative Notes:
 <br>
 
-20.6.5.1 [allocator.members], p3,<br>
-20.6.5.1 [allocator.members], p10,<br>
+20.7.5.1 [allocator.members], p3,<br>
+20.7.5.1 [allocator.members], p10,<br>
 21.3.2 [string.cons], p11,<br>
 22.1.1.2 [locale.cons], p11,<br>
 23.2.2.3 [deque.modifiers], p2,<br>
@@ -5443,7 +5502,7 @@ List 2 -- Examples of (presumably) informative Notes:
 18.5.1.3 [new.delete.placement], p3,<br>
 21.3.6.6 [string::replace], p14,<br>
 22.2.1.4.2 [locale.codecvt.virtuals], p3,<br>
-25.1.1 [alg.foreach], p4,<br>
+25.1.4 [alg.foreach], p4,<br>
 26.3.5 [complex.member.ops], p1,<br>
 27.4.2.5 [ios.base.storage], p6.<br>
 <br>
@@ -5785,7 +5844,7 @@ table, in this regard.
 
 <hr>
 <h3><a name="451"></a>451. Associative erase should return an iterator</h3>
-<p><b>Section:</b> 23.1.2 [associative.reqmts], 23.3 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+<p><b>Section:</b> 23.1.4 [associative.reqmts], 23.3 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</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#Dup">Dup</a> status.</p>
@@ -6284,7 +6343,7 @@ support that the eventual solution should make this code well formed.
 
 <hr>
 <h3><a name="480"></a>480. unary_function and binary_function should have protected nonvirtual destructors</h3>
-<p><b>Section:</b> 20.5.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 20.6.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Joe Gottman <b>Date:</b> 2004-08-19</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
@@ -6386,7 +6445,7 @@ explicit, but it's hard to think that's a major problem.</p>
 
 <hr>
 <h3><a name="482"></a>482. Swapping pairs</h3>
-<p><b>Section:</b> 20.2.3 [pairs], 20.3 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+<p><b>Section:</b> 20.2.3 [pairs], 20.4 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2004-09-14</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#NAD%20Editorial">NAD Editorial</a> status.</p>
@@ -6535,7 +6594,6 @@ operator that takes a T, or a T may be convertible to the type of *i.
 <h3><a name="486"></a>486. min/max CopyConstructible requirement is too strict</h3>
 <p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-10-13</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</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#Dup">Dup</a> status.</p>
 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a></p>
@@ -7294,7 +7352,7 @@ not guarantee the substitution property or referential transparency).</p>
 
 <hr>
 <h3><a name="494"></a>494. Wrong runtime complexity for associative container's insert and delete</h3>
-<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Hans B os <b>Date:</b> 2004-12-19</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#NAD">NAD</a> status.</p>
@@ -7447,7 +7505,7 @@ Contradiction.
 
 <hr>
 <h3><a name="501"></a>501. Proposal: strengthen guarantees of lib.comparisons</h3>
-<p><b>Section:</b> 20.5.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 20.6.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Me &lt;anti_spam_email2003@yahoo.com&gt; <b>Date:</b> 2005-06-07</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
@@ -8129,7 +8187,7 @@ Berlin: N1932 considers this NAD. This is a QOI issue.
 
 <hr>
 <h3><a name="525"></a>525. type traits definitions not clear</h3>
-<p><b>Section:</b> 20.4.4 [meta.unary], TR1 4.5 [tr.meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+<p><b>Section:</b> 20.5.4 [meta.unary], TR1 4.5 [tr.meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Robert Klarer <b>Date:</b> 2005-07-11</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -8164,7 +8222,7 @@ in the WP.
 
 <hr>
 <h3><a name="526"></a>526. Is it undefined if a function in the standard changes in parameters?</h3>
-<p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2005-09-14</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#NAD">NAD</a> status.</p>
@@ -8299,7 +8357,7 @@ doesn't give permission for it not to work.</li>
 <li><tt>list::remove(value)</tt> is required to work because the standard
 doesn't give permission for it not to work.</li>
 <li><tt>vector::insert(iter, iter, iter)</tt> is not required to work because
-23.1.1 [sequence.reqmts], p4 says so.</li>
+23.1.3 [sequence.reqmts], p4 says so.</li>
 <li><tt>copy</tt> has to work, except where 25.2.1 [alg.copy] says
 it doesn't have to work.  While a language lawyer can tear this wording apart,
 it is felt that the wording is not prone to accidental interpretation.</li>
@@ -8391,7 +8449,7 @@ chapter 17 wording.
 
 <hr>
 <h3><a name="529"></a>529. The standard encourages redundant and confusing preconditions</h3>
-<p><b>Section:</b> 17.4.3.9 [res.on.required] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+<p><b>Section:</b> 17.4.3.10 [res.on.required] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-10-25</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -8485,7 +8543,7 @@ Alan provided the survey
 
 <hr>
 <h3><a name="532"></a>532. Tuple comparison</h3>
-<p><b>Section:</b> 20.3.1.6 [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#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 20.4.1.6 [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#NAD%20Editorial">Pending NAD Editorial</a>
  <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-11-29</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</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>
@@ -8782,6 +8840,7 @@ Portland:  Subsumed by N2111.
 <h3><a name="553"></a>553. very minor editorial change intptr_t / uintptr_t</h3>
 <p><b>Section:</b> 18.3.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-01-30</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
@@ -8914,10 +8973,10 @@ Redmond:  Editorial.
 
 <hr>
 <h3><a name="557"></a>557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)</h3>
-<p><b>Section:</b> 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-06</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint">issues</a> in [cstdint].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 I'm seeing a problem with such overloads: when, _Longlong == intmax_t ==
@@ -9230,6 +9289,73 @@ committee meant.
 
 
 <hr>
+<h3><a name="570"></a>570. Request adding additional explicit specializations of char_traits</h3>
+<p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Jack Reeves <b>Date:</b> 2006-04-06</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Currently, the Standard Library specifies only a declaration for template class
+char_traits&lt;&gt; and requires the implementation provide two explicit
+specializations: char_traits&lt;char&gt; and char_traits&lt;wchar_t&gt;. I feel the Standard
+should require explicit specializations for all built-in character types, i.e.
+char, wchar_t, unsigned char, and signed char.
+</p>
+<p>
+I have put together a paper
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>)
+that describes this in more detail and
+includes all the necessary wording.
+</p>
+<p><i>[
+Portland: Jack will rewrite
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>
+to propose a primary template that will work with other integral types.
+]</i></p>
+
+<p><i>[
+Toronto: issue has grown with addition of <tt>char16_t</tt> and <tt>char32_t</tt>.
+]</i></p>
+
+
+<p><i>[
+post Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+We suggest that Jack be asked about the status of his paper, and if it
+is not forthcoming, the work-item be assigned to someone else. If no one
+steps forward to do the paper before the next meeting, we propose to
+make this NAD without further discussion. We leave this Open for now,
+but our recommendation is NAD.
+</p>
+<p>
+Note: the issue statement should be updated, as the Toronto comment has
+already been resolved. E.g., char_traits specializations for char16_t
+and char32_t are now in the working paper.
+</p>
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+Nobody has submitted the requested paper, so we move to NAD, as suggested by the decision at the last meeting.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
 <h3><a name="571"></a>571. Update C90 references to C99?</h3>
 <p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-08</p>
@@ -9303,8 +9429,9 @@ is adopted.
 
 <hr>
 <h3><a name="579"></a>579. erase(iterator) for unordered containers should not return an iterator</h3>
-<p><b>Section:</b> 23.1.3 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2006-06-13</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#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -9392,7 +9519,6 @@ uses depend on the iterator being returned.
 <h3><a name="583"></a>583. div() for unsigned integral types</h3>
 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-06-15</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -9431,7 +9557,6 @@ behavior and thus does not need this treatment.
 <h3><a name="584"></a>584. missing int pow(int,int) functionality</h3>
 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-06-15</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -9493,7 +9618,7 @@ post Oxford: Noted that it is already fixed in
 
 <hr>
 <h3><a name="590"></a>590. Type traits implementation latitude should be removed for C++0x</h3>
-<p><b>Section:</b> 20.4 [meta], TR1 4.9 [tr.meta.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+<p><b>Section:</b> 20.5 [meta], TR1 4.9 [tr.meta.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-08-10</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#NAD%20Editorial">NAD Editorial</a> status.</p>
@@ -9603,10 +9728,10 @@ Recommend NAD / Editorial.  The proposed resolution is accepted as editorial.
 
 <hr>
 <h3><a name="592"></a>592. Incorrect treatment of rdbuf()-&gt;close() return type</h3>
-<p><b>Section:</b> 27.8.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 27.8.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Christopher Kohlhoff <b>Date:</b> 2006-08-17</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 I just spotted a minor problem in 27.8.1.7
@@ -9959,6 +10084,12 @@ Bellevue:  Marked as NAD Editorial.
 ]</i></p>
 
 
+<p><i>[
+Post-Sophia Antipolis:  Martin indicates there is still work to be done on this issue.
+Reopened.
+]</i></p>
+
+
 
 
 <p><b>Proposed resolution:</b></p>
@@ -10046,12 +10177,12 @@ its resource limits", so no further escape hatch is necessary.
 
 <hr>
 <h3><a name="633"></a>633. Return clause mentions undefined "type()"</h3>
-<p><b>Section:</b> 20.5.15.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+<p><b>Section:</b> 20.6.15.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-03</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-20.5.15.2.5 [func.wrap.func.targ], p4 says:
+20.6.15.2.5 [func.wrap.func.targ], p4 says:
 </p>
 <blockquote><p>
 <i>Returns:</i> If <tt>type() == typeid(T)</tt>, a pointer to the stored
@@ -10067,7 +10198,7 @@ function <tt>type()</tt> in class template function nor in the global or
 <li>
 Assuming that <tt>type</tt> should have been <tt>target_type()</tt>,
 this description would lead to false results, if <tt>T = <i>cv</i>
-void</tt> due to returns clause 20.5.15.2.5 [func.wrap.func.targ], p1.
+void</tt> due to returns clause 20.6.15.2.5 [func.wrap.func.targ], p1.
 </li>
 </ol>
 
@@ -10075,7 +10206,7 @@ void</tt> due to returns clause 20.5.15.2.5 [func.wrap.func.targ], p1.
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change 20.5.15.2.5 [func.wrap.func.targ], p4:
+Change 20.6.15.2.5 [func.wrap.func.targ], p4:
 </p>
 
 <blockquote><p>
@@ -10127,7 +10258,6 @@ Pete recommends editorial fix.
 <h3><a name="637"></a>637. [c.math]/10 inconsistent return values</h3>
 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-13</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -10949,13 +11079,13 @@ unlikely to be better than what's already in the standard.
 
 <hr>
 <h3><a name="658"></a>658. Two unspecified function comparators in [function.objects]</h3>
-<p><b>Section:</b> 20.5 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-19</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The header <tt>&lt;functional&gt;</tt> synopsis in 20.5 [function.objects]
+The header <tt>&lt;functional&gt;</tt> synopsis in 20.6 [function.objects]
 contains the following two free comparison operator templates
 for the <tt>function</tt> class template
 </p>
@@ -10969,7 +11099,7 @@ void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function
 <p>
 which are nowhere described. I assume that they are relicts before the
 corresponding two private and undefined member templates in the function
-template (see 20.5.15.2 [func.wrap.func] and X [func.wrap.func.undef]) have been introduced. The original free
+template (see 20.6.15.2 [func.wrap.func] and X [func.wrap.func.undef]) have been introduced. The original free
 function templates should be removed, because using an undefined entity
 would lead to an ODR violation of the user.
 </p>
@@ -10978,7 +11108,7 @@ would lead to an ODR violation of the user.
 <p><b>Proposed resolution:</b></p>
 <p>
 Remove the above mentioned two function templates from
-the header <tt>&lt;functional&gt;</tt> synopsis (20.5 [function.objects])
+the header <tt>&lt;functional&gt;</tt> synopsis (20.6 [function.objects])
 </p>
 
 <blockquote><pre><del>template&lt;class Function1, class Function2&gt;
@@ -11328,13 +11458,13 @@ Bellevue:  Proposed wording now in WP.
 
 <hr>
 <h3><a name="686"></a>686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type</h3>
-<p><b>Section:</b> 20.6.11.2.4 [unique.ptr.single.observers], 20.6.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 20.7.11.2.4 [unique.ptr.single.observers], 20.7.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-06-14</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 The standard library uses the <tt>operator <i>unspecified-bool-type</i>() const</tt> idiom in
-five places. In three of those places (20.5.15.2.3 [func.wrap.func.cap], function capacity 
+five places. In three of those places (20.6.15.2.3 [func.wrap.func.cap], function capacity 
 for example) the returned value is constrained to disallow
 unintended conversions to int. The standardese is
 </p>
@@ -11362,8 +11492,8 @@ makes it irrelevant.
 <p>
 To the <i>Returns</i> paragraph for <tt>operator <i>unspecified-bool-type</i>()
 const</tt>
-of 20.6.11.2.4 [unique.ptr.single.observers] paragraph 11 and
-20.6.12.2.5 [util.smartptr.shared.obs] paragraph 16, add the sentence:
+of 20.7.11.2.4 [unique.ptr.single.observers] paragraph 11 and
+20.7.12.2.5 [util.smartptr.shared.obs] paragraph 16, add the sentence:
 </p>
 <blockquote><p>
 The return type shall not be convertible to <tt>int</tt>.
@@ -11382,7 +11512,6 @@ Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue.
 <h3><a name="690"></a>690. abs(long long) should return long long</h3>
 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-06-10</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -11542,63 +11671,6 @@ implementation details.
 
 
 <hr>
-<h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3>
-<p><b>Section:</b> 21.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-13</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The changes made for <tt>constexpr</tt> in 21.1.3 [char.traits.specializations] have 
-not only changed the <tt>not_eof</tt> function from pass by const reference to 
-pass by value, it has also changed the parameter type from <tt>int_type</tt> to 
-<tt>char_type</tt>.
-</p>
-<p>
-This doesn't work for type <tt>char</tt>, and is inconsistent with the 
-requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require].
-</p>
-
-<p>
-Pete adds:
-</p>
-
-<blockquote><p>
-For what it's worth, that may not have been an intentional change. 
-N2349, which detailed the changes for adding constant expressions to 
-the library, has strikeout bars through the <tt>const</tt> and the <tt>&amp;</tt> that 
-surround the <tt>char_type</tt> argument, but none through <tt>char_type</tt> itself. 
-So the intention may have been just to change to pass by value, with 
-text incorrectly copied from the standard.
-</p></blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the signature in 21.1.3.1 [char.traits.specializations.char],
-21.1.3.2 [char.traits.specializations.char16_t], 21.1.3.3 [char.traits.specializations.char32_t],
-and 21.1.3.4 [char.traits.specializations.wchar.t] to
-</p>
-
-<blockquote><pre>static constexpr int_type not_eof(<del>char_type</del> <ins>int_type</ins> c);
-</pre></blockquote>
-
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Resolution: NAD editorial - up to Pete's judgment
-</blockquote>
-
-
-
-
-<hr>
 <h3><a name="717"></a>717. Incomplete <tt>valarray::operator[]</tt> specification in [valarray.access]</h3>
 <p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-27</p>
@@ -11660,7 +11732,7 @@ of that array ends, whichever happens first.
 
 <hr>
 <h3><a name="725"></a>725. Optional sequence container requirements column label</h3>
-<p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
  <b>Submitter:</b> David Abrahams <b>Date:</b> 2007-09-16</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#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
@@ -12025,6 +12097,7 @@ for the proposed resolution.
 <h3><a name="736"></a>736. Comment on [rand.dist.samp.discrete]</h3>
 <p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -12372,7 +12445,7 @@ for the proposed resolution.
 
 <hr>
 <h3><a name="741"></a>741. Const-incorrect <tt>get_deleter</tt> function for <tt>shared_ptr</tt></h3>
-<p><b>Section:</b> 20.6.12.2.11 [util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 20.7.12.2.11 [util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-09-27</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
@@ -12383,7 +12456,7 @@ The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
 
 <p>
 According to the recent draft N2369, both the header memory synopsis
-of 20.6 [memory] and 20.6.12.2.11 [util.smartptr.getdeleter] declare:
+of 20.7 [memory] and 20.7.12.2.11 [util.smartptr.getdeleter] declare:
 </p>
 
 <blockquote><pre>template&lt;class D, class T&gt; D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
@@ -12398,7 +12471,7 @@ the mutability of the owner (as seen for the both overloads of
 <tt>unique_ptr::get_deleter</tt>).
 Even the next similar counter-part of <tt>get_deleter</tt> - the two
 overloads of <tt>function::target</tt> in the class template function
-synopsis 20.5.15.2 [func.wrap.func] or in 20.5.15.2.5 [func.wrap.func.targ] - do
+synopsis 20.6.15.2 [func.wrap.func] or in 20.6.15.2.5 [func.wrap.func.targ] - do
 properly mirror the const-state of the owner.
 </p>
 
@@ -12406,7 +12479,7 @@ properly mirror the const-state of the owner.
 
 <p>
 Replace the declarations of <tt>get_deleter</tt> in the header <tt>&lt;memory&gt;</tt>
-synopsis of 20.6 [memory] and in 20.6.12.2.11 [util.smartptr.getdeleter] by one of the
+synopsis of 20.7 [memory] and in 20.7.12.2.11 [util.smartptr.getdeleter] by one of the
 following alternatives (A) or (B):
 </p>
 
@@ -12519,9 +12592,8 @@ slicing involved.
 
 <hr>
 <h3><a name="748"></a>748. The is_abstract type trait is defined by reference to 10.4.</h3>
-<p><b>Section:</b> 20.4.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 20.5.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</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#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -12556,10 +12628,10 @@ Core has clarified that the definition abstract is adequate. Issue withdrawn by
 
 <hr>
 <h3><a name="754"></a>754. Ambiguous return clause for <tt>std::uninitialized_copy</tt></h3>
-<p><b>Section:</b> 20.6.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 20.7.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-10-15</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 14882-2003, [lib.uninitialized.copy] is currently written as follows:
@@ -12586,7 +12658,7 @@ Core has clarified that the definition abstract is adequate. Issue withdrawn by
 
 <p>
 similarily for N2369, and its corresponding section
-20.6.10.1 [uninitialized.copy].
+20.7.10.1 [uninitialized.copy].
 </p>
 
 <p>
@@ -12634,7 +12706,7 @@ for <tt>std::copy</tt>.
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change the wording of the return clause to say (20.6.10.1 [uninitialized.copy]):
+Change the wording of the return clause to say (20.7.10.1 [uninitialized.copy]):
 </p>
 
 <blockquote>
@@ -12659,11 +12731,107 @@ occur.
 
 
 <hr>
+<h3><a name="756"></a>756. Container adaptors push</h3>
+<p><b>Section:</b> 23.2.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-10-31</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+After n2369 we have a single <tt>push_back</tt> overload in the sequence containers,
+of the "emplace" type. At variance with that, still in n2461, we have
+two separate overloads, the C++03 one + one taking an rvalue reference
+in the container adaptors. Therefore, simply from a consistency point of
+view, I was wondering whether the container adaptors should be aligned
+with the specifications of the sequence container themselves: thus have
+a single <tt>push</tt> along the lines:
+</p>
+
+<blockquote><pre>template&lt;typename... _Args&gt;
+void
+push(_Args&amp;&amp;... __args)
+  { c.push_back(std::forward&lt;_Args&gt;(__args)...); }
+</pre></blockquote>
+
+<p><i>[
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 23.2.5.1.1 [queue.defn]:
+</p>
+
+<blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
+<del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
+<ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
+</pre></blockquote>
+
+<p>
+Change 23.2.5.2 [priority.queue]:
+</p>
+
+<blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
+<del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
+<ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
+</pre></blockquote>
+
+<p>
+Change 23.2.5.2.2 [priqueue.members]:
+</p>
+
+<blockquote>
+<pre><del>void push(const value_type&amp; x);</del>
+</pre>
+<blockquote>
+<p>
+<del><i>Effects:</i></del>
+</p>
+<blockquote><pre><del>c.push_back(x);</del>
+<del>push_heap(c.begin(), c.end(), comp);</del>
+</pre></blockquote>
+</blockquote>
+
+<pre><ins>template&lt;class... Args&gt;</ins> void push(<del>value_type</del> <ins>Args</ins>&amp;&amp;<ins>...</ins> <del>x</del> <ins>args</ins>);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i>
+</p>
+<blockquote><pre>c.push_back(std::<del>move</del><ins>forward&lt;Args&gt;</ins>(<del>x</del> <ins>args</ins>)<ins>...</ins>);
+push_heap(c.begin(), c.end(), comp);
+</pre></blockquote>
+</blockquote>
+</blockquote>
+
+<p>
+Change 23.2.5.3.1 [stack.defn]:
+</p>
+
+<blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
+<del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
+<ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
+</pre></blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<p>
+Addressed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>.
+</p>
+
+
+
+
+
+<hr>
 <h3><a name="757"></a>757. Typo in the synopsis of vector</h3>
-<p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-11-04</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#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 In the synopsis 23.2.6 [vector], there is the signature:
@@ -12702,7 +12870,7 @@ void     insert(const_iterator position, size_type n, const T&amp; x);
 
 <hr>
 <h3><a name="763"></a>763. Renaming <tt>emplace()</tt> overloads</h3>
-<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-04</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#NAD">NAD</a> status.</p>
@@ -12721,7 +12889,7 @@ a <tt>const_iterator</tt> as first argument.
 </p>
 
 <p><i>[
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
 ]</i></p>
 
 
@@ -12754,8 +12922,9 @@ For example to <tt>emplace_here</tt>, <tt>hint_emplace</tt>...
 
 <hr>
 <h3><a name="764"></a>764. <tt>equal_range</tt> on unordered containers should return a <tt>pair</tt> of <tt>local_iterators</tt></h3>
-<p><b>Section:</b> 23.1.3 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-29</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#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -12812,7 +12981,7 @@ for dubious benefit, and iterators are already constant time.
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change the entry for <tt>equal_range</tt> in Table 93 (23.1.3 [unord.req]) as follows:
+Change the entry for <tt>equal_range</tt> in Table 93 (23.1.5 [unord.req]) as follows:
 </p>
 <table border="1">
 <tbody><tr>
@@ -12832,6 +13001,273 @@ Change the entry for <tt>equal_range</tt> in Table 93 (23.1.3 [unord.req]) as fo
 
 
 <hr>
+<h3><a name="767"></a>767. Forwarding and backward compatibility</h3>
+<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-28</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#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Playing with g++'s C++0X mode, I noticed that the following
+code, which used to compile:
+</p>
+
+<blockquote><pre>#include &lt;vector&gt;
+
+int main()
+{
+    std::vector&lt;char *&gt; v;
+    v.push_back(0);
+}
+</pre></blockquote>
+
+<p>
+now fails with the following error message:
+</p>
+
+<blockquote>.../include/c++/4.3.0/ext/new_allocator.h: In member
+function 'void __gnu_cxx::new_allocator&lt;_Tp&gt;::construct(_Tp*,
+_Args&amp;&amp; ...) [with _Args = int, _Tp = char*]':
+.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void
+std::vector&lt;_Tp, _Alloc&gt;::push_back(_Args&amp;&amp; ...) [with
+_Args = int, _Tp = char*, _Alloc = std::allocator&lt;char*&gt;]'
+test.cpp:6: instantiated from here
+.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid
+conversion from 'int' to 'char*'
+</blockquote>
+
+<p>
+As far as I know, g++ follows the current draft here.
+</p>
+<p>
+Does the committee really intend to break compatibility for such cases?
+</p>
+
+<p><i>[
+Sylvain adds: 
+]</i></p>
+
+
+<blockquote>
+<p>
+I just noticed that <tt>std::pair</tt> has the same issue.
+The following now fails with GCC's -std=c++0x mode:
+</p>
+
+<blockquote><pre>#include &lt;utility&gt;
+
+int main()
+{
+   std::pair&lt;char *, char *&gt; p (0,0);
+}
+</pre></blockquote>
+
+<p>
+I have not made any general audit for such problems elsewhere.
+</p>
+</blockquote>
+
+<p><i>[
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>
+]</i></p>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Motivation is to handle the old-style int-zero-valued NULL pointers.
+Problem: this solution requires concepts in some cases, which some users
+will be slow to adopt. Some discussion of alternatives involving
+prohibiting variadic forms and additional library-implementation
+complexity.
+</p>
+<p>
+Discussion of "perfect world" solutions, the only such solution put
+forward being to retroactively prohibit use of the integer zero for a
+NULL pointer. This approach was deemed unacceptable given the large
+bodies of pre-existing code that do use integer zero for a NULL pointer.
+</p>
+<p>
+Another approach is to change the member names. Yet another approach is
+to forbid the extension in absence of concepts.
+</p>
+<p>
+Resolution: These issues (<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>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>) will be subsumed into a
+paper to be produced by Alan Talbot in time for review at the 2008
+meeting in France. Once this paper is produced, these issues will be
+moved to NAD.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following rows to Table 90 "Optional sequence container operations", 23.1.3 [sequence.reqmts]:
+</p>
+
+<blockquote>
+<table border="1">
+<tbody><tr>
+<th>expression</th> <th>return type</th> <th>assertion/note<br>pre-/post-condition</th> <th>container</th>
+</tr>
+
+<tr>
+<td>
+<tt>a.push_front(t)</tt>
+</td>
+<td>
+<tt>void</tt>
+</td>
+<td>
+<tt>a.insert(a.begin(), t)</tt><br>
+<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
+</td>
+<td>
+<tt>list, deque</tt>
+</td>
+</tr>
+
+<tr>
+<td>
+<tt>a.push_front(rv)</tt>
+</td>
+<td>
+<tt>void</tt>
+</td>
+<td>
+<tt>a.insert(a.begin(), rv)</tt><br>
+<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
+</td>
+<td>
+<tt>list, deque</tt>
+</td>
+</tr>
+
+<tr>
+<td>
+<tt>a.push_back(t)</tt>
+</td>
+<td>
+<tt>void</tt>
+</td>
+<td>
+<tt>a.insert(a.end(), t)</tt><br>
+<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
+</td>
+<td>
+<tt>list, deque, vector, basic_string</tt>
+</td>
+</tr>
+
+<tr>
+<td>
+<tt>a.push_back(rv)</tt>
+</td>
+<td>
+<tt>void</tt>
+</td>
+<td>
+<tt>a.insert(a.end(), rv)</tt><br>
+<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
+</td>
+<td>
+<tt>list, deque, vector, basic_string</tt>
+</td>
+</tr>
+
+</tbody></table>
+</blockquote>
+
+<p>
+Change the synopsis in 23.2.2 [deque]:
+</p>
+
+<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
+<ins>void push_front(T&amp;&amp; x);</ins>
+<ins>void push_back(const T&amp; x);</ins>
+<ins>void push_back(T&amp;&amp; x);</ins>
+template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
+template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
+</pre></blockquote>
+
+<p>
+Change 23.2.2.3 [deque.modifiers]:
+</p>
+
+<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
+<ins>void push_front(T&amp;&amp; x);</ins>
+<ins>void push_back(const T&amp; x);</ins>
+<ins>void push_back(T&amp;&amp; x);</ins>
+template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
+template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
+</pre></blockquote>
+
+<p>
+Change the synopsis in 23.2.4 [list]:
+</p>
+
+<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
+<ins>void push_front(T&amp;&amp; x);</ins>
+<ins>void push_back(const T&amp; x);</ins>
+<ins>void push_back(T&amp;&amp; x);</ins>
+template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
+template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
+</pre></blockquote>
+
+<p>
+Change 23.2.4.3 [list.modifiers]:
+</p>
+
+<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
+<ins>void push_front(T&amp;&amp; x);</ins>
+<ins>void push_back(const T&amp; x);</ins>
+<ins>void push_back(T&amp;&amp; x);</ins>
+template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
+template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
+</pre></blockquote>
+
+<p>
+Change the synopsis in 23.2.6 [vector]:
+</p>
+
+<blockquote><pre><ins>void push_back(const T&amp; x);</ins>
+<ins>void push_back(T&amp;&amp; x);</ins>
+template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
+</pre></blockquote>
+
+<p>
+Change 23.2.6.4 [vector.modifiers]:
+</p>
+
+<blockquote><pre><ins>void push_back(const T&amp; x);</ins>
+<ins>void push_back(T&amp;&amp; x);</ins>
+template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
+</pre></blockquote>
+
+
+
+
+<p><b>Rationale:</b></p>
+<p>
+Addressed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>.
+</p>
+
+<p>
+If there is still an issue with pair, Howard should submit another issue.
+</p>
+
+
+
+
+
+<hr>
 <h3><a name="773"></a>773. issues with random</h3>
 <p><b>Section:</b> 26.4.8.1 [rand.dist.uni] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-01-14</p>
@@ -12949,6 +13385,132 @@ Change 30.3.3.2.3 [thread.lock.unique.mod]:
 
 
 <hr>
+<h3><a name="786"></a>786. Thread library timed waits, UTC and monotonic clocks</h3>
+<p><b>Section:</b> X [datetime.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Christopher Kohlhoff, Jeff Garland <b>Date:</b> 2008-02-03</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The draft C++0x thread library requires that the time points of type
+<tt>system_time</tt> and returned by <tt>get_system_time()</tt> represent Coordinated
+Universal Time (UTC) (section X [datetime.system]). This can lead to
+surprising behavior when a library user performs a duration-based wait,
+such as <tt>condition_variable::timed_wait()</tt>. A complete explanation of the
+problem may be found in the
+<a href="http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19">Rationale for the Monotonic Clock</a>
+section in POSIX, but in summary:
+</p>
+
+<ul>
+<li>
+Operations such as <tt>condition_variable::timed_wait()</tt> (and its POSIX
+equivalent, <tt>pthread_cond_timedwait()</tt>) are specified using absolute times
+to address the problem of spurious wakeups.
+</li>
+
+<li>
+The typical use of the timed wait operations is to perform a relative
+wait. This may be achieved by first calculating an absolute time as the
+sum of the current time and the desired duration. In fact, the C++0x
+thread library includes duration-based overloads of
+<tt>condition_variable::timed_wait()</tt> that behave as if by calling the
+corresponding absolute time overload with a time point value of
+<tt>get_system_time() + rel_time</tt>.
+</li>
+
+<li>
+A UTC clock may be affected by changes to the system time, such as
+synchronization with an external source, leap seconds, or manual changes
+to the clock.
+</li>
+
+<li>
+Should the clock change during a timed wait operation, the actual
+duration of the wait will not be the expected length. For example, a
+user may intend a timed wait of one second duration but, due to an
+adjustment of the system clock backwards by a minute, the wait instead
+takes 61 seconds.
+</li>
+</ul>
+
+<p>
+POSIX solves the problem by introducing a new monotonic clock, which is
+unaffected by changes to the system time. When a condition variable is
+initialized, the user may specify whether the monotonic clock is to be
+used. (It is worth noting that on POSIX systems it is not possible to
+use <tt>condition_variable::native_handle()</tt> to access this facility, since
+the desired clock type must be specified during construction of the
+condition variable object.)
+</p>
+
+<p>
+In the context of the C++0x thread library, there are added dimensions
+to the problem due to the need to support platforms other than POSIX:
+</p>
+
+<ul>
+<li>
+Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock.
+</li>
+
+<li>
+Some environments do not have a monotonic clock, but do have a UTC clock.
+</li>
+
+<li>
+The Microsoft Windows API's synchronization functions use relative
+timeouts based on an implied monotonic clock. A program that switches
+from the Windows API to the C++0x thread library will now find itself
+susceptible to clock changes.
+</li>
+</ul>
+
+<p>
+One possible minimal solution:
+</p>
+
+<ul>
+<li>
+Strike normative references to UTC and an epoch based on 1970-01-01.
+</li>
+
+<li>
+Make the semantics of <tt>system_time</tt> and <tt>get_system_time()</tt>
+implementation-defined (i.e standard library implementors may choose the
+appropriate underlying clock based on the capabilities of the target
+platform).
+</li>
+
+<li>
+Add a non-normative note encouraging use of a monotonic clock.
+</li>
+
+<li>
+Remove <tt>system_time::seconds_since_epoch()</tt>.
+</li>
+
+<li>
+Change the constructor <tt>explicit system_time(time_t secs, nanoseconds ns
+= 0)</tt> to <tt>explicit system_time(nanoseconds ns)</tt>.
+</li>
+</ul>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+<p><b>Rationale:</b></p>
+Addressed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661: A Foundation to Sleep On</a>.
+
+
+
+
+
+<hr>
 <h3><a name="790"></a>790. <tt>xor_combine::seed</tt> not specified</h3>
 <p><b>Section:</b> 26.4.4.4 [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
@@ -12967,7 +13529,7 @@ Bellevue:
 
 
 <blockquote>
-Overcome by the previous proposal. NAD mooted by resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#789">789</a>.
+Overcome by the previous proposal. NAD mooted by resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>.
 </blockquote>
 
 
@@ -13306,5 +13868,149 @@ Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the r
 
 
 
+<hr>
+<h3><a name="826"></a>826. Equivalent of <tt>%'d</tt>, or rather, lack thereof?</h3>
+<p><b>Section:</b> 22.2.2.2 [locale.nm.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-07</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In the spirit of <tt>printf vs iostream</tt>...
+</p>
+
+<p>
+POSIX <tt>printf</tt> says that <tt>%'d</tt> should insert grouping characters (and the
+implication is that in the absence of <tt>'</tt> no grouping characters are
+inserted). The <tt>num_put</tt> facet, on the other hand, seems to always insert
+grouping characters. Can this be considered a defect worth fixing for
+C++0x? Maybe <tt>ios_base</tt> needs an additional flag?
+</p>
+
+<p><i>[
+Pablo Halpern:
+]</i></p>
+
+
+<blockquote>
+I'm not sure it constitutes a defect, but I would be in favor of adding
+another flag (and corresponding manipulator).
+</blockquote>
+
+<p><i>[
+Martin Sebor:
+]</i></p>
+
+
+<blockquote>
+I don't know if it qualifies as a defect but I agree that there
+should be an easy way to control whether the thousands separator
+should or shouldn't be inserted. A new flag would be in line with
+the current design of iostreams (like <tt>boolalpha</tt>, <tt>showpos</tt>, or
+<tt>showbase</tt>).
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+This is not a part of C99. LWG suggests submitting a paper may be appropriate.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="831"></a>831. wrong type for not_eof()</h3>
+<p><b>Section:</b> 21.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+  In Table 56 (Traits requirements) the <tt>not_eof()</tt> member function
+  is using an argument of type <i>e</i> which denotes an object of
+  type <code>X::int_type</code>. However, the specializations in
+  21.1.3 [char.traits.specializations] all use <code>char_type</code>.
+  This would effectively mean that the argument type actually can't
+  represent EOF in the first place. I'm pretty sure that the type used
+  to be <code>int_type</code> which is quite obviously the only sensible
+  argument.
+</p>
+<p>
+  This issue is close to being editorial. I suspect that the proposal
+  changing this section to include the specializations for <code>char16_t</code>
+  and <code>char32_t</code> accidentally used the wrong type.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+  In 21.1.3.1 [char.traits.specializations.char],
+  21.1.3.2 [char.traits.specializations.char16_t],
+  21.1.3.3 [char.traits.specializations.char32_t], and
+   [char.traits.specializations.wchar_t] correct the
+  argument type from <code>char_type</code> to <code>int_type</code>.
+</p>
+
+
+<p><b>Rationale:</b></p>
+Already fixed in WP.
+
+
+
+
+
+<hr>
+<h3><a name="840"></a>840. <tt>pair</tt> default template argument</h3>
+<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-05-23</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#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I have one issue with <tt>std::pair</tt>. Well, it might just be a very annoying
+historical accident, but why is there no default template argument for
+the second template argument? This is so annoying when the type in
+question is looong and hard to write (type deduction with <tt>auto</tt> won't
+help those cases where we use it as a return or argument type).
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 20.2 [utility] to read:
+</p>
+
+<blockquote><pre>template &lt;class T1, class T2 <ins>= T1</ins>&gt; struct pair;
+</pre></blockquote>
+
+<p>
+Change 20.2.3 [pairs] to read:
+</p>
+
+<blockquote><pre>namespace std {
+ template &lt;class T1, class T2 <ins>= T1</ins>&gt;
+ struct pair {
+   typedef T1 first_type;
+   typedef T2 second_type;
+   ...
+</pre></blockquote>
+
+
+<p><b>Rationale:</b></p>
+<tt>std::pair</tt> is a heterogeneous container.
+
+
+
+
 
 </body></html>
\ No newline at end of file
diff --git a/libstdc++-v3/doc/html/ext/lwg-defects.html b/libstdc++-v3/doc/html/ext/lwg-defects.html
index 0133503..5951a98 100644 (file)
--- a/libstdc++-v3/doc/html/ext/lwg-defects.html
+++ b/libstdc++-v3/doc/html/ext/lwg-defects.html
@@ -1,22 +1,24 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
-<html><head><title>C++ Standard Library Defect Report List</title>
-
+<html><head>
+<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
 
 
+<title>C++ Standard Library Defect Report List</title>
 <style type="text/css">
 p {text-align:justify}
 li {text-align:justify}
 ins {background-color:#A0FFA0}
 del {background-color:#FFA0A0}
-</style></head><body>
+</style>
+</head><body>
 <table>
 <tbody><tr>
 <td align="left">Doc. no.</td>
-<td align="left">N2613=08-0123</td>
+<td align="left">N2728=08-0238</td>
 </tr>
 <tr>
 <td align="left">Date:</td>
-<td align="left">2008-05-18</td>
+<td align="left">2008-08-24</td>
 </tr>
 <tr>
 <td align="left">Project:</td>
@@ -27,7 +29,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 Defect Report List (Revision R56)</h1>
+<h1>C++ Standard Library Defect Report List (Revision R59)</h1>
 
   <p>Reference ISO/IEC IS 14882:1998(E)</p>
   <p>Also see:</p>
@@ -49,6 +51,67 @@ del {background-color:#FFA0A0}
 
 <h2>Revision History</h2>
 <ul>
+<li>R59: 
+2008-08-22 pre-San Francisco mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>192 open issues, up by 9.</li>
+<li>686 closed issues, up by 0.</li>
+<li>878 issues total, up by 9.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="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-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R58: 
+2008-07-28 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>183 open issues, up by 12.</li>
+<li>686 closed issues, down by 4.</li>
+<li>869 issues total, up by 8.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#864">864</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#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</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#869">869</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#393">393</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#592">592</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 Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
+<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>.</li>
+<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R57: 
+2008-06-27 post-Sophia Antipolis mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>171 open issues, down by 20.</li>
+<li>690 closed issues, up by 43.</li>
+<li>861 issues total, up by 23.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following NAD issues: <a href="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-active.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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 Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li>
+<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>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-active.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-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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 New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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>
+</ul></li>
+</ul>
+</li>
 <li>R56: 
 2008-05-16 pre-Sophia Antipolis mailing.
 <ul>
@@ -58,7 +121,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-active.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-active.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-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
@@ -76,7 +139,7 @@ del {background-color:#FFA0A0}
 <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-active.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-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>.</li>
 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#803">803</a>.</li>
-<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#798">798</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>
 <li>Changed the following issues from NAD Future to NAD: <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#323">323</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#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</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>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li>
@@ -85,13 +148,13 @@ 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-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-closed.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 New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-closed.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#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</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-active.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-active.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-active.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-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
@@ -108,7 +171,7 @@ del {background-color:#FFA0A0}
 <li>787 issues total, up by 23.</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#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <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#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</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-closed.html#767">767</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-active.html#769">769</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-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</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-active.html#776">776</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-active.html#779">779</a>, <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-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-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <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-active.html#787">787</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#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</li>
 <li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</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#697">697</a>.</li>
@@ -126,7 +189,7 @@ del {background-color:#FFA0A0}
 <li>764 issues total, up by 10.</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#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>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-active.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-active.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-active.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 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>
@@ -141,16 +204,16 @@ del {background-color:#FFA0A0}
 <li>754 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#724">724</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-active.html#726">726</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#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</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#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</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#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li>
+<li>Added the following New issues: <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#725">725</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-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</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#739">739</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-closed.html#741">741</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-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-closed.html#745">745</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-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</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-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</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#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-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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#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-active.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-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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#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-active.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-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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-active.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>
+<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-active.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-active.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>
 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</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#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</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-active.html#672">672</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-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</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#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-closed.html#645">645</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-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-active.html#691">691</a>.</li>
 <li>Changed the following issues from New to WP: <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#634">634</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#678">678</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#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>.</li>
 <li>Changed the following issues from Open to WP: <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#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</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#488">488</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#660">660</a>.</li>
@@ -166,7 +229,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-closed.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
 </ul></li>
 </ul>
 </li>
@@ -187,10 +250,10 @@ 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#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-closed.html#633">633</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#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-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-closed.html#656">656</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#579">579</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-defects.html#680">680</a>.</li>
 <li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
-<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#644">644</a>.</li>
+<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</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#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</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#488">488</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#518">518</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#518">518</a>.</li>
 <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
 <li>Changed the following issues from DR to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</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#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#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-defects.html#646">646</a>.</li>
@@ -206,7 +269,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-active.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-active.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-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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 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>
@@ -223,7 +286,7 @@ 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-active.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-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-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-active.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-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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 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>
@@ -233,7 +296,7 @@ del {background-color:#FFA0A0}
 <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-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-closed.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-defects.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 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-active.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>
 <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</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#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>.</li>
@@ -250,9 +313,9 @@ 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-active.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-active.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-active.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-defects.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-active.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-active.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-active.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-closed.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-active.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-active.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-active.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-closed.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-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>
@@ -284,7 +347,7 @@ del {background-color:#FFA0A0}
 <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#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#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> to WP.</li>
 <li>Moved issues <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#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#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-closed.html#558">558</a> to NAD.</li>
 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</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#542">542</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-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
+<li>Moved issues <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-active.html#523">523</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#542">542</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-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
 <li>Moved issues <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-closed.html#549">549</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#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a> to Ready.</li>
 <li>Moved issues <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> to Review.</li>
 <li>Added new issues <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#609">609</a>.</li>
@@ -373,7 +436,7 @@ Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.ht
 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#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-active.html#518">518</a> from New to Review.
+Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
 </li>
 <li>R38: 
 2005-07-03 pre-Mont Tremblant mailing.
@@ -4092,7 +4155,7 @@ for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".</p>
 
 <hr>
 <h3><a name="103"></a>103. set::iterator is required to be modifiable, but this allows modification of keys</h3>
-<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</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#WP">WP</a> status.</p>
@@ -4124,7 +4187,7 @@ goes in line with trusting user knows what he is doing. </p>
 
 <p><b>Other Options Evaluated:</b> </p>
 
-<p>Option A.&nbsp;&nbsp; In 23.1.2 [associative.reqmts], paragraph 2, after
+<p>Option A.&nbsp;&nbsp; In 23.1.4 [associative.reqmts], paragraph 2, after
 first sentence, and before "In addition,...", add one line:
 </p>
 
@@ -4132,7 +4195,7 @@ first sentence, and before "In addition,...", add one line:
   <p>Modification of keys shall not change their strict weak ordering. </p>
 </blockquote>
 
-<p>Option B.&nbsp;Add three new sentences to 23.1.2 [associative.reqmts]:</p>
+<p>Option B.&nbsp;Add three new sentences to 23.1.4 [associative.reqmts]:</p>
 
 <blockquote>
   <p>At the end of paragraph 5: "Keys in an associative container
@@ -4144,7 +4207,7 @@ first sentence, and before "In addition,...", add one line:
   type."</p>
 </blockquote>
 
-<p>Option C.&nbsp;To 23.1.2 [associative.reqmts], paragraph 3, which
+<p>Option C.&nbsp;To 23.1.4 [associative.reqmts], paragraph 3, which
 currently reads:</p>
 
 <blockquote>
@@ -4170,7 +4233,7 @@ currently reads:</p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Add the following to 23.1.2 [associative.reqmts] at
+<p>Add the following to 23.1.4 [associative.reqmts] at
 the indicated location:</p>
 
 <blockquote>
@@ -4717,12 +4780,12 @@ operator&gt;&gt;(int&amp; val);</pre>
 
 <hr>
 <h3><a name="119"></a>119. Should virtual functions be allowed to strengthen the exception specification?</h3>
-<p><b>Section:</b> 17.4.4.8 [res.on.exception.handling] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
+<p><b>Section:</b> 17.4.4.9 [res.on.exception.handling] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.exception.handling">issues</a> in [res.on.exception.handling].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>Section 17.4.4.8 [res.on.exception.handling] states: </p>
+<p>Section 17.4.4.9 [res.on.exception.handling] states: </p>
 
 <p>"An implementation may strengthen the exception-specification
 for a function by removing listed exceptions." </p>
@@ -4746,7 +4809,7 @@ public:
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Change Section 17.4.4.8 [res.on.exception.handling] from:</p>
+<p>Change Section 17.4.4.9 [res.on.exception.handling] from:</p>
 
 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
 exception-specification for a function"</p>
@@ -5156,7 +5219,7 @@ object parameter may be bound to an rvalue [13.3.3.1.4/3]
 
   <p>Tokyo: The LWG removed the following from the proposed resolution:</p>
 
-  <p>In 20.4.4 [meta.unary], paragraph 2, and 20.4.4.3 [meta.unary.prop], 
+  <p>In 20.5.4 [meta.unary], paragraph 2, and 20.5.4.3 [meta.unary.prop], 
   paragraph 2, make the conversion to auto_ptr_ref const:</p>
   <blockquote>
     <pre>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() const throw();</pre>
@@ -5164,17 +5227,17 @@ object parameter may be bound to an rvalue [13.3.3.1.4/3]
 
 
 <p><b>Proposed resolution:</b></p>
-<p>In 20.4.4 [meta.unary], paragraph 2, move
+<p>In 20.5.4 [meta.unary], paragraph 2, move
 the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
 
-<p>In 20.4.4 [meta.unary], paragraph 2, add
+<p>In 20.5.4 [meta.unary], paragraph 2, add
 a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
 
 <blockquote>
   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</pre>
 </blockquote>
 
-<p>Also add the assignment operator to 20.4.4.3 [meta.unary.prop]: </p>
+<p>Also add the assignment operator to 20.5.4.3 [meta.unary.prop]: </p>
 
 <blockquote>
   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw()</pre>
@@ -5227,7 +5290,7 @@ stream state in case of failure.</p>
 
 <hr>
 <h3><a name="130"></a>130. Return type of container::erase(iterator) differs for associative containers</h3>
-<p><b>Section:</b> 23.1.2 [associative.reqmts], 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
+<p><b>Section:</b> 23.1.4 [associative.reqmts], 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-03-02</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#DR">DR</a> status.</p>
@@ -5244,7 +5307,7 @@ fail to meet the requirements for containers.</p>
 <p><b>Proposed resolution:</b></p>
 
 <p>
-In 23.1.2 [associative.reqmts], in Table 69 Associative container
+In 23.1.4 [associative.reqmts], in Table 69 Associative container
 requirements, change the return type of <tt>a.erase(q)</tt> from
 <tt>void</tt> to <tt>iterator</tt>.  Change the
 assertion/not/pre/post-condition from "erases the element pointed to
@@ -5255,7 +5318,7 @@ is returned."
 </p>
 
 <p>
-In 23.1.2 [associative.reqmts], in Table 69 Associative container
+In 23.1.4 [associative.reqmts], in Table 69 Associative container
 requirements, change the return type of <tt>a.erase(q1, q2)</tt>
 from <tt>void</tt> to <tt>iterator</tt>.  Change the
 assertion/not/pre/post-condition from "erases the elements in the
@@ -5518,7 +5581,7 @@ in the standard.</p>
 
 <hr>
 <h3><a name="139"></a>139. Optional sequence operation table description unclear</h3>
-<p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
+<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-03-30</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#TC">TC</a> status.</p>
@@ -5855,7 +5918,7 @@ two places:</p>
 
 <hr>
 <h3><a name="150"></a>150. Find_first_of says integer instead of iterator </h3>
-<p><b>Section:</b> 25.1.4 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
+<p><b>Section:</b> 25.1.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
  <b>Submitter:</b> Matt McClure <b>Date:</b> 1999-06-30</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
@@ -5863,7 +5926,7 @@ two places:</p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Change 25.1.4 [alg.find.first.of] paragraph 2 from:</p>
+<p>Change 25.1.7 [alg.find.first.of] paragraph 2 from:</p>
 
 <blockquote>
 <p>Returns: The first iterator i in the range [first1, last1) such
@@ -5882,7 +5945,7 @@ that for some iterator j in the range [first2, last2) ...</p>
 
 <hr>
 <h3><a name="151"></a>151. Can't currently clear() empty container</h3>
-<p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
+<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
  <b>Submitter:</b> Ed Brey <b>Date:</b> 1999-06-21</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#TC">TC</a> status.</p>
@@ -7263,12 +7326,12 @@ Josuttis provided the above wording.]</i></p>
 
 <hr>
 <h3><a name="185"></a>185. Questionable use of term "inline"</h3>
-<p><b>Section:</b> 20.5 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> UK Panel <b>Date:</b> 1999-07-26</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>Paragraph 4 of 20.5 [function.objects] says:</p>
+<p>Paragraph 4 of 20.6 [function.objects] says:</p>
 <blockquote>
   <p>&nbsp;[Example: To negate every element of a: transform(a.begin(), a.end(),
   a.begin(), negate&lt;double&gt;()); The corresponding functions will inline
@@ -7295,17 +7358,17 @@ not required elsewhere.</p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>In 20.5 [function.objects] paragraph 1, remove the sentence:</p>
+<p>In 20.6 [function.objects] paragraph 1, remove the sentence:</p>
 <blockquote>
 <p>They are important for the effective use of the library.</p>
 </blockquote>
-<p>Remove 20.5 [function.objects] paragraph 2, which reads:</p>
+<p>Remove 20.6 [function.objects] paragraph 2, which reads:</p>
 <blockquote>
   <p> Using function objects together with function templates
   increases the expressive power of the library as well as making the
   resulting code much more efficient.</p>
 </blockquote>
-<p>In 20.5 [function.objects] paragraph 4, remove the sentence:</p>
+<p>In 20.6 [function.objects] paragraph 4, remove the sentence:</p>
 <blockquote>
   <p>The corresponding functions will inline the addition and the
   negation.</p>
@@ -8461,7 +8524,6 @@ is.setstate(ios::failbit) which may throw ios_base::failure
 <h3><a name="212"></a>212. Empty range behavior unclear for several algorithms</h3>
 <p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 2000-02-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</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#TC">TC</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -8760,7 +8822,7 @@ footnote.</p>
 
 <hr>
 <h3><a name="224"></a>224. clear() complexity for associative containers refers to undefined N</h3>
-<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
+<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
  <b>Submitter:</b> Ed Brey <b>Date:</b> 2000-03-23</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#TC">TC</a> status.</p>
@@ -9401,7 +9463,7 @@ change "T is Assignable" to "T is CopyConstructible and
 Assignable"
 </p>
 
-<p>In 23.1.2 [associative.reqmts] table 69 X::key_type; change
+<p>In 23.1.4 [associative.reqmts] table 69 X::key_type; change
 "Key is Assignable" to "Key is
 CopyConstructible and Assignable"<br>
 </p>
@@ -9585,7 +9647,7 @@ rationale.]</i></p>
 
 <hr>
 <h3><a name="233"></a>233. Insertion hints in associative containers</h3>
-<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-04-30</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#WP">WP</a> status.</p>
@@ -9693,7 +9755,7 @@ is no longer needed (or reflected in the proposed wording below).
 
 <p>
 Change the indicated rows of the "Associative container requirements" Table in
-23.1.2 [associative.reqmts] to:
+23.1.4 [associative.reqmts] to:
 </p>
 
 <p></p><center>
@@ -9736,7 +9798,7 @@ logarithmic in general, but amortized constant if <tt>t</tt> is inserted right <
 
 <hr>
 <h3><a name="234"></a>234. Typos in allocator definition</h3>
-<p><b>Section:</b> 20.6.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -9888,7 +9950,7 @@ applications of the corresponding predicate.</p></blockquote>
 
 <hr>
 <h3><a name="240"></a>240. Complexity of adjacent_find() is meaningless</h3>
-<p><b>Section:</b> 25.1.5 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 25.1.8 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -9928,7 +9990,7 @@ an "as-if" specification.</p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Change the complexity section in 25.1.5 [alg.adjacent.find] to:</p>
+<p>Change the complexity section in 25.1.8 [alg.adjacent.find] to:</p>
 <blockquote><p>
 For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
 (<i>last</i> - <i>first</i>) - 1)</tt> applications of the
@@ -10519,6 +10581,7 @@ issue is stylistic rather than a matter of correctness.</p>
 <h3><a name="253"></a>253. valarray helper functions are almost entirely useless</h3>
 <p><b>Section:</b> 26.5.2.1 [valarray.cons], 26.5.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Robert Klarer <b>Date:</b> 2000-07-31</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</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#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -11471,7 +11534,7 @@ Change the following sentence in 21.3 paragraph 5 from
 
 <hr>
 <h3><a name="264"></a>264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3>
-<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> John Potter <b>Date:</b> 2000-09-07</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#WP">WP</a> status.</p>
@@ -12425,7 +12488,6 @@ this solution is safe and correct.
 <h3><a name="281"></a>281. std::min() and max() requirements overly restrictive</h3>
 <p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-02</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</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#WP">WP</a> status.</p>
 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#486">486</a></p>
@@ -12675,11 +12737,11 @@ imposing a greater restriction that what the standard currently says
 
 <hr>
 <h3><a name="284"></a>284. unportable example in 20.3.7, p6</h3>
-<p><b>Section:</b> 20.5.7 [comparisons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.6.7 [comparisons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-26</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>The example in 20.5.7 [comparisons], p6 shows how to use the C
+<p>The example in 20.6.7 [comparisons], p6 shows how to use the C
 library function <tt>strcmp()</tt> with the function pointer adapter
 <tt>ptr_fun()</tt>. But since it's unspecified whether the C library
 functions have <tt>extern "C"</tt> or <tt>extern
@@ -12691,7 +12753,7 @@ well-formed is unspecified.
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Change 20.5.7 [comparisons] paragraph 6 from:</p>
+<p>Change 20.6.7 [comparisons] paragraph 6 from:</p>
 <blockquote>
   <p>[<i>Example:</i></p>
   <pre>    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
@@ -13035,7 +13097,6 @@ it isn't stringent enough.</p>
 <h3><a name="295"></a>295. Is abs defined in &lt;cmath&gt;?</h3>
 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Jens Maurer <b>Date:</b> 2001-01-12</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -13072,7 +13133,7 @@ putting in &lt;cstdlib&gt;.  That's issue <a href="http://www.open-std.org/jtc1/
 
 <hr>
 <h3><a name="297"></a>297. const_mem_fun_t&lt;&gt;::argument_type should be const T*</h3>
-<p><b>Section:</b> 20.5.8 [logical.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.6.8 [logical.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-06</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -14044,7 +14105,7 @@ comment in c++std-lib-8939.
 <p><b>Discussion:</b></p>
 <p>Table 27 in section 20 lists the header &lt;memory&gt; (only) for
 Memory (lib.memory) but neglects to mention the headers
-&lt;cstdlib&gt; and &lt;cstring&gt; that are discussed in 20.4.5 [meta.rel].</p>
+&lt;cstdlib&gt; and &lt;cstring&gt; that are discussed in 20.5.5 [meta.rel].</p>
 
 
 <p><b>Proposed resolution:</b></p>
@@ -14084,7 +14145,7 @@ Change the "range" from (last - first) to [first, last).
 
 <hr>
 <h3><a name="316"></a>316. Vague text in Table 69</h3>
-<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-04</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#WP">WP</a> status.</p>
@@ -14306,7 +14367,7 @@ Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
 <p>Effects: Replaces the contents of the list with the range [first, last).</p>
 </blockquote>
 
-<p>In 23.1.1 [sequence.reqmts], in Table 67 (sequence requirements), 
+<p>In 23.1.3 [sequence.reqmts], in Table 67 (sequence requirements), 
 add two new rows:</p>
 <pre>      a.assign(i,j)     void      pre: i,j are not iterators into a.
                                   Replaces elements in a with a copy
@@ -14791,7 +14852,7 @@ reallocation guarantees was inadvertant.</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-With the change in 17.4.4.8 [res.on.exception.handling] to state
+With the change in 17.4.4.9 [res.on.exception.handling] to state
    "An implementation may strengthen the exception-specification for a 
     non-virtual function by removing listed exceptions."
 (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>)
@@ -15093,7 +15154,7 @@ library (though a deprecated one).</p>
 <li>17.4.1.2 [headers] Headers/4</li>
 <li>17.4.3.5 [replacement.functions] Replacement functions/1</li>
 <li>17.4.4.3 [global.functions] Global or non-member functions/2</li>
-<li>17.4.4.6 [protection.within.classes] Protection within classes/1</li>
+<li>17.4.4.7 [protection.within.classes] Protection within classes/1</li>
 </ul>
 
 
@@ -15687,7 +15748,7 @@ be considered NAD.</p>
 
 <hr>
 <h3><a name="354"></a>354. Associative container lower/upper bound requirements</h3>
-<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Hans Aberg <b>Date:</b> 2001-12-17</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#WP">WP</a> status.</p>
@@ -15727,7 +15788,7 @@ the intention (and not possible with the "const" versions).
 
 <p><b>Proposed resolution:</b></p>
 
-<p>Change Table 69 of section 23.1.2 [associative.reqmts] indicated entries
+<p>Change Table 69 of section 23.1.4 [associative.reqmts] indicated entries
 to:</p>
 
 <blockquote>
@@ -15753,7 +15814,7 @@ key greater than k, or a.end() if such an element is not found.
 
 <hr>
 <h3><a name="355"></a>355. Operational semantics for a.back()</h3>
-<p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Yaroslav Mironov <b>Date:</b> 2002-01-23</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#WP">WP</a> status.</p>
@@ -16453,7 +16514,7 @@ erase_if() member function that much greater.
 
 <p><b>Proposed resolution:</b></p>
 
-<p>Add the following to the end of 23.1.2 [associative.reqmts] paragraph 4: 
+<p>Add the following to the end of 23.1.4 [associative.reqmts] paragraph 4: 
 "For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt>
   are <i>stable</i>: they preserve the relative ordering of equivalent
   elements.</p> 
@@ -17052,7 +17113,6 @@ const in the header file synopsis in section 22.1 [locales].
 <h3><a name="395"></a>395. inconsistencies in the definitions of rand() and random_shuffle()</h3>
 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> James Kanze <b>Date:</b> 2003-01-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -17105,13 +17165,13 @@ implementation is permitted to use <tt>rand</tt>.]
 
 <hr>
 <h3><a name="400"></a>400. redundant type cast in lib.allocator.members</h3>
-<p><b>Section:</b> 20.6.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-20.6.5.1 [allocator.members] allocator members, contains
+20.7.5.1 [allocator.members] allocator members, contains
 the following 3 lines:
 </p>
 
@@ -17223,7 +17283,7 @@ issue to Ready status to be voted into the WP at Kona.
 
 <hr>
 <h3><a name="402"></a>402. wrong new expression in [some_]allocator::construct</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements], 20.6.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.1.2 [allocator.requirements], 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</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>
@@ -17231,13 +17291,13 @@ issue to Ready status to be voted into the WP at Kona.
 <p><b>Discussion:</b></p>
 <p>
 This applies to the new expression that is contained in both par12 of
-20.6.5.1 [allocator.members] and in par2 (table 32) of  [default.con.req].
+20.7.5.1 [allocator.members] and in par2 (table 32) of  [default.con.req].
 I think this new expression is wrong, involving unintended side
 effects.
 </p>
 
 
-<p>20.6.5.1 [allocator.members]  contains the following 3 lines:</p>
+<p>20.7.5.1 [allocator.members]  contains the following 3 lines:</p>
 
 <pre>  11 Returns: the largest value N for which the call allocate(N,0) might succeed.
      void construct(pointer p, const_reference val);
@@ -18094,7 +18154,7 @@ use the right wording.]</i></p>
 
 <hr>
 <h3><a name="425"></a>425. return value of std::get_temporary_buffer</h3>
-<p><b>Section:</b> 20.6.8 [temporary.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.7.8 [temporary.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -18109,7 +18169,7 @@ is when the argument is less than 0.
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Change 20.4.3 [meta.help] paragraph 2 from "...or a pair of 0
+<p>Change 20.5.3 [meta.help] paragraph 2 from "...or a pair of 0
 values if no storage can be obtained" to "...or a pair of 0 values if
 no storage can be obtained or if <i>n</i> &lt;= 0."</p>
 <p><i>[Kona: Matt provided wording]</i></p>
@@ -18120,7 +18180,7 @@ no storage can be obtained or if <i>n</i> &lt;= 0."</p>
 
 <hr>
 <h3><a name="426"></a>426. search_n(), fill_n(), and generate_n() with negative n</h3>
-<p><b>Section:</b> 25.1.9 [alg.search], 25.2.6 [alg.fill], 25.2.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 25.1.12 [alg.search], 25.2.6 [alg.fill], 25.2.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.search">issues</a> in [alg.search].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -18677,13 +18737,13 @@ text.]</i></p>
 
 <hr>
 <h3><a name="438"></a>438. Ambiguity in the "do the right thing" clause</h3>
-<p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
+<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2003-10-20</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#DR">DR</a> status.</p>
 <p><b>Discussion:</b></p>
 
-<p>Section 23.1.1 [sequence.reqmts], paragraphs 9-11, fixed up the problem
+<p>Section 23.1.3 [sequence.reqmts], paragraphs 9-11, fixed up the problem
 noticed with statements like:</p>
 <pre>vector&lt;int&gt; v(10, 1);
 </pre>
@@ -18881,7 +18941,7 @@ T implicit_cast(const U&amp; u)
 
 <p><b>Proposed resolution:</b></p>
 
-<p>Replace 23.1.1 [sequence.reqmts] paragraphs 9 - 11 with:</p>
+<p>Replace 23.1.3 [sequence.reqmts] paragraphs 9 - 11 with:</p>
 
 <p>For every sequence defined in this clause and in clause lib.strings:</p>
 
@@ -19068,7 +19128,6 @@ of <tt>sentry::operator bool()</tt> to const.
 <h3><a name="443"></a>443. filebuf::close() inconsistent use of EOF</h3>
 <p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#filebuf.members">active issues</a> in [filebuf.members].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.members].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -19607,7 +19666,6 @@ names within the namespace <tt>std</tt>.</ins> <i>-- end example</i>]
 <h3><a name="457"></a>457. bitset constructor: incorrect number of initialized bits</h3>
 <p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
  <b>Submitter:</b> Dag Henriksson <b>Date:</b> 2004-01-30</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#bitset.cons">active issues</a> in [bitset.cons].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -20084,7 +20142,7 @@ I propose to strike the Footnote.
 
 <hr>
 <h3><a name="475"></a>475. May the function object passed to for_each modify the elements of the iterated sequence?</h3>
-<p><b>Section:</b> 25.1.1 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 25.1.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Date:</b> 2004-07-09</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#WP">WP</a> status.</p>
@@ -20149,7 +20207,7 @@ passed to for_each modify its argument.</p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Add a nonnormative note to the Effects in 25.1.1 [alg.foreach]: If
+<p>Add a nonnormative note to the Effects in 25.1.4 [alg.foreach]: If
 the type of 'first' satisfies the requirements of a mutable iterator,
 'f' may apply nonconstant functions through the dereferenced iterators
 passed to it.
@@ -20653,6 +20711,75 @@ just above paragraph 5.
 
 
 <hr>
+<h3><a name="518"></a>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3>
+<p><b>Section:</b> 23.1.5 [unord.req], TR1 6.3.1 [tr.unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Matt Austern <b>Date:</b> 2005-07-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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Issue 371 deals with stability of multiset/multimap under insert and erase
+(i.e. do they preserve the relative order in ranges of equal elements).
+The same issue applies to unordered_multiset and unordered_multimap.
+</p>
+<p><i>[
+Moved to open (from review):  There is no resolution.
+]</i></p>
+
+
+<p><i>[
+Toronto:  We have a resolution now.  Moved to Review.  Some concern was noted
+as to whether this conflicted with existing practice or not.  An additional
+concern was in specifying (partial) ordering for an unordered container.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Wording for the proposed resolution is taken from the equivalent text for associative containers.
+</p>
+
+<p>
+Change 23.1.5 [unord.req], Unordered associative containers, paragraph 6 to:
+</p>
+
+<blockquote><p>
+An unordered associative container supports <i>unique</i> keys if it may 
+contain at most one element for each key. Otherwise, it supports <i>equivalent 
+keys</i>. <tt>unordered_set</tt> and <tt>unordered_map</tt> support 
+unique keys. <tt>unordered_multiset</tt> and <tt>unordered_multimap</tt> 
+support equivalent keys. In containers that support equivalent keys, elements 
+with equivalent keys are adjacent to each other. <ins>For
+<tt>unordered_multiset</tt> 
+and <tt>unordered_multimap</tt>,<tt> insert</tt> and <tt>erase</tt> 
+preserve the relative ordering of equivalent elements.</ins>
+</p></blockquote>
+
+<p>
+Change 23.1.5 [unord.req], Unordered associative containers, paragraph 8 to:
+</p>
+
+<blockquote>
+<p>The elements of an unordered associative container are organized into <i>
+buckets</i>. Keys with the same hash code appear in the same bucket. The number 
+of buckets is automatically increased as elements are added to an unordered 
+associative container, so that the average number of elements per bucket is kept 
+below a bound. Rehashing invalidates iterators, changes ordering between 
+elements, and changes which buckets elements appear in, but does not invalidate 
+pointers or references to elements. <ins>For <tt>unordered_multiset</tt> 
+and <tt>unordered_multimap</tt>, rehashing 
+preserves the relative ordering of equivalent elements.</ins></p>
+</blockquote>
+
+
+
+
+
+
+<hr>
 <h3><a name="519"></a>519. Data() undocumented</h3>
 <p><b>Section:</b> 23.2.1 [array], TR1 6.2.2 [tr.array.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
@@ -20689,7 +20816,7 @@ of <tt>data()</tt> is unspecified.
 
 <hr>
 <h3><a name="520"></a>520. Result_of and pointers to data members</h3>
-<p><b>Section:</b> 20.5.11.1 [func.bind], TR1 3.6 [tr.func.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.6.11.1 [func.bind], TR1 3.6 [tr.func.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -20732,7 +20859,7 @@ Peter provided wording.
 
 <hr>
 <h3><a name="521"></a>521. Garbled requirements for argument_type in reference_wrapper</h3>
-<p><b>Section:</b> 20.5.5 [refwrap], TR1 2.1.2 [tr.util.refwrp.refwrp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.6.5 [refwrap], TR1 2.1.2 [tr.util.refwrp.refwrp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -20881,7 +21008,7 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 <hr>
 <h3><a name="527"></a>527. tr1::bind has lost its Throws clause</h3>
-<p><b>Section:</b> 20.5.11.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.6.11.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2005-10-01</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>
@@ -20949,7 +21076,7 @@ throws an exception.
 
 <p><b>Proposed resolution:</b></p>
 <p>
-In 20.5.11.1.3 [func.bind.bind], add a new paragraph after p2:
+In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p2:
 </p>
 
 <blockquote>
@@ -20958,7 +21085,7 @@ in the <tt>BoundArgs...</tt> pack expansion throws an exception.
 </blockquote>
 
 <p>
-In 20.5.11.1.3 [func.bind.bind], add a new paragraph after p4:
+In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p4:
 </p>
 
 <blockquote>
@@ -21103,7 +21230,7 @@ writing to out of bounds memory when <tt>n == 0</tt>.  Martin provided fix.
 
 <hr>
 <h3><a name="533"></a>533. typo in 2.2.3.10/1</h3>
-<p><b>Section:</b> 20.6.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
+<p><b>Section:</b> 20.7.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2005-11-09</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
@@ -21428,7 +21555,7 @@ Otherwise CopyConstructible is not required.
 
 <hr>
 <h3><a name="540"></a>540. shared_ptr&lt;void&gt;::operator*()</h3>
-<p><b>Section:</b> 20.6.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.7.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-15</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#WP">WP</a> status.</p>
@@ -21486,7 +21613,7 @@ definition) of the function shall be well-formed.</ins>
 
 <hr>
 <h3><a name="541"></a>541. shared_ptr template assignment and void</h3>
-<p><b>Section:</b> 20.6.12.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-16</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>
@@ -21567,7 +21694,7 @@ public:
 
 <hr>
 <h3><a name="542"></a>542. shared_ptr observers</h3>
-<p><b>Section:</b> 20.6.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.7.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-18</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#WP">WP</a> status.</p>
@@ -21607,7 +21734,7 @@ capture the intent.
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change 20.6.12.2.5 [util.smartptr.shared.obs] p12:
+Change 20.7.12.2.5 [util.smartptr.shared.obs] p12:
 </p>
 <blockquote><p>
 [<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
@@ -21615,7 +21742,7 @@ debugging and testing purposes, not for production code.</del> --<i>end note</i>
 </p></blockquote>
 
 <p>
-Change 20.6.12.3.5 [util.smartptr.weak.obs] p3:
+Change 20.7.12.3.5 [util.smartptr.weak.obs] p3:
 </p>
 <blockquote><p>
 [<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
@@ -21704,7 +21831,7 @@ lengths, and strides, as explained in the previous section.
 
 <hr>
 <h3><a name="545"></a>545. When is a deleter deleted?</h3>
-<p><b>Section:</b> 20.6.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.7.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -21722,7 +21849,7 @@ instances). We should say which it is.
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add after the first sentence of 20.6.12.2.11 [util.smartptr.getdeleter]/1:
+Add after the first sentence of 20.7.12.2.11 [util.smartptr.getdeleter]/1:
 </p>
 <blockquote>
 <p>
@@ -21741,6 +21868,144 @@ This can happen if the implementation doesn't destroy the deleter until all
 
 
 <hr>
+<h3><a name="550"></a>550. What should the return type of pow(float,int) be?</h3>
+<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-12</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Assuming we adopt the
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">C
+compatibility package from C99</a>  what should be the return type of the
+following signature be:
+</p>
+<blockquote><pre>?  pow(float, int);
+</pre></blockquote>
+<p>
+C++03 says that the return type should be <tt>float</tt>. 
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
+TR1</a> and C90/99 say the return type should be <tt>double</tt>.  This can put
+clients into a situation where C++03 provides answers that are not as high
+quality as C90/C99/TR1.  For example:
+</p>
+<blockquote><pre>#include &lt;math.h&gt;
+
+int main()
+{
+    float x = 2080703.375F;
+    double y = pow(x, 2);
+}
+</pre></blockquote>
+<p>
+Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest:
+</p>
+
+<blockquote><pre>y = 4329326534736.390625
+</pre></blockquote>
+
+<p>
+which is exactly right.  While C++98/C++03 demands:
+</p>
+
+<blockquote><pre>y = 4329326510080.
+</pre></blockquote>
+
+<p>
+which is only approximately right.
+</p>
+
+<p>
+I recommend that C++0X adopt the mixed mode arithmetic already adopted by
+Fortran, C and TR1 and make the return type of <tt>pow(float,int)</tt> be
+<tt>double</tt>.
+</p>
+
+<p><i>[
+Kona (2007): Other functions that are affected by this issue include
+<tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt>. We also believe that there is a typo in
+26.7/10: <tt>float nexttoward(float, long double);</tt> [sic] should be <tt>float
+nexttoward(float, float);</tt> Proposed Disposition: Review (the proposed
+resolution appears above, rather than below, the heading "Proposed
+resolution")
+]</i></p>
+
+
+<p><i>[
+<p>
+Howard, post Kona:
+</p>
+<blockquote>
+<p>
+Unfortunately I strongly disagree with a part of the resolution
+from Kona.  I am moving from New to Open instead of to Review because I do not believe
+we have consensus on the intent of the resolution.
+</p>
+<p>
+This issue does not include <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt> because
+the second integral parameter in each of these signatures (from C99) is <b>not</b> a
+<i>generic parameter</i> according to C99 7.22p2.  The corresponding C++ overloads are
+intended (as far as I know) to correspond directly to C99's definition of <i>generic parameter</i>.
+</p>
+<p>
+For similar reasons, I do not believe that the second <tt>long double</tt> parameter of
+<tt>nexttoward</tt>, nor the return type of this function, is in error.  I believe the
+correct signature is:
+</p>
+<blockquote>
+<pre>float nexttoward(float, long double);
+</pre>
+</blockquote>
+<p>
+which is what both the C++0X working paper and C99 state (as far as I currently understand).
+</p>
+<p>
+This is really <b>only</b> about <tt>pow(float, int)</tt>.  And this is because C++98 took one
+route (with <tt>pow</tt> only) and C99 took another (with many math functions in <tt>&lt;tgmath.h&gt;</tt>.
+The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99.
+</p>
+</blockquote>
+]</i></p>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+This signature was not picked up from C99. Instead, if one types
+pow(2.0f,2), the promotion rules will invoke "double pow(double,
+double)", which generally gives special treatment for integral
+exponents, preserving full accuracy of the result.  New proposed
+wording provided.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 26.7 [c.math] p10:
+</p>
+
+<blockquote>
+<p>
+The added signatures are:
+</p>
+<blockquote><pre>...
+<del>float pow(float, int);</del>
+...
+<del>double pow(double, int);</del>
+...
+<del>long double pow(long double, int);</del>
+</pre></blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
 <h3><a name="551"></a>551. &lt;ccomplex&gt;</h3>
 <p><b>Section:</b> 26.3.11 [cmplxh], TR1 8.3 [tr.c99.cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-23</p>
@@ -22376,8 +22641,60 @@ Kona (2007): Proposed Disposition: Ready
 
 
 <hr>
+<h3><a name="574"></a>574. DR 369 Contradicts Text</h3>
+<p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Pete Becker <b>Date:</b> 2006-04-18</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+lib.iostream.objects requires that the standard stream objects are never
+destroyed, and it requires that they be destroyed.
+</p>
+<p>
+DR 369 adds words to say that we really mean for ios_base::Init objects to force
+construction of standard stream objects. It ends, though, with the phrase "these
+stream objects shall be destroyed after the destruction of dynamically ...".
+However, the rule for destruction is stated in the standard: "The objects are
+not destroyed during program execution."
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 27.3 [iostream.objects]/1:
+</p>
+
+<blockquote>
+<p>
+-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>290)</sup> The objects are not destroyed during program
+execution.<sup>291)</sup> If a translation unit includes <tt>&lt;iostream&amp;t;</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>, and these stream objects shall be
+destroyed after the destruction of dynamically initialized non-local
+objects defined later in that translation unit</del>.
+</p>
+</blockquote>
+
+
+<p><i>[
+Kona (2007): From 27.3 [iostream.objects]/2, strike the words "...and these stream objects
+shall be destroyed after the destruction of dynamically initialized
+non-local objects defined later in that translation unit." Proposed
+Disposition: Review
+]</i></p>
+
+
+
+
+
+<hr>
 <h3><a name="575"></a>575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions</h3>
-<p><b>Section:</b> 20.6.12.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.7.12.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-04-23</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -22455,7 +22772,7 @@ after <tt>*this</tt> is destroyed. <i>--end note</i>]
 
 <hr>
 <h3><a name="576"></a>576. find_first_of is overconstrained</h3>
-<p><b>Section:</b> 25.1.4 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 25.1.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Doug Gregor <b>Date:</b> 2006-04-25</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -22558,7 +22875,7 @@ conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j)
 
 <hr>
 <h3><a name="578"></a>578. purpose of hint to allocator::allocate()</h3>
-<p><b>Section:</b> 20.6.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-17</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -22867,96 +23184,386 @@ particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
 
 
 <hr>
-<h3><a name="598"></a>598. Decimal: Conversion to integral should truncate, not round.</h3>
-<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<h3><a name="595"></a>595. TR1/C++0x: fabs(complex&lt;T&gt;) redundant / wrongly specified</h3>
+<p><b>Section:</b> 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Stefan Große Pawig <b>Date:</b> 2006-09-24</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
-
 <p>
-In a private email, Daniel writes:
+TR1 introduced, in the C compatibility chapter, the function
+fabs(complex&lt;T&gt;):
 </p>
-<blockquote>
+<blockquote><pre>----- SNIP -----
+8.1.1 Synopsis                                [tr.c99.cmplx.syn]
+
+  namespace std {
+  namespace tr1 {
+[...]
+  template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp; x);
+  } // namespace tr1
+  } // namespace std
+
+[...]
+
+8.1.8 Function fabs                          [tr.c99.cmplx.fabs]
+
+1 Effects: Behaves the same as C99 function cabs, defined in
+  subclause 7.3.8.1.
+----- SNIP -----
+</pre></blockquote>
+
 <p>
-I would like to 
-ask, what where the reason for the decision to 
-define the semantics of the integral conversion of the decimal types, namely
+The current C++0X draft document (n2009.pdf) adopted this
+definition in chapter 26.3.1 (under the comment // 26.3.7 values)
+and 26.3.7/7.
 </p>
-<pre>"operator long long() const;
-
-     Returns: Returns the result of the 
-conversion of *this to the type long long, as if 
-performed by the expression llrounddXX(*this)."
-</pre>
 <p>
-where XX stands for either 32, 64, or 128, 
-corresponding to the proper decimal type. The 
-exact meaning of llrounddXX is not given in that 
-paper, so I compared it to the corresponding 
-definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2:
+But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
+n1124), the referenced subclause reads
 </p>
+
+<blockquote><pre>----- SNIP -----
+7.3.8.1 The cabs functions
+
+  Synopsis
+
+1 #include &lt;complex.h&gt;
+  double cabs(double complex z);
+  float cabsf(float complex z);
+  long double cabsl(long double z);
+
+  Description
+
+2 The cabs functions compute the complex absolute value (also called
+  norm, modulus, or magnitude) of z.
+
+  Returns
+
+3 The cabs functions return the complex absolute value.
+----- SNIP -----
+</pre></blockquote>
+
 <p>
-"The lround and llround functions round their 
-argument to the nearest integer value,
-rounding halfway cases away from zero, regardless 
-of the current rounding direction. [..]"
+Note that the return type of the cabs*() functions is not a complex
+type.  Thus, they are equivalent to the already well established
+  template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp; x);
+(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft
+document n2009.pdf).
 </p>
 <p>
-Now considering the fact that integral conversion 
-of the usual floating-point types ("4.9 
-Floating-integral conversions") has truncation 
-semantic I wonder why this conversion behaviour 
-has not been transferred for the decimal types. 
+So either the return value of fabs() is specified wrongly, or fabs()
+does not behave the same as C99's cabs*().
 </p>
-</blockquote>
+
+<b>Possible Resolutions</b>
+
 <p>
-Robert comments:
+This depends on the intention behind the introduction of fabs().
 </p>
 <p>
-Also, there is a further error in the <b>Returns:</b> clause for converting <code>decimal::decimal128</code> to <code>long long</code>.  It currently calls <code>llroundd64</code>, not <code>llroundd128</code>.
+If the intention was to provide a /complex/ valued function that
+calculates the magnitude of its argument, this should be
+explicitly specified.  In TR1, the categorization under "C
+compatibility" is definitely wrong, since C99 does not provide
+such a complex valued function.
 </p>
-
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Change the <b>Returns:</b> clause in 3.2.2.4 to:
+Also, it remains questionable if such a complex valued function
+is really needed, since complex&lt;T&gt; supports construction and
+assignment from real valued arguments.  There is no difference
+in observable behaviour between
 </p>
-<blockquote><p>
-<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd32(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
-</p></blockquote>
+<blockquote><pre>  complex&lt;double&gt; x, y;
+  y = fabs(x);
+  complex&lt;double&gt; z(fabs(x));
+</pre></blockquote>
 <p>
-Change the <b>Returns:</b> clause in 3.2.3.4 to:
+and
 </p>
-<blockquote><p>
-<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd64(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
-</p></blockquote>
+<blockquote><pre>  complex&lt;double&gt; x, y;
+  y = abs(x);
+  complex&lt;double&gt; z(abs(x));
+</pre></blockquote>
 <p>
-Change the <b>Returns:</b> clause in 3.2.4.4 to:
+If on the other hand the intention was to provide the intended
+functionality of C99, fabs() should be either declared deprecated
+or (for C++0X) removed from the standard, since the functionality
+is already provided by the corresponding overloads of abs().
 </p>
-<blockquote><p>
-<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <del><code>llroundd64(*this)</code></del> <ins><code>llroundd128(*this)</code> while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
-</p></blockquote>
 
+<p><i>[
+Bellevue:
+]</i></p>
 
 
+<blockquote>
+Bill believes that abs() is a suitable overload. We should remove fabs().
+</blockquote>
 
 
+<p><b>Proposed resolution:</b></p>
 
-<hr>
-<h3><a name="599"></a>599. Decimal: Say "octets" instead of "bytes."</h3>
-<p><b>Section:</b> TRDecimal 3.1 [trdec.types.encodings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-Daniel writes in a private email:
+Change the synopsis in 26.3.1 [complex.synopsis]:
 </p>
 
-<blockquote>
-<p>
+<blockquote><pre><del>template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp;);</del>
+</pre></blockquote>
+
+<p>
+Remove 26.3.7 [complex.value.ops], p7:
+</p>
+
+<blockquote>
+<pre><del>template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp; <i>x</i>);</del>
+</pre>
+<blockquote>
+<p>
+<del>-7- <i>Effects:</i> Behaves the same as C99 function <tt>cabs</tt>, defined in subclause 7.3.8.1.</del>
+</p>
+</blockquote>
+</blockquote>
+
+
+
+<p><i>[
+Kona (2007): Change the return type of <tt>fabs(complex)</tt> to <tt>T</tt>. 
+Proposed Disposition: Ready
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="596"></a>596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes</h3>
+<p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Thomas Plum <b>Date:</b> 2006-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.members].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke  
+</p>
+<blockquote><pre>   ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
+</pre></blockquote>
+<p>
+and we expect the open to fail, because out|in|app is not listed in
+Table 92, and just before the table we see very specific words:
+</p>
+<blockquote><p>
+  If mode is not some combination of flags shown in the table 
+  then the open fails.
+</p></blockquote>
+<p>
+But the corresponding table in the C standard, 7.19.5.3, provides two
+modes "a+" and "a+b", to which the C++ modes out|in|app and
+out|in|app|binary would presumably apply.
+</p>
+<p>
+We would like to argue that the intent of Table 112 was to match the
+semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was
+unintentional.  (Otherwise there would be valid and useful behaviors
+available in C file I/O which are unavailable using C++, for no
+valid functional reason.)
+</p>
+<p>
+We further request that the missing modes be explicitly restored to
+the WP, for inclusion in C++0x.
+</p>
+
+<p><i>[
+Martin adds:
+]</i></p>
+
+
+<p>
+...besides "a+" and "a+b" the C++ table is also missing a row
+for a lone app bit which in at least two current implementation
+as well as in Classic Iostreams corresponds to the C stdio "a"
+mode and has been traditionally documented as implying ios::out.
+Which means the table should also have a row for in|app meaning
+the same thing as "a+" already proposed in the issue.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:
+</p>
+
+<blockquote>
+<table border="1">
+<caption> File open modes</caption>
+<tbody><tr>
+<th colspan="5"><tt>ios_base</tt> Flag combination</th>
+<th><tt>stdio</tt> equivalent</th>
+</tr>
+<tr>
+<th><tt>binary</tt></th><th><tt>in</tt></th><th><tt>out</tt></th><th><tt>trunc</tt></th><th><tt>app</tt></th><th><tt>&nbsp;</tt></th>
+</tr>
+
+<tr>
+<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
+</tr>
+<tr>
+<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"a"</tt></td>
+</tr>
+<tr>
+<td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a"</tt></ins></td>
+</tr>
+<tr>
+<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
+</tr>
+<tr>
+<td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r"</tt></td>
+</tr>
+<tr>
+<td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+"</tt></td>
+</tr>
+<tr>
+<td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+"</tt></td>
+</tr>
+<tr>
+<td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
+</tr>
+<tr>
+<td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
+</tr>
+
+<tr>
+<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
+</tr>
+<tr>
+<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"ab"</tt></td>
+</tr>
+<tr>
+<td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"ab"</tt></ins></td>
+</tr>
+<tr>
+<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
+</tr>
+<tr>
+<td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"rb"</tt></td>
+</tr>
+<tr>
+<td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+b"</tt></td>
+</tr>
+<tr>
+<td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+b"</tt></td>
+</tr><tr>
+<td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
+</tr>
+<tr>
+<td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
+</tr>
+
+
+</tbody></table>
+</blockquote>
+
+
+
+<p><i>[
+Kona (2007) Added proposed wording and moved to Review.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="598"></a>598. Decimal: Conversion to integral should truncate, not round.</h3>
+<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+In a private email, Daniel writes:
+</p>
+<blockquote>
+<p>
+I would like to 
+ask, what where the reason for the decision to 
+define the semantics of the integral conversion of the decimal types, namely
+</p>
+<pre>"operator long long() const;
+
+     Returns: Returns the result of the 
+conversion of *this to the type long long, as if 
+performed by the expression llrounddXX(*this)."
+</pre>
+<p>
+where XX stands for either 32, 64, or 128, 
+corresponding to the proper decimal type. The 
+exact meaning of llrounddXX is not given in that 
+paper, so I compared it to the corresponding 
+definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2:
+</p>
+<p>
+"The lround and llround functions round their 
+argument to the nearest integer value,
+rounding halfway cases away from zero, regardless 
+of the current rounding direction. [..]"
+</p>
+<p>
+Now considering the fact that integral conversion 
+of the usual floating-point types ("4.9 
+Floating-integral conversions") has truncation 
+semantic I wonder why this conversion behaviour 
+has not been transferred for the decimal types. 
+</p>
+</blockquote>
+<p>
+Robert comments:
+</p>
+<p>
+Also, there is a further error in the <b>Returns:</b> clause for converting <code>decimal::decimal128</code> to <code>long long</code>.  It currently calls <code>llroundd64</code>, not <code>llroundd128</code>.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the <b>Returns:</b> clause in 3.2.2.4 to:
+</p>
+<blockquote><p>
+<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd32(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
+</p></blockquote>
+<p>
+Change the <b>Returns:</b> clause in 3.2.3.4 to:
+</p>
+<blockquote><p>
+<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd64(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
+</p></blockquote>
+<p>
+Change the <b>Returns:</b> clause in 3.2.4.4 to:
+</p>
+<blockquote><p>
+<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <del><code>llroundd64(*this)</code></del> <ins><code>llroundd128(*this)</code> while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
+</p></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="599"></a>599. Decimal: Say "octets" instead of "bytes."</h3>
+<p><b>Section:</b> TRDecimal 3.1 [trdec.types.encodings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Daniel writes in a private email:
+</p>
+
+<blockquote>
+<p>
 - 3.1 'Decimal type encodings' says in its note:
 </p>
 <pre>"this implies that 
@@ -23530,7 +24137,7 @@ and accept my apologies for the oversight.
 
 <hr>
 <h3><a name="610"></a>610. Suggested non-normative note for C++0x</h3>
-<p><b>Section:</b> 20.5.15.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.6.15.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Scott Meyers <b>Date:</b> 2006-11-02</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -23668,6 +24275,61 @@ component</ins>. </li>
 
 
 <hr>
+<h3><a name="612"></a>612. numeric_limits::is_modulo insufficiently defined</h3>
+<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2006-11-10</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+18.2.1.2 55 states that "A type is modulo if it is possible to add two
+positive numbers together and have a result that wraps around to a
+third number that is less".
+This seems insufficient for the following reasons:
+</p>
+
+<ol>
+<li>Doesn't define what that value received is.</li>
+<li>Doesn't state the result is repeatable</li>
+<li> Doesn't require that doing addition, subtraction and other
+operations on all values is defined behaviour.</li>
+</ol>
+
+<p><i>[
+Batavia: Related to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2144.pdf">N2144</a>.
+Pete: is there an ISO definition of modulo?  Underflow on signed behavior is undefined.
+]</i></p>
+
+
+<p><i>[
+Bellevue:  accept resolution, move to ready status.
+Does this mandate that is_modulo be true on platforms for which int
+happens to b modulo? A: the standard already seems to require that.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Suggest 18.2.1.2 [numeric.limits.members], paragraph 57 is amended to:
+</p>
+
+<blockquote><p>
+A type is modulo if<ins>,</ins> <del>it is possible to add two positive numbers
+and have a result that wraps around to a third number that is less.</del>
+<ins>given any operation involving +,- or * on values of that type whose value
+would fall outside the range <tt>[min(), max()]</tt>, then the value returned
+differs from the true value by an integer multiple of <tt>(max() - min() +
+1)</tt>.</ins>
+</p></blockquote>
+
+
+
+
+
+
+<hr>
 <h3><a name="613"></a>613. max_digits10 missing from numeric_limits</h3>
 <p><b>Section:</b> 18.2.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-11-20</p>
@@ -23795,42 +24457,99 @@ as this is a dependent type, it should obviously be
 
 
 <hr>
-<h3><a name="619"></a>619. Longjmp wording problem</h3>
-<p><b>Section:</b> 18.8 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2007-01-12</p>
+<h3><a name="618"></a>618. valarray::cshift() effects on empty array</h3>
+<p><b>Section:</b> 26.5.2.7 [valarray.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-10</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The wording for <tt>longjmp</tt> is confusing.
-</p>
-<p>
-18.8 [support.runtime] -4- Other runtime support
-</p>
-<blockquote><p>
-The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more restricted
-behavior in this International Standard.  If any automatic objects would
-be destroyed by a thrown exception transferring control to another
-(destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt> that
-the throw point that transfers control to the same (destination) point has
-undefined behavior.
-</p></blockquote>
-<p>
-Someone at Google thinks that should say "then a call to <tt>longjmp(jbuf, val)</tt>
-*at* the throw point that transfers control".
-</p>
-<p>
-Bill Gibbons thinks it should say something like "If any automatic objects
-would be destroyed by an exception thrown at the point of the longjmp and
-caught only at the point of the setjmp, the behavior is undefined."
+I would respectfully request an issue be opened with the intention to
+clarify the wording for <tt>size() == 0</tt> for <tt>cshift</tt>.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-In general, accept Bill Gibbons' recommendation,
-but add "call" to indicate that the undefined behavior
+Change 26.5.2.7 [valarray.members], paragraph 10:
+</p>
+
+<blockquote>
+
+<pre>valarray&lt;T&gt; cshift(int <i>n</i>) const;
+</pre>
+
+<blockquote>
+<p>
+This function returns an object of class <tt>valarray&lt;T&gt;</tt>, of
+length <tt>size()</tt>, <del>each of whose elements <tt>I</tt> is
+<tt>(*this)[(I + n ) % size()]</tt>. Thus, if element zero is taken as
+the leftmost element, a positive value of <i>n</i> shifts the elements
+circularly left <i>n</i> places.</del> <ins>that is a circular shift of <tt>*this</tt>. If
+element zero is taken as the leftmost element, a non-negative value of
+<i>n</i> shifts the elements circularly left <i>n</i> places and a
+negative value of <i>n</i> shifts the elements circularly right
+-<i>n</i> places.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<p>
+We do not believe that there is any real ambiguity about what happens
+when <tt>size() == 0</tt>, but we do believe that spelling this out as a C++
+expression causes more trouble that it solves. The expression is
+certainly wrong when <tt>n &lt; 0</tt>, since the sign of % with negative arguments
+is implementation defined.
+</p>
+
+
+<p><i>[
+Kona (2007) Changed proposed wording, added rationale and set to Review.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="619"></a>619. Longjmp wording problem</h3>
+<p><b>Section:</b> 18.9 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2007-01-12</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The wording for <tt>longjmp</tt> is confusing.
+</p>
+<p>
+18.9 [support.runtime] -4- Other runtime support
+</p>
+<blockquote><p>
+The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more restricted
+behavior in this International Standard.  If any automatic objects would
+be destroyed by a thrown exception transferring control to another
+(destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt> that
+the throw point that transfers control to the same (destination) point has
+undefined behavior.
+</p></blockquote>
+<p>
+Someone at Google thinks that should say "then a call to <tt>longjmp(jbuf, val)</tt>
+*at* the throw point that transfers control".
+</p>
+<p>
+Bill Gibbons thinks it should say something like "If any automatic objects
+would be destroyed by an exception thrown at the point of the longjmp and
+caught only at the point of the setjmp, the behavior is undefined."
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In general, accept Bill Gibbons' recommendation,
+but add "call" to indicate that the undefined behavior
 comes from the dynamic call, not from its presence in the code.
-In 18.8 [support.runtime] paragraph 4, change
+In 18.9 [support.runtime] paragraph 4, change
 </p>
 
 <blockquote><p>
@@ -23852,6 +24571,7 @@ undefined behavior if replacing the <tt>setjmp</tt> and <tt>longjmp</tt> by
 <h3><a name="620"></a>620. valid uses of empty valarrays</h3>
 <p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</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#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -24053,7 +24773,7 @@ dtor? Should the  dtor catch and swallow it or  should it propagate it
 to the caller?  The text doesn't  seem to provide any guidance in this
 regard  other  than  the  general  restriction on  throwing  (but  not
 propagating)  exceptions  from   destructors  of  library  classes  in
-17.4.4.8 [res.on.exception.handling].
+17.4.4.9 [res.on.exception.handling].
 
         </p>
         <p>
@@ -24168,7 +24888,7 @@ And to make the following edits in 27.8.1.2 [filebuf.cons].
 <code>close()</code>.    <ins>If  an   exception  occurs   during  the
 destruction of the object, including the call to <code>close()</code>,
 the     exception    is     caught    but     not     rethrown    (see
-17.4.4.8 [res.on.exception.handling]).</ins>
+17.4.4.9 [res.on.exception.handling]).</ins>
 
             </p>
         </blockquote>
@@ -24379,7 +25099,7 @@ Change 28.8.2 [re.regex.construct]:
 
 <hr>
 <h3><a name="634"></a>634. <tt>allocator.address()</tt> doesn't work for types overloading <tt>operator&amp;</tt></h3>
-<p><b>Section:</b> 20.6.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-02-07</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -24387,7 +25107,7 @@ Change 28.8.2 [re.regex.construct]:
 <p><b>Discussion:</b></p>
 
 <p>
-20.6.5.1 [allocator.members] says:
+20.7.5.1 [allocator.members] says:
 </p>
 <blockquote>
 <pre>pointer address(reference <i>x</i>) const;</pre>
@@ -24399,7 +25119,7 @@ Change 28.8.2 [re.regex.construct]:
 </blockquote>
 
 <p>
-20.6.5.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not
+20.7.5.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not
 only defines the semantics of copy construction, but also restricts what an overloaded
 <tt>operator&amp;</tt> may do.  I believe proposals are in the works (such as concepts
 and rvalue reference) to decouple these two requirements.  Indeed it is not evident
@@ -24430,7 +25150,7 @@ is expected to make use of <tt>allocator::address</tt> mandatory for containers.
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change 20.6.5.1 [allocator.members]:
+Change 20.7.5.1 [allocator.members]:
 </p>
 
 <blockquote>
@@ -24471,6 +25191,102 @@ issue to Ready status to be voted into the WP at Kona.
 
 
 <hr>
+<h3><a name="638"></a>638. deque end invalidation during erase</h3>
+<p><b>Section:</b> 23.2.2.3 [deque.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Steve LoBasso <b>Date:</b> 2007-02-17</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The standard states at 23.2.2.3 [deque.modifiers]/4:
+</p>
+<blockquote><pre>deque erase(...)
+</pre>
+ <p>
+<i>Effects:</i> ... An erase at either end of the deque invalidates only
+the iterators and the references to the erased elements.
+</p>
+</blockquote>
+<p>
+This does not state that iterators to end will be invalidated.
+It needs to be amended in such a way as to account for end invalidation.
+</p>
+<p>
+Something like:
+</p>
+<blockquote><p>
+Any time the last element is erased, iterators to end are invalidated.
+</p></blockquote>
+
+<p>
+This would handle situations like:
+</p>
+<blockquote><pre>erase(begin(), end())
+erase(end() - 1)
+pop_back()
+resize(n, ...) where n &lt; size()
+pop_front() with size() == 1
+
+</pre></blockquote>
+
+<p><i>[
+Post Kona, Steve LoBasso notes:
+]</i></p>
+
+
+<blockquote>
+My only issue with the proposed resolution is that it might not be clear
+that <tt>pop_front()</tt> [where <tt>size() == 1</tt>] can invalidate past-the-end
+iterators.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 23.2.2.3 [deque.modifiers], p4:
+</p>
+
+<blockquote>
+<pre>iterator erase(const_iterator position); 
+iterator erase(const_iterator first, const_iterator last);
+</pre>
+
+<blockquote>
+<p>
+-4- <i>Effects:</i> An erase in the middle of the <tt>deque</tt>
+invalidates all the iterators and references to elements of the
+<tt>deque</tt> <ins>and the past-the-end iterator</ins>. An erase at
+either end of the <tt>deque</tt> invalidates only the iterators and the
+references to the erased elements<ins>, except that erasing at the end
+also invalidates the past-the-end iterator</ins>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+<p><i>[
+Kona (2007): Proposed wording added and moved to Review.
+]</i></p>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Note that there is existing code that relies on iterators not being
+invalidated, but there are also existing implementations that do
+invalidate iterators. Thus, such code is not portable in any case. There
+is a pop_front() note, which should possibly be a separate issue. Mike
+Spertus to evaluate and, if need be, file an issue.
+</blockquote>
+
+
+
+
+<hr>
 <h3><a name="640"></a>640. 27.6.2.5.2 does not handle (unsigned) long long</h3>
 <p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-17</p>
@@ -24586,45 +25402,6 @@ A local variable <tt><i>punct</i></tt> is initialized via
 
 
 <hr>
-<h3><a name="644"></a>644. Possible typos in 'function' description</h3>
-<p><b>Section:</b> X [func.wrap.func.undef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-25</p>
-<p><b>Discussion:</b></p>
-<p>
-X [func.wrap.func.undef]
-</p>
-<p>
-The note in paragraph 2 refers to 'undefined void operators', while the 
-section declares a pair of operators returning bool.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.5.15.2 [func.wrap.func]
-</p>
-
-<blockquote><pre>...
-private:
-   // X [func.wrap.func.undef], undefined operators:
-   template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
-   template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
-};
-</pre></blockquote>
-
-<p>
-Change X [func.wrap.func.undef]
-</p>
-
-<blockquote><pre>template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
-template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
-</pre></blockquote>
-
-
-
-
-
-<hr>
 <h3><a name="646"></a>646. const incorrect match_result members</h3>
 <p><b>Section:</b> 28.10.4 [re.results.form] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p>
@@ -24985,12 +25762,12 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 <hr>
 <h3><a name="660"></a>660. Missing Bitwise Operations</h3>
-<p><b>Section:</b> 20.5 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-04-02</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>Section 20.5 [function.objects] provides <span id="st" name="st" class="st">function</span>
+<p>Section 20.6 [function.objects] provides <span id="st" name="st" class="st">function</span>
 <span id="st" name="st" class="st">objects</span> for some unary and binary 
 operations, but others are missing. In a LWG reflector discussion, beginning 
 with c++std-lib-18078, pros and cons of adding some of the missing operations 
@@ -25009,7 +25786,7 @@ resolution is limited to them.</p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>To 20.5 [function.objects], Function objects, paragraph 2, add to the header 
+<p>To 20.6 [function.objects], Function objects, paragraph 2, add to the header 
 &lt;functional&gt; synopsis:</p>
 <blockquote>
   <pre>template &lt;class T&gt; struct bit_and;
@@ -25284,96 +26061,159 @@ four characters long, usually three letters and a space.
 
 
 <hr>
-<h3><a name="674"></a>674. <tt>shared_ptr</tt> interface changes for consistency with N1856</h3>
-<p><b>Section:</b> 20.6.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-05</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>
+<h3><a name="672"></a>672. Swappable requirements need updating</h3>
+<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</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#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> does not propose
-any changes to <tt>shared_ptr</tt>. It needs to be updated to use a rvalue reference where appropriate
-and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>.
+The current <tt>Swappable</tt> is:
 </p>
 
-
-<p><b>Proposed resolution:</b></p>
-
+<blockquote>
+<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(s,t)</tt></td><td><tt>void</tt></td><td><tt>t</tt> has the value originally held by <tt>u</tt>, and <tt>u</tt> has the value originally 
+held by <tt>t</tt></td></tr>
+<tr><td colspan="3">
 <p>
-Change 20.6.12.2 [util.smartptr.shared] as follows:
+The Swappable requirement is met by satisfying one or more of the following conditions:
 </p>
-
-<blockquote>
-<pre>template&lt;class Y&gt; explicit shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
-<ins>template&lt;class Y, class D&gt; explicit shared_ptr(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
-template&lt;class Y, class D&gt; explicit shared_ptr(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins>
-...
-template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
-<ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
-template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
+<ul>
+<li>
+<tt>T</tt> is Swappable if <tt>T</tt> satisfies the <tt>CopyConstructible</tt> requirements (Table 34) 
+and the <tt>CopyAssignable</tt> requirements (Table 36);
+</li>
+<li>
+<tt>T</tt> is Swappable if a namespace scope function named <tt>swap</tt> exists in the same 
+namespace as the definition of <tt>T</tt>, such that the expression <tt>swap(t,u)</tt> is valid 
+and has the semantics described in this table.
+</li>
+</ul>
+</td></tr>
+</tbody></table>
 </blockquote>
 
 <p>
-Change 20.6.12.2.1 [util.smartptr.shared.const] as follows:
+With the passage of rvalue reference into the language, <tt>Swappable</tt> needs to be updated to
+require only <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.  This is a minimum.
 </p>
 
-<blockquote>
-<pre><ins>template&lt;class Y&gt; shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</ins></pre>
-</blockquote>
-
 <p>
-Add to 20.6.12.2.1 [util.smartptr.shared.const]:
+Additionally we may want to support proxy references such that the following code is acceptable:
 </p>
 
-<blockquote>
-<pre><ins>template&lt;class Y, class D&gt; shared_ptr(unique_ptr&lt;Y, D&gt;&amp;&amp; r);</ins></pre>
-<blockquote>
+<blockquote><pre>namespace Mine {
 
-<p><ins>
-<i>Effects:</i> Equivalent to <tt>shared_ptr( r.release(), r.get_deleter() )</tt> when <tt>D</tt> is
-          not a reference type, <tt>shared_ptr( r.release(), ref( r.get_deleter() ) )</tt>
-          otherwise.
-</ins></p>
+template &lt;class T&gt;
+struct proxy {...};
 
-<p><ins>
-<i>Exception safety:</i> If an exception is thrown, the constructor has no effect.
-</ins></p>
-</blockquote>
+template &lt;class T&gt;
+struct proxied_iterator
+{
+   typedef T value_type;
+   typedef proxy&lt;T&gt; reference;
+   reference operator*() const;
+   ...
+};
 
-</blockquote>
+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;);
+
+}  // Mine
+
+...
+
+Mine::proxied_iterator&lt;Mine::A&gt; i(...)
+Mine::A a;
+swap(*i1, a);
+</pre></blockquote>
 
 <p>
-Change 20.6.12.2.3 [util.smartptr.shared.assign] as follows:
+I.e. here is a call to <tt>swap</tt> which the user enables swapping between a proxy to a class and the class
+itself.  We do not need to anything in terms of implementation except not block their way with overly
+constrained concepts.  That is, the <tt>Swappable</tt> concept should be expanded to allow swapping
+between two different types for the case that one is binding to a user-defined <tt>swap</tt>.
 </p>
 
-<blockquote>
-<pre>template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</pre>
-</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
 
 <p>
-Add to 20.6.12.2.3 [util.smartptr.shared.assign]:
+Change 20.1.1 [utility.arg.requirements]:
 </p>
 
 <blockquote>
-<pre><ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
 
-<blockquote>
-<p><ins>
--4- <i>Effects:</i> Equivalent to <tt>shared_ptr(std::move(r)).swap(*this)</tt>.
-</ins></p>
-<p><ins>
--5- <i>Returns:</i> <tt>*this</tt>.
-</ins></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> is a type to be supplied by a C++ program
+instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
+values of type <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>; and <tt>rv</tt> is a non-<tt>const</tt>
+rvalue of type <tt>T</tt>.
+</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(s,t)</tt></td><td><tt>void</tt></td>
+<td><tt>t</tt> has the value originally
+held by <tt>u</tt>, and
+<tt>u</tt> has the value originally held
+by <tt>t</tt></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 <tt>T</tt> satisfies the
+<del><tt>CopyConstructible</tt></del> <ins>MoveConstructible</ins>
+requirements (Table <del>34</del> <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del> <ins>MoveAssignable</ins>
+requirements (Table <del>36</del> <ins>35</ins>);
+</li>
+<li>
+<tt>T</tt> is <tt>Swappable</tt> if a namespace scope function named
+<tt>swap</tt> exists in the same namespace as the definition of
+<tt>T</tt>, such that the expression
+<tt>swap(t,u)</tt> is valid and has the
+semantics described in this table.
+</li>
+</ul>
+</td></tr>
+</tbody></table>
 </blockquote>
 
 
 
 <p><i>[
-Kona (2007): We may need to open an issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>) to deal with the question of
-whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
+Kona (2007): We like the change to the <tt>Swappable</tt> requirements to use
+move semantics. The issue relating to the support of proxies is
+separable from the one relating to move semantics, and it's bigger than
+just swap. We'd like to address only the move semantics changes under
+this issue, and open a separated issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>) to handle proxies. Also, there
+may be a third issue, in that the current definition of <tt>Swappable</tt> does
+not permit rvalues to be operands to a swap operation, and Howard's
+proposed resolution would allow the right-most operand to be an rvalue,
+but it would not allow the left-most operand to be an rvalue (some swap
+functions in the library have been overloaded to permit left operands to
+swap to be rvalues).
 ]</i></p>
 
 
@@ -25381,295 +26221,340 @@ whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
 
 
 <hr>
-<h3><a name="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</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>
+<h3><a name="673"></a>673. <tt>unique_ptr</tt> update</h3>
+<p><b>Section:</b> 20.7.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr">issues</a> in [unique.ptr].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-<tt>seed_seq::randomize</tt> provides a mechanism for initializing random number
-engines which ideally would yield "distant" states when given "close"
-seeds.  The algorithm for <tt>seed_seq::randomize</tt> given in the current
-Working Draft for C++,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
-(2007-05-08), has 3 weaknesses
+Since the publication of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
+there have been a few small but significant advances which should be included into
+<tt>unique_ptr</tt>.  There exists a
+<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">example implmenation</a>
+for all of these changes.
 </p>
 
-<ol>
-<li>
-<p> Collisions in state.  Because of the way the state is initialized,
-    seeds of different lengths may result in the same state.  The
-    current version of seed_seq has the following properties:</p>
 <ul>
-<li>  For a given <tt>s &lt;= n</tt>, each of the 2^(32s) seed vectors results in a
-      distinct state.</li>
-</ul>
+
+<li>
 <p>
-    The proposed algorithm (below) has the considerably stronger
-    properties:</p>
-<ul>
-<li>   All of the <tt>(2^(32n)-1)/(2^32-1)</tt> seed vectors of lengths <tt>s &lt; n</tt>
-      result in distinct states.
-</li>
-<li>  All of the <tt>2^(32n)</tt> seed vectors of length <tt>s == n</tt> result in
-      distinct states.
-</li>
-</ul>
-</li>
-<li>
-<p> Poor mixing of <tt>v'</tt>s entropy into the state.  Consider <tt>v.size() == n</tt>
-    and hold <tt>v[n/2]</tt> thru <tt>v[n-1]</tt> fixed while varying <tt>v[0]</tt> thru <tt>v[n/2-1]</tt>,
-    a total of <tt>2^(16n)</tt> possibilities.  Because of the simple recursion
-    used in <tt>seed_seq</tt>, <tt>begin[n/2]</tt> thru <tt>begin[n-1]</tt> can take on only 2^64
-    possible states.</p>
-
-<p> The proposed algorithm uses a more complex recursion which results
-    in much better mixing.</p>
-</li>
-<li> <tt>seed_seq::randomize</tt> is undefined for <tt>v.size() == 0</tt>.  The proposed
-    algorithm remedies this.
-</li>
-</ol>
-<p>
-The current algorithm for <tt>seed_seq::randomize</tt> is adapted by me from the
-initialization procedure for the Mersenne Twister by Makoto Matsumoto
-and Takuji Nishimura.  The weakness (2) given above was communicated to
-me by Matsumoto last year.
-</p>
-<p>
-The proposed replacement for <tt>seed_seq::randomize</tt> is due to Mutsuo Saito,
-a student of Matsumoto, and is given in the implementation of the
-SIMD-oriented Fast Mersenne Twister random number generator SFMT.
-<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/index.html">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html</a>
-<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/SFMT-src-1.2.tar.gz">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz</a>
-</p>
-<p>
-See
-Mutsuo Saito,
-An Application of Finite Field: Design and Implementation of 128-bit
-Instruction-Based Fast Pseudorandom Number Generator,
-Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
-<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/M062821.pdf">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf</a>
+Even though <tt>unique_ptr&lt;void&gt;</tt> is not a valid use case (unlike for <tt>shared_ptr&lt;void&gt;</tt>),
+unexpected cases to crop up which require the instantiation of the interface of <tt>unique_ptr&lt;void&gt;</tt>
+even if it is never used.  For example see
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidently
+happened to <tt>auto_ptr</tt>.  I believe the most robust way to protect <tt>unique_ptr</tt> against this
+type of failure is to augment the return type of <tt>unique_ptr&lt;T&gt;:operator*()</tt> with
+<tt>add_lvalue_reference&lt;T&gt;::type</tt>.  This means that given an instantiated <tt>unique_ptr&lt;void&gt;</tt>
+the act of dereferencing it will simply return <tt>void</tt> instead of causing a compile time failure.
+This is simpler than creating a <tt>unique_ptr&lt;void&gt;</tt> specialization which isn't robust in the
+face of <tt><i>cv-</i></tt>qualified <tt>void</tt> types.
 </p>
+
 <p>
-One change has been made here, namely to treat the case of small <tt>n</tt>
-(setting <tt>t = (n-1)/2</tt> for <tt>n &lt; 7</tt>).
+This resolution also supports instantiations such as <tt>unique_ptr&lt;void, free_deleter&gt;</tt>
+which could be very useful to the client.
 </p>
+
+</li>
+
+<li>
 <p>
-Since <tt>seed_seq</tt> was introduced relatively recently there is little cost
-in making this incompatible improvement to it.
+Efforts have been made to better support containers and smart pointers in shared
+memory contexts.  One of the key hurdles in such support is not assuming that a
+pointer type is actually a <tt>T*</tt>.  This can easily be accomplished
+for <tt>unique_ptr</tt> by having the deleter define the pointer type:
+<tt>D::pointer</tt>.  Furthermore this type can easily be defaulted to
+<tt>T*</tt> should the deleter <tt>D</tt> choose not to define a pointer
+type (example implementation
+<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">here</a>).
+This change has no run time overhead.  It has no interface overhead on
+authors of custom delter types.  It simply allows (but not requires)
+authors of custom deleter types to define a smart pointer for the
+storage type of <tt>unique_ptr</tt> if they find such functionality
+useful.  <tt>std::default_delete</tt> is an example of a deleter which
+defaults <tt>pointer</tt> to <tt>T*</tt> by simply ignoring this issue
+and not including a <tt>pointer typedef</tt>.
 </p>
+</li>
 
+<li>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
+When the deleter type is a function pointer then it is unsafe to construct
+a <tt>unique_ptr</tt> without specifying the function pointer in the constructor.
+This case is easy to check for with a <tt>static_assert</tt> assuring that the
+deleter is not a pointer type in those constructors which do not accept deleters.
 </p>
 
+<blockquote><pre>unique_ptr&lt;A, void(*)(void*)&gt; p(new A);  // error, no function given to delete the pointer!
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
-</p>
+</li>
 
+</ul>
 
 <p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+Kona (2007): We don't like the solution given to the first bullet in
+light of concepts. The second bullet solves the problem of supporting
+fancy pointers for one library component only. The full LWG needs to
+decide whether to solve the problem of supporting fancy pointers
+piecemeal, or whether a paper addressing the whole library is needed. We
+think that the third bullet is correct.
 ]</i></p>
 
 
+<p><i>[
+Post Kona: Howard adds example user code related to the first bullet:
+]</i></p>
 
 
+<blockquote>
+<pre>void legacy_code(void*, std::size_t);
 
-<hr>
-<h3><a name="678"></a>678. Changes for [rand.req.eng]</h3>
-<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
-</p>
-
-<p>
-This change follows naturally from the proposed change to
-<tt>seed_seq::randomize</tt> in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>.
-</p>
+void foo(std::size_t N)
+{
+    std::unique_ptr&lt;void, void(*)(void*)&gt; ptr(std::malloc(N), std::free);
+    legacy_code(ptr.get(), N);
+}   // unique_ptr used for exception safety purposes
+</pre>
+</blockquote>
 
 <p>
-In table 104 the description of <tt>X(q)</tt> contains a special treatment of
-the case <tt>q.size() == 0</tt>.  This is undesirable for 4 reasons:
+I.e. <tt>unique_ptr&lt;void&gt;</tt> <i>is</i> a useful tool that we don't want
+to disable with concepts.  The only part of <tt>unique_ptr&lt;void&gt;</tt> we
+want to disable (with concepts or by other means) are the two member functions:
 </p>
 
-<ol>
-<li>It replicates the functionality provided by <tt>X()</tt>.</li>
-<li>It leads to the possibility of a collision in the state provided
-    by some other <tt>X(q)</tt> with <tt>q.size() &gt; 0</tt>.</li>
-<li>It is inconsistent with the description of the <tt>X(q)</tt> in
-paragraphs 26.4.3.1 [rand.eng.lcong] p5, 26.4.3.2 [rand.eng.mers] p8, and 26.4.3.3 [rand.eng.sub] p10 where
-there is no special treatment of <tt>q.size() == 0</tt>.</li>
-<li>The proposed replacement for <tt>seed_seq::randomize</tt> given above
-    allows for the case <tt>q.size() == 0</tt>.</li>
-</ol>
+<blockquote><pre>T&amp; operator*() const;
+T* operator-&gt;() const;
+</pre></blockquote>
 
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
-</p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
-</p>
-
 
 <p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review
+the proposed resolutions below.
 ]</i></p>
 
 
+<ul>
+<li>
 
-
-
-<hr>
-<h3><a name="679"></a>679. resize parameter by value</h3>
-<p><b>Section:</b> 23.2 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-The C++98 standard specifies that one member function alone of the containers
-passes its parameter (<tt>T</tt>) by value instead of by const reference:
+Change 20.7.11.2 [unique.ptr.single]:
 </p>
 
-<blockquote><pre>void resize(size_type sz, T c = T());
+<blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
+   ...
+   <del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
+   ...
+};
 </pre></blockquote>
 
 <p>
-This fact has been discussed / debated repeatedly over the years, the first time
-being even before C++98 was ratified.  The rationale for passing this parameter by
-value has been:
+Change 20.7.11.2.4 [unique.ptr.single.observers]:
 </p>
 
-<blockquote>
-<p>
-So that self referencing statements are guaranteed to work, for example:
-</p>
-<blockquote><pre>v.resize(v.size() + 1, v[0]);
+<blockquote><pre><del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
 </pre></blockquote>
-</blockquote>
 
+</li>
+
+<li>
 <p>
-However this rationale is not convincing as the signature for <tt>push_back</tt> is:
+Change 20.7.11.2 [unique.ptr.single]:
 </p>
 
-<blockquote><pre>void push_back(const T&amp; x);
+<blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
+public:
+  <ins>typedef <i>implementation (see description below)</i> pointer;</ins>
+   ...
+   explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
+   ...
+   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
+   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
+   ...
+   <del>T*</del> <ins>pointer</ins> operator-&gt;() const;
+   <del>T*</del> <ins>pointer</ins> get() const;
+   ...
+   <del>T*</del> <ins>pointer</ins> release();
+   void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
+};
 </pre></blockquote>
 
 <p>
-And <tt>push_back</tt> has similar semantics to <tt>resize</tt> (append).
-And <tt>push_back</tt> must also work in the self referencing case:
+<ins>
+-3- If the type <tt>remove_reference&lt;D&gt;::type::pointer</tt>
+exists, then <tt>unique_ptr&lt;T, D&gt;::pointer</tt> is a typedef to
+<tt>remove_reference&lt;D&gt;::type::pointer</tt>.  Otherwise
+<tt>unique_ptr&lt;T, D&gt;::pointer</tt> is a typedef to <tt>T*</tt>.
+The type <tt>unique_ptr&lt;T, D&gt;::pointer</tt> shall be <tt>CopyConstructible</tt>
+and <tt>CopyAssignable</tt>.
+</ins>
 </p>
 
-<blockquote><pre>v.push_back(v[0]);  // must work
+<p>
+Change 20.7.11.2.1 [unique.ptr.single.ctor]:
+</p>
+
+<blockquote><pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
+...
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); 
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); 
+...
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp; d);
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp;&amp; d);
+...
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp; d); 
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp;&amp; d);
+...
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp; d); 
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp;&amp; d);
+...
 </pre></blockquote>
 
 <p>
-The problem with passing <tt>T</tt> by value is that it can be significantly more
-expensive than passing by reference.  The converse is also true, however when it is
-true it is usually far less dramatic (e.g. for scalar types).
+-23- <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>
+<del>must</del> <ins>shall</ins> be well formed and not throw an exception. If <tt>D</tt> is a
+reference type, then <tt>E</tt> <del>must</del> <ins>shall</ins> be the same type as <tt>D</tt>
+(diagnostic required). <del><tt>U*</tt></del> <ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins>
+<del>must</del> <ins>shall</ins> be implicitly convertible to <del><tt>T*</tt></del>
+<ins>pointer</ins>.
 </p>
 
 <p>
-Even with move semantics available, passing this parameter by value can be expensive.
-Consider for example <tt>vector&lt;vector&lt;int&gt;&gt;</tt>:
+-25- <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before
+the construction, modulo any required offset adjustments resulting from
+the cast from <del><tt>U*</tt></del>
+<ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> to <del><tt>T*</tt></del>
+<ins>pointer</ins>. <tt>get_deleter()</tt> returns a reference to the
+internally stored deleter which was constructed from
+<tt>u.get_deleter()</tt>.
 </p>
 
-<blockquote><pre>std::vector&lt;int&gt; x(1000);
-std::vector&lt;std::vector&lt;int&gt;&gt; v;
-...
-v.resize(v.size()+1, x);
-</pre></blockquote>
-
 <p>
-In the pass-by-value case, <tt>x</tt> is copied once to the parameter of
-<tt>resize</tt>.  And then internally, since the code can not know at compile
-time by how much <tt>resize</tt> is growing the <tt>vector</tt>, <tt>x</tt> is
-usually copied (not moved) a second time from <tt>resize</tt>'s parameter into its proper place
-within the <tt>vector</tt>.
+Change 20.7.11.2.3 [unique.ptr.single.asgn]:
 </p>
 
+<blockquote>
 <p>
-With pass-by-const-reference, the <tt>x</tt> in the above example need be copied
-only once.  In this case, <tt>x</tt> has an expensive copy constructor and so any
-copies that can be saved represents a significant savings.
+-8- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
+<tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception. <del><tt>U*</tt></del>
+<ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> <del>must</del> <ins>shall</ins> be implicitly
+convertible to <del><tt>T*</tt></del> <ins>pointer</ins>.
 </p>
+</blockquote>
 
 <p>
-If we can be efficient for <tt>push_back</tt>, we should be efficient for <tt>resize</tt>
-as well.  The resize taking a reference parameter has been coded and shipped in the
-CodeWarrior library with no reports of problems which I am aware of.
+Change 20.7.11.2.4 [unique.ptr.single.observers]:
 </p>
 
+<blockquote>
+<pre><del>T*</del> <ins>pointer</ins> operator-&gt;() const;</pre>
+...
+<pre><del>T*</del> <ins>pointer</ins> get() const;</pre>
+</blockquote>
 
+<p>
+Change 20.7.11.2.5 [unique.ptr.single.modifiers]:
+</p>
+
+<blockquote>
+<pre><del>T*</del> <ins>pointer</ins> release();</pre>
+...
+<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);</pre>
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 23.2.2 [deque], p2:
+Change 20.7.11.3 [unique.ptr.runtime]:
 </p>
 
-<blockquote><pre>class deque {
+<blockquote><pre>template &lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt; {
+public:
+  <ins>typedef <i>implementation</i> pointer;</ins>
    ...
-   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
+   explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
+   ...
+   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
+   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
+   ...
+   <del>T*</del> <ins>pointer</ins> get() const;
+   ...
+   <del>T*</del> <ins>pointer</ins> release();
+   void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
+};
 </pre></blockquote>
 
 <p>
-Change 23.2.2.2 [deque.capacity], p3:
+Change 20.7.11.3.1 [unique.ptr.runtime.ctor]:
 </p>
 
-<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></blockquote>
+<blockquote>
+<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
+</pre>
 
 <p>
-Change 23.2.4 [list], p2:
+These constructors behave the same as in the primary template except
+that they do not accept pointer types which are convertible to
+<del><tt>T*</tt></del> <ins><tt>pointer</tt></ins>. [<i>Note:</i> One
+implementation technique is to create private templated overloads of
+these members. <i>-- end note</i>]
 </p>
-
-<blockquote><pre>class list {
-   ...
-   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></blockquote>
+</blockquote>
 
 <p>
-Change 23.2.4.2 [list.capacity], p3:
+Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]:
 </p>
 
-<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></blockquote>
+<blockquote>
+<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
+</pre>
 
 <p>
-Change 23.2.6 [vector], p2:
+-1- <i>Requires:</i> Does not accept pointer types which are convertible
+to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
+required). [<i>Note:</i> One implementation technique is to create a private
+templated overload. <i>-- end note</i>]
 </p>
+</blockquote>
 
-<blockquote><pre>class vector {
-   ...
-   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></blockquote>
+</li>
+
+<li>
 
 <p>
-Change 23.2.6.2 [vector.capacity], p11:
+Change 20.7.11.2.1 [unique.ptr.single.ctor]:
 </p>
 
-<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></blockquote>
+<blockquote>
+<pre>unique_ptr();</pre>
+<blockquote>
+<p>
+<i>Requires:</i> <tt>D</tt> <del>must</del> <ins>shall</ins> be default constructible, and that
+construction <del>must</del> <ins>shall</ins> not throw an exception. <tt>D</tt> <del>must</del> <ins>shall</ins> not be a
+reference type <ins>or pointer type (diagnostic required)</ins>.
+</p>
+</blockquote>
+<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
+<blockquote>
+<p>
+<i>Requires:</i>  The expression <tt>D()(p)</tt> <del>must</del> <ins>shall</ins> be well formed.
+The default constructor of <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception.
+<tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type <ins>or pointer type (diagnostic
+required)</ins>.
+</p>
+</blockquote>
+</blockquote>
+
+</li>
+
+</ul>
 
 
 
@@ -25677,110 +26562,200 @@ Change 23.2.6.2 [vector.capacity], p11:
 
 
 <hr>
-<h3><a name="680"></a>680. move_iterator operator-&gt; return</h3>
-<p><b>Section:</b> 24.4.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p>
+<h3><a name="674"></a>674. <tt>shared_ptr</tt> interface changes for consistency with N1856</h3>
+<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-05</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#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-<tt>move_iterator</tt>'s <tt>operator-&gt;</tt> return type <tt>pointer</tt>
-does not consistently match the type which is returned in the description
-in 24.4.3.3.5 [move.iter.op.ref].
-</p>
-
-<blockquote><pre>template &lt;class Iterator&gt;
-class move_iterator {
-public:
-    ...
-    typedef typename iterator_traits&lt;Iterator&gt;::pointer pointer;
-    ...
-    pointer operator-&gt;() const {return current;}
-    ...
-private: 
-    Iterator current; // exposition only
-};
-</pre></blockquote>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> does not propose
+any changes to <tt>shared_ptr</tt>. It needs to be updated to use a rvalue reference where appropriate
+and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>.
+</p>
 
 
+<p><b>Proposed resolution:</b></p>
+
 <p>
-There are two possible fixes.
+Change 20.7.12.2 [util.smartptr.shared] as follows:
 </p>
 
-<ol>
-<li><tt>pointer operator-&gt;() const {return &amp;*current;}</tt></li>
-<li><tt>typedef Iterator pointer;</tt></li>
-</ol>
+<blockquote>
+<pre>template&lt;class Y&gt; explicit shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
+<ins>template&lt;class Y, class D&gt; explicit shared_ptr(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
+template&lt;class Y, class D&gt; explicit shared_ptr(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins>
+...
+template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
+<ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
+template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
+</blockquote>
 
 <p>
-The first solution is the one chosen by <tt>reverse_iterator</tt>.  A potential
-disadvantage of this is it may not work well with iterators which return a
-proxy on dereference and that proxy has overloaded <tt>operator&amp;()</tt>.  Proxy
-references often need to overloaad <tt>operator&amp;()</tt> to return a proxy
-pointer.  That proxy pointer may or may not be the same type as the iterator's
-<tt>pointer</tt> type.
+Change 20.7.12.2.1 [util.smartptr.shared.const] as follows:
 </p>
 
+<blockquote>
+<pre><ins>template&lt;class Y&gt; shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</ins></pre>
+</blockquote>
+
 <p>
-By simply returning the <tt>Iterator</tt> and taking advantage of the fact that
-the language forwards calls to <tt>operator-&gt;</tt> automatically until it
-finds a non-class type, the second solution avoids the issue of an overloaded
-<tt>operator&amp;()</tt> entirely.
+Add to 20.7.12.2.1 [util.smartptr.shared.const]:
 </p>
 
-<p><b>Proposed resolution:</b></p>
+<blockquote>
+<pre><ins>template&lt;class Y, class D&gt; shared_ptr(unique_ptr&lt;Y, D&gt;&amp;&amp; r);</ins></pre>
+<blockquote>
+
+<p><ins>
+<i>Effects:</i> Equivalent to <tt>shared_ptr( r.release(), r.get_deleter() )</tt> when <tt>D</tt> is
+          not a reference type, <tt>shared_ptr( r.release(), ref( r.get_deleter() ) )</tt>
+          otherwise.
+</ins></p>
+
+<p><ins>
+<i>Exception safety:</i> If an exception is thrown, the constructor has no effect.
+</ins></p>
+</blockquote>
+
+</blockquote>
+
 <p>
-Change the synopsis in 24.4.3.1 [move.iterator]:
+Change 20.7.12.2.3 [util.smartptr.shared.assign] as follows:
 </p>
 
-<blockquote><pre>typedef <del>typename iterator_traits&lt;</del>Iterator<del>&gt;::pointer</del> pointer;
-</pre></blockquote>
+<blockquote>
+<pre>template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</pre>
+</blockquote>
+
+<p>
+Add to 20.7.12.2.3 [util.smartptr.shared.assign]:
+</p>
+
+<blockquote>
+<pre><ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
+
+<blockquote>
+<p><ins>
+-4- <i>Effects:</i> Equivalent to <tt>shared_ptr(std::move(r)).swap(*this)</tt>.
+</ins></p>
+<p><ins>
+-5- <i>Returns:</i> <tt>*this</tt>.
+</ins></p>
+</blockquote>
+
+</blockquote>
+
 
 
+<p><i>[
+Kona (2007): We may need to open an issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>) to deal with the question of
+whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
+]</i></p>
+
 
 
 
 
 <hr>
-<h3><a name="681"></a>681. Operator functions impossible to compare are defined in [re.submatch.op]</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#WP">WP</a>
- <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p>
+<h3><a name="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</h3>
+<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</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#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-In 28.9.2 [re.submatch.op] of N2284, 
-operator functions numbered 31-42 seem impossible to compare. &nbsp;E.g.: 
+<tt>seed_seq::randomize</tt> provides a mechanism for initializing random number
+engines which ideally would yield "distant" states when given "close"
+seeds.  The algorithm for <tt>seed_seq::randomize</tt> given in the current
+Working Draft for C++,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
+(2007-05-08), has 3 weaknesses
 </p>
 
-<blockquote>
-<pre>template &lt;class BiIter&gt;
-&nbsp; &nbsp; bool operator==(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; const sub_match&lt;BiIter&gt;&amp; rhs);
-</pre>
-<blockquote>
+<ol>
+<li>
+<p> Collisions in state.  Because of the way the state is initialized,
+    seeds of different lengths may result in the same state.  The
+    current version of seed_seq has the following properties:</p>
+<ul>
+<li>  For a given <tt>s &lt;= n</tt>, each of the 2^(32s) seed vectors results in a
+      distinct state.</li>
+</ul>
 <p>
--31- <i>Returns:</i> <tt>lhs == rhs.str()</tt>.
+    The proposed algorithm (below) has the considerably stronger
+    properties:</p>
+<ul>
+<li>   All of the <tt>(2^(32n)-1)/(2^32-1)</tt> seed vectors of lengths <tt>s &lt; n</tt>
+      result in distinct states.
+</li>
+<li>  All of the <tt>2^(32n)</tt> seed vectors of length <tt>s == n</tt> result in
+      distinct states.
+</li>
+</ul>
+</li>
+<li>
+<p> Poor mixing of <tt>v'</tt>s entropy into the state.  Consider <tt>v.size() == n</tt>
+    and hold <tt>v[n/2]</tt> thru <tt>v[n-1]</tt> fixed while varying <tt>v[0]</tt> thru <tt>v[n/2-1]</tt>,
+    a total of <tt>2^(16n)</tt> possibilities.  Because of the simple recursion
+    used in <tt>seed_seq</tt>, <tt>begin[n/2]</tt> thru <tt>begin[n-1]</tt> can take on only 2^64
+    possible states.</p>
+
+<p> The proposed algorithm uses a more complex recursion which results
+    in much better mixing.</p>
+</li>
+<li> <tt>seed_seq::randomize</tt> is undefined for <tt>v.size() == 0</tt>.  The proposed
+    algorithm remedies this.
+</li>
+</ol>
+<p>
+The current algorithm for <tt>seed_seq::randomize</tt> is adapted by me from the
+initialization procedure for the Mersenne Twister by Makoto Matsumoto
+and Takuji Nishimura.  The weakness (2) given above was communicated to
+me by Matsumoto last year.
+</p>
+<p>
+The proposed replacement for <tt>seed_seq::randomize</tt> is due to Mutsuo Saito,
+a student of Matsumoto, and is given in the implementation of the
+SIMD-oriented Fast Mersenne Twister random number generator SFMT.
+<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/index.html">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html</a>
+<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/SFMT-src-1.2.tar.gz">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz</a>
+</p>
+<p>
+See
+Mutsuo Saito,
+An Application of Finite Field: Design and Implementation of 128-bit
+Instruction-Based Fast Pseudorandom Number Generator,
+Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
+<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/M062821.pdf">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf</a>
+</p>
+<p>
+One change has been made here, namely to treat the case of small <tt>n</tt>
+(setting <tt>t = (n-1)/2</tt> for <tt>n &lt; 7</tt>).
+</p>
+<p>
+Since <tt>seed_seq</tt> was introduced relatively recently there is little cost
+in making this incompatible improvement to it.
 </p>
-</blockquote>
-</blockquote>
 
 <p>
-When <tt>char*</tt> is used as <tt>BiIter</tt>, <tt>iterator_traits&lt;BiIter&gt;::value_type</tt> would be 
-<tt>char</tt>, so that <tt>lhs == rhs.str()</tt> ends up comparing a <tt>char</tt> value and an object 
-of <tt>std::basic_string&lt;char&gt;</tt>. &nbsp;However, the behaviour of comparison between 
-these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
-&nbsp;This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>. 
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
 Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
 </p>
 
 
 <p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
 ]</i></p>
 
@@ -25789,59 +26764,53 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 <hr>
-<h3><a name="682"></a>682. basic_regex ctor takes InputIterator or ForwardIterator?</h3>
-<p><b>Section:</b> 28.8.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-03</p>
+<h3><a name="678"></a>678. Changes for [rand.req.eng]</h3>
+<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Looking at N2284, 28.8 [re.regex], p3 <tt>basic_regex</tt> class template synopsis shows this 
-constructor: 
+Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
 </p>
-<blockquote><pre>template &lt;class InputIterator&gt;
-&nbsp; &nbsp; &nbsp;basic_regex(InputIterator first, InputIterator last, 
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;flag_type f = regex_constants::ECMAScript);
-</pre></blockquote>
 
 <p>
-In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature: 
+This change follows naturally from the proposed change to
+<tt>seed_seq::randomize</tt> in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>.
 </p>
 
-<blockquote><pre>template &lt;class ForwardIterator&gt;
-&nbsp; &nbsp; &nbsp;basic_regex(ForwardIterator first, ForwardIterator last, 
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;flag_type f = regex_constants::ECMAScript);
-</pre></blockquote>
-
 <p>
-<tt>ForwardIterator</tt> is probably correct, so the synopsis is wrong.
+In table 104 the description of <tt>X(q)</tt> contains a special treatment of
+the case <tt>q.size() == 0</tt>.  This is undesirable for 4 reasons:
 </p>
 
-<p><i>[
-John adds:
-]</i></p>
-
+<ol>
+<li>It replicates the functionality provided by <tt>X()</tt>.</li>
+<li>It leads to the possibility of a collision in the state provided
+    by some other <tt>X(q)</tt> with <tt>q.size() &gt; 0</tt>.</li>
+<li>It is inconsistent with the description of the <tt>X(q)</tt> in
+paragraphs 26.4.3.1 [rand.eng.lcong] p5, 26.4.3.2 [rand.eng.mers] p8, and 26.4.3.3 [rand.eng.sub] p10 where
+there is no special treatment of <tt>q.size() == 0</tt>.</li>
+<li>The proposed replacement for <tt>seed_seq::randomize</tt> given above
+    allows for the case <tt>q.size() == 0</tt>.</li>
+</ol>
 
-<blockquote>
-<p>
-I think either could be implemented? &nbsp;Although an input iterator would 
-probably require an internal copy of the string being made.
-</p>
 <p>
-I have no strong feelings either way, although I think my original intent 
-was <tt>InputIterator</tt>. 
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
 </p>
-</blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
 Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
 </p>
 
 
 <p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
 ]</i></p>
 
@@ -25850,419 +26819,2719 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 <hr>
-<h3><a name="687"></a>687. shared_ptr conversion constructor not constrained</h3>
-<p><b>Section:</b> 20.6.12.2.1 [util.smartptr.shared.const], 20.6.12.3.1 [util.smartptr.weak.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</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>
+<h3><a name="679"></a>679. resize parameter by value</h3>
+<p><b>Section:</b> 23.2 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Since all conversions from <tt>shared_ptr&lt;T&gt;</tt> to <tt>shared_ptr&lt;U&gt;</tt> have the same
-rank regardless of the relationship between <tt>T</tt> and <tt>U</tt>, reasonable user
-code that works with raw pointers fails with <tt>shared_ptr</tt>:
+The C++98 standard specifies that one member function alone of the containers
+passes its parameter (<tt>T</tt>) by value instead of by const reference:
 </p>
 
-<blockquote><pre>void f( shared_ptr&lt;void&gt; );
-void f( shared_ptr&lt;int&gt; );
+<blockquote><pre>void resize(size_type sz, T c = T());
+</pre></blockquote>
 
-int main()
-{
-&nbsp;&nbsp;f( shared_ptr&lt;double&gt;() ); // ambiguous
-}
+<p>
+This fact has been discussed / debated repeatedly over the years, the first time
+being even before C++98 was ratified.  The rationale for passing this parameter by
+value has been:
+</p>
+
+<blockquote>
+<p>
+So that self referencing statements are guaranteed to work, for example:
+</p>
+<blockquote><pre>v.resize(v.size() + 1, v[0]);
 </pre></blockquote>
+</blockquote>
 
 <p>
-Now that we officially have <tt>enable_if</tt>, we can constrain the constructor
-and the corresponding assignment operator to only participate in the
-overload resolution when the pointer types are compatible.
+However this rationale is not convincing as the signature for <tt>push_back</tt> is:
+</p>
+
+<blockquote><pre>void push_back(const T&amp; x);
+</pre></blockquote>
+
+<p>
+And <tt>push_back</tt> has similar semantics to <tt>resize</tt> (append).
+And <tt>push_back</tt> must also work in the self referencing case:
+</p>
+
+<blockquote><pre>v.push_back(v[0]);  // must work
+</pre></blockquote>
+
+<p>
+The problem with passing <tt>T</tt> by value is that it can be significantly more
+expensive than passing by reference.  The converse is also true, however when it is
+true it is usually far less dramatic (e.g. for scalar types).
+</p>
+
+<p>
+Even with move semantics available, passing this parameter by value can be expensive.
+Consider for example <tt>vector&lt;vector&lt;int&gt;&gt;</tt>:
+</p>
+
+<blockquote><pre>std::vector&lt;int&gt; x(1000);
+std::vector&lt;std::vector&lt;int&gt;&gt; v;
+...
+v.resize(v.size()+1, x);
+</pre></blockquote>
+
+<p>
+In the pass-by-value case, <tt>x</tt> is copied once to the parameter of
+<tt>resize</tt>.  And then internally, since the code can not know at compile
+time by how much <tt>resize</tt> is growing the <tt>vector</tt>, <tt>x</tt> is
+usually copied (not moved) a second time from <tt>resize</tt>'s parameter into its proper place
+within the <tt>vector</tt>.
+</p>
+
+<p>
+With pass-by-const-reference, the <tt>x</tt> in the above example need be copied
+only once.  In this case, <tt>x</tt> has an expensive copy constructor and so any
+copies that can be saved represents a significant savings.
+</p>
+
+<p>
+If we can be efficient for <tt>push_back</tt>, we should be efficient for <tt>resize</tt>
+as well.  The resize taking a reference parameter has been coded and shipped in the
+CodeWarrior library with no reports of problems which I am aware of.
 </p>
 
 
+
 <p><b>Proposed resolution:</b></p>
 <p>
-In 20.6.12.2.1 [util.smartptr.shared.const], change:
+Change 23.2.2 [deque], p2:
 </p>
 
-<blockquote><p>
--14- <i>Requires:</i> <del>For the second constructor</del> <ins>The
-second constructor shall not participate in the overload resolution
-unless</ins> <tt>Y*</tt> <del>shall be</del> <ins>is implicitly</ins> convertible
-to <tt>T*</tt>.
-</p></blockquote>
+<blockquote><pre>class deque {
+   ...
+   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
+</pre></blockquote>
+
+<p>
+Change 23.2.2.2 [deque.capacity], p3:
+</p>
+
+<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
+</pre></blockquote>
+
+<p>
+Change 23.2.4 [list], p2:
+</p>
+
+<blockquote><pre>class list {
+   ...
+   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
+</pre></blockquote>
+
+<p>
+Change 23.2.4.2 [list.capacity], p3:
+</p>
+
+<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
+</pre></blockquote>
+
+<p>
+Change 23.2.6 [vector], p2:
+</p>
+
+<blockquote><pre>class vector {
+   ...
+   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
+</pre></blockquote>
+
+<p>
+Change 23.2.6.2 [vector.capacity], p11:
+</p>
+
+<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
+</pre></blockquote>
+
+
+
+
+
 
+<hr>
+<h3><a name="680"></a>680. move_iterator operator-&gt; return</h3>
+<p><b>Section:</b> 24.4.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>move_iterator</tt>'s <tt>operator-&gt;</tt> return type <tt>pointer</tt>
+does not consistently match the type which is returned in the description
+in 24.4.3.3.5 [move.iter.op.ref].
+</p>
+
+<blockquote><pre>template &lt;class Iterator&gt;
+class move_iterator {
+public:
+    ...
+    typedef typename iterator_traits&lt;Iterator&gt;::pointer pointer;
+    ...
+    pointer operator-&gt;() const {return current;}
+    ...
+private: 
+    Iterator current; // exposition only
+};
+</pre></blockquote>
+
+
+<p>
+There are two possible fixes.
+</p>
+
+<ol>
+<li><tt>pointer operator-&gt;() const {return &amp;*current;}</tt></li>
+<li><tt>typedef Iterator pointer;</tt></li>
+</ol>
+
+<p>
+The first solution is the one chosen by <tt>reverse_iterator</tt>.  A potential
+disadvantage of this is it may not work well with iterators which return a
+proxy on dereference and that proxy has overloaded <tt>operator&amp;()</tt>.  Proxy
+references often need to overloaad <tt>operator&amp;()</tt> to return a proxy
+pointer.  That proxy pointer may or may not be the same type as the iterator's
+<tt>pointer</tt> type.
+</p>
+
+<p>
+By simply returning the <tt>Iterator</tt> and taking advantage of the fact that
+the language forwards calls to <tt>operator-&gt;</tt> automatically until it
+finds a non-class type, the second solution avoids the issue of an overloaded
+<tt>operator&amp;()</tt> entirely.
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 24.4.3.1 [move.iterator]:
+</p>
+
+<blockquote><pre>typedef <del>typename iterator_traits&lt;</del>Iterator<del>&gt;::pointer</del> pointer;
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="681"></a>681. Operator functions impossible to compare are defined in [re.submatch.op]</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#WP">WP</a>
+ <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-In 20.6.12.3.1 [util.smartptr.weak.const], change:
+In 28.9.2 [re.submatch.op] of N2284, 
+operator functions numbered 31-42 seem impossible to compare. &nbsp;E.g.: 
 </p>
 
 <blockquote>
-<pre><del>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</del>
-<del>weak_ptr(weak_ptr const&amp; r);</del>
-<del>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</del>
-<ins>weak_ptr(weak_ptr const&amp; r);</ins>
-<ins>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</ins>
-<ins>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</ins>
+<pre>template &lt;class BiIter&gt;
+&nbsp; &nbsp; bool operator==(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; const sub_match&lt;BiIter&gt;&amp; rhs);
 </pre>
-<blockquote><p>
--4- <i>Requires:</i> <del>For</del> <del>t</del><ins>T</ins>he second and
-third constructors<del>,</del> <ins>shall not participate in the
-overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del>
-<ins>is implicitly</ins> convertible to <tt>T*</tt>.
-</p></blockquote>
+<blockquote>
+<p>
+-31- <i>Returns:</i> <tt>lhs == rhs.str()</tt>.
+</p>
+</blockquote>
 </blockquote>
 
+<p>
+When <tt>char*</tt> is used as <tt>BiIter</tt>, <tt>iterator_traits&lt;BiIter&gt;::value_type</tt> would be 
+<tt>char</tt>, so that <tt>lhs == rhs.str()</tt> ends up comparing a <tt>char</tt> value and an object 
+of <tt>std::basic_string&lt;char&gt;</tt>. &nbsp;However, the behaviour of comparison between 
+these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
+&nbsp;This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>. 
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
 
 
 
+<hr>
+<h3><a name="682"></a>682. basic_regex ctor takes InputIterator or ForwardIterator?</h3>
+<p><b>Section:</b> 28.8.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-03</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Looking at N2284, 28.8 [re.regex], p3 <tt>basic_regex</tt> class template synopsis shows this 
+constructor: 
+</p>
+<blockquote><pre>template &lt;class InputIterator&gt;
+&nbsp; &nbsp; &nbsp;basic_regex(InputIterator first, InputIterator last, 
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;flag_type f = regex_constants::ECMAScript);
+</pre></blockquote>
+
+<p>
+In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature: 
+</p>
+
+<blockquote><pre>template &lt;class ForwardIterator&gt;
+&nbsp; &nbsp; &nbsp;basic_regex(ForwardIterator first, ForwardIterator last, 
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;flag_type f = regex_constants::ECMAScript);
+</pre></blockquote>
+
+<p>
+<tt>ForwardIterator</tt> is probably correct, so the synopsis is wrong.
+</p>
+
+<p><i>[
+John adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+I think either could be implemented? &nbsp;Although an input iterator would 
+probably require an internal copy of the string being made.
+</p>
+<p>
+I have no strong feelings either way, although I think my original intent 
+was <tt>InputIterator</tt>. 
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="685"></a>685. reverse_iterator/move_iterator difference has invalid signatures</h3>
+<p><b>Section:</b> 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-06-10</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In C++03 the difference between two <tt>reverse_iterators</tt>
+</p>
+<blockquote><pre>ri1 - ri2
+</pre></blockquote>
+<p>
+is possible to compute only if both iterators have the same base 
+iterator. The result type is the <tt>difference_type</tt> of the base iterator. 
+</p>
+<p>
+In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff] 
+</p>
+<blockquote><pre>template&lt;class Iterator1, class Iterator2&gt; 
+typename reverse_iterator&lt;Iterator&gt;::difference_type 
+   operator-(const reverse_iterator&lt;Iterator1&gt;&amp; x, 
+                    const reverse_iterator&lt;Iterator2&gt;&amp; y);
+</pre></blockquote>
+<p>
+The return type is the same as the C++03 one, based on the no longer 
+present <tt>Iterator</tt> template parameter. 
+</p>
+<p>
+Besides being slightly invalid, should this operator work only when 
+<tt>Iterator1</tt> and <tt>Iterator2</tt> has the same <tt>difference_type</tt>? Or should the 
+implementation choose one of them? Which one? 
+</p>
+<p>
+The same problem now also appears in <tt>operator-()</tt> for <tt>move_iterator</tt>
+24.4.3.3.14 [move.iter.nonmember]. 
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 24.4.1.1 [reverse.iterator]:
+</p>
+
+<blockquote>
+<pre>template &lt;class Iterator1, class Iterator2&gt; 
+  <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
+    const reverse_iterator&lt;Iterator1&gt;&amp; x, 
+    const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(y.current - x.current)</ins>;
+</pre>
+</blockquote>
+
+<p>
+Change 24.4.1.3.19 [reverse.iter.opdiff]:
+</p>
+
+<blockquote>
+<pre>template &lt;class Iterator1, class Iterator2&gt; 
+  <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
+    const reverse_iterator&lt;Iterator1&gt;&amp; x, 
+    const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(y.current - x.current)</ins>;
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>y.current - x.current</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+<p>
+Change the synopsis in 24.4.3.1 [move.iterator]:
+</p>
+
+<blockquote>
+<pre>template &lt;class Iterator1, class Iterator2&gt; 
+  <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
+    const move_iterator&lt;Iterator1&gt;&amp; x, 
+    const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(x.base() - y.base())</ins>;
+</pre>
+</blockquote>
+
+<p>
+Change 24.4.3.3.14 [move.iter.nonmember]:
+</p>
+
+<blockquote>
+<pre>template &lt;class Iterator1, class Iterator2&gt; 
+  <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
+    const move_iterator&lt;Iterator1&gt;&amp; x, 
+    const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(x.base() - y.base())</ins>;
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>x.base() - y.base()</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+<p><i>[
+Pre Bellevue:  This issue needs to wait until the <tt>auto -&gt; return</tt> language feature
+goes in.
+]</i></p>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="687"></a>687. shared_ptr conversion constructor not constrained</h3>
+<p><b>Section:</b> 20.7.12.2.1 [util.smartptr.shared.const], 20.7.12.3.1 [util.smartptr.weak.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Since all conversions from <tt>shared_ptr&lt;T&gt;</tt> to <tt>shared_ptr&lt;U&gt;</tt> have the same
+rank regardless of the relationship between <tt>T</tt> and <tt>U</tt>, reasonable user
+code that works with raw pointers fails with <tt>shared_ptr</tt>:
+</p>
+
+<blockquote><pre>void f( shared_ptr&lt;void&gt; );
+void f( shared_ptr&lt;int&gt; );
+
+int main()
+{
+&nbsp;&nbsp;f( shared_ptr&lt;double&gt;() ); // ambiguous
+}
+</pre></blockquote>
+
+<p>
+Now that we officially have <tt>enable_if</tt>, we can constrain the constructor
+and the corresponding assignment operator to only participate in the
+overload resolution when the pointer types are compatible.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.7.12.2.1 [util.smartptr.shared.const], change:
+</p>
+
+<blockquote><p>
+-14- <i>Requires:</i> <del>For the second constructor</del> <ins>The
+second constructor shall not participate in the overload resolution
+unless</ins> <tt>Y*</tt> <del>shall be</del> <ins>is implicitly</ins> convertible
+to <tt>T*</tt>.
+</p></blockquote>
+
+<p>
+In 20.7.12.3.1 [util.smartptr.weak.const], change:
+</p>
+
+<blockquote>
+<pre><del>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</del>
+<del>weak_ptr(weak_ptr const&amp; r);</del>
+<del>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</del>
+<ins>weak_ptr(weak_ptr const&amp; r);</ins>
+<ins>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</ins>
+<ins>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</ins>
+</pre>
+<blockquote><p>
+-4- <i>Requires:</i> <del>For</del> <del>t</del><ins>T</ins>he second and
+third constructors<del>,</del> <ins>shall not participate in the
+overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del>
+<ins>is implicitly</ins> convertible to <tt>T*</tt>.
+</p></blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="689"></a>689. reference_wrapper constructor overly constrained</h3>
+<p><b>Section:</b> 20.6.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary
+motivation behind this is the safety problem with respect to rvalues,
+which is addressed by the proposed resolution of the previous issue.
+Therefore we should consider relaxing the requirements on the
+constructor since requests for the implicit conversion keep resurfacing.
+</p>
+<p>
+Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Remove the <tt>explicit</tt> from the constructor of <tt>reference_wrapper</tt>. If the
+proposed resolution of the previous issue is accepted, remove the
+<tt>explicit</tt> from the <tt>T&amp;&amp;</tt> constructor as well to keep them in sync.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="693"></a>693. <code>std::bitset::all()</code> missing</h3>
+<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The  <code>bitset</code> class template  provides the  member function
+<code>any()</code> to determine whether an  object of the type has any
+bits  set, and  the member  function <code>none()</code>  to determine
+whether all of an object's  bits are clear. However, the template does
+not   provide  a   corresponding  function   to  discover   whether  a
+<code>bitset</code>  object  has  all  its  bits  set.   While  it  is
+possible,  even easy,  to  obtain this  information  by comparing  the
+result of <code>count()</code>  with the result of <code>size()</code>
+for  equality  (i.e.,  via  <code>b.count()  ==  b.size()</code>)  the
+operation  is   less  efficient   than  a  member   function  designed
+specifically  for that purpose  could be.   (<code>count()</code> must
+count  all non-zero bits  in a  <code>bitset</code> a  word at  a time
+while <code>all()</code> could stop counting as soon as it encountered
+the first word with a zero bit).
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add  a declaration of the new  member function <code>all()</code> to the
+defintion of the <code>bitset</code> template in 23.3.5 [template.bitset], p1,
+right above the declaration of <code>any()</code> as shown below:
+</p>
+
+<blockquote><pre>bool operator!=(const bitset&lt;N&gt;&amp; rhs) const;
+bool test(size_t pos) const;
+<ins>bool all() const;</ins>
+bool any() const;
+bool none() const;
+</pre></blockquote>
+
+<p>
+Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text:
+</p>
+<blockquote><p>
+<code>bool all() const;</code>
+</p>
+<blockquote>
+<i>Returns</i>: <code>count() == size()</code>.
+</blockquote>
+</blockquote>
+
+<p>
+In  addition,   change  the  description   of  <code>any()</code>  and
+<code>none()</code>   for  consistency   with   <code>all()</code>  as
+follows:
+</p>
+<blockquote><p>
+<code>bool any() const;</code>
+</p>
+<blockquote>
+<p>
+<i>Returns</i>: <del><code>true</code> if any bit in <code>*this</code>
+is one</del><ins><code>count() != 0</code></ins>.
+</p>
+</blockquote>
+<p>
+<code>bool none() const;</code>
+</p>
+<blockquote>
+<p>
+<i>Returns</i>: <del><code>true</code> if no bit in <code>*this</code>
+is one</del><ins><code>count() == 0</code></ins>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="694"></a>694. <code>std::bitset</code> and <code>long long</code></h3>
+<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Objects of the  <code>bitset</code> class template specializations can
+be constructed from  and explicitly converted to values  of the widest
+C++ integer  type, <code>unsigned long</code>.   With the introduction
+of  <code>long long</code> into  the language  the template  should be
+enhanced to make it possible  to interoperate with values of this type
+as well, or  perhaps <code>uintmax_t</code>.  See c++std-lib-18274 for
+a brief discussion in support of this change.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+For simplicity,  instead of  adding overloads for  <code>unsigned long
+long</code> and dealing with possible ambiguities in the spec, replace
+the <code>bitset</code> ctor  that takes an <code>unsigned long</code>
+argument  with  one  taking  <code>unsigned long  long</code>  in  the
+definition  of the  template as  shown below.   (The  standard permits
+implementations  to add  overloads on  other integer  types  or employ
+template tricks to  achieve the same effect provided  they don't cause
+ambiguities or changes in behavior.)
+</p>
+<blockquote>
+<pre>// [bitset.cons] constructors:
+bitset();
+bitset(unsigned <ins>long</ins> long val);
+template&lt;class charT, class traits, class Allocator&gt;
+explicit bitset(
+                const basic_string&lt;charT,traits,Allocator&gt;&amp; str,
+                typename basic_string&lt;charT,traits,Allocator&gt;::size_type pos = 0,
+                typename basic_string&lt;charT,traits,Allocator&gt;::size_type n =
+                    basic_string&lt;charT,traits,Allocator&gt;::npos);
+</pre>
+</blockquote>
+<p>
+Make a corresponding change in 23.3.5.1 [bitset.cons], p2:
+</p>
+<blockquote>
+<p>
+<code>bitset(unsigned <ins>long</ins> long val);</code>
+</p>
+<blockquote>
+<i>Effects</i>:  Constructs   an  object  of   class  bitset&lt;N&gt;,
+initializing  the  first <code><i>M</i></code>  bit  positions to  the
+corresponding      bit     values      in     <code><i>val</i></code>.
+<code><i>M</i></code> is the  smaller of <code><i>N</i></code> and the
+number of bits in  the value representation (section [basic.types]) of
+<code>unsigned  <ins> long</ins> long</code>.   If  <code><i>M</i> &lt;
+<i>N</i></code>  <ins>is  <code>true</code></ins>,  the remaining  bit
+positions are initialized to zero.
+</blockquote>
+</blockquote>
+
+<p>
+Additionally, introduce a new member function <code>to_ullong()</code>
+to make  it possible to  convert <code>bitset</code> to values  of the
+new  type. Add  the following  declaration  to the  definition of  the
+template, immediate  after the declaration  of <code>to_ulong()</code>
+in 23.3.5 [template.bitset], p1, as shown below:
+</p>
+<blockquote>
+<pre>// element access:
+bool operator[](size_t pos) const; // for b[i];
+reference operator[](size_t pos); // for b[i];
+unsigned long to_ulong() const;
+<ins>unsigned long long to_ullong() const;</ins>
+template &lt;class charT, class traits, class Allocator&gt;
+basic_string&lt;charT, traits, Allocator&gt; to_string() const;
+</pre>
+</blockquote>
+<p>
+And add a description of  the new member function to 23.3.5.2 [bitset.members],
+below  the  description of  the  existing <code>to_ulong()</code>  (if
+possible), with the following text:
+</p>
+<blockquote>
+<p>
+<code>unsigned long long to_ullong() const;</code>
+</p>
+<blockquote>
+<i>Throws</i>:  <code>overflow_error</code>   if  the  integral  value
+<code><i>x</i></code> corresponding to  the bits in <code>*this</code>
+cannot be represented as type <code>unsigned long long</code>.
+</blockquote>
+<blockquote>
+<i>Returns:</i> <code><i>x</i></code>.
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="695"></a>695. ctype&lt;char&gt;::classic_table() not accessible</h3>
+<p><b>Section:</b> 22.2.1.3 [facet.ctype.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The   <code>ctype&lt;char&gt;::classic_table()</code>   static  member
+function    returns    a    pointer    to   an    array    of    const
+<code>ctype_base::mask</code>    objects    (enums)   that    contains
+<code>ctype&lt;char&gt;::table_size</code>    elements.    The   table
+describes the properties of the character set in the "C" locale (i.e.,
+whether a  character at an index  given by its value  is alpha, digit,
+punct,   etc.),   and   is    typically   used   to   initialize   the
+<code>ctype&lt;char&gt;</code>  facet in the  classic "C"  locale (the
+protected      <code>ctype&lt;char&gt;</code>      member     function
+<code>table()</code>    then    returns     the    same    value    as
+<code>classic_table()</code>).
+</p>
+<p>
+However, while <code>ctype&lt;char&gt;::table_size</code> (the size of
+the   table)    is   a   public    static   const   member    of   the
+<code>ctype&lt;char&gt;</code>           specialization,           the
+<code>classic_table()</code> static member function is protected. That
+makes getting at the classic  data less than convenient (i.e., one has
+to create  a whole derived class just  to get at the  masks array). It
+makes  little sense  to expose  the size  of the  table in  the public
+interface while making the table itself protected, especially when the
+table is a constant object.
+</p>
+<p>
+The  same argument  can be  made for  the non-static  protected member
+function <code>table()</code>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Make     the    <code>ctype&lt;char&gt;::classic_table()</code>    and
+<code>ctype&lt;char&gt;::table()</code>  member  functions  public  by
+moving their declarations into the public section of the definition of
+specialization in 22.2.1.3 [facet.ctype.special] as shown below:
+</p>
+<blockquote>
+<pre>  static locale::id id;
+  static const size_t table_size = IMPLEMENTATION_DEFINED;
+<del>protected:</del>
+  const mask* table() const throw();
+  static const mask* classic_table() throw();
+<ins>protected:</ins>
+
+~ctype(); // virtual
+virtual char do_toupper(char c) const;
+</pre>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="699"></a>699. N2111 changes min/max</h3>
+<p><b>Section:</b> 26.4 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
+changes <tt>min/max</tt> in several places in random from member
+functions to static data members. I believe this introduces
+a needless backward compatibility problem between C++0X and
+TR1. I'd like us to find new names for the static data members,
+or perhaps change <tt>min/max</tt> to <tt>constexpr</tt>s in C++0X.
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="700"></a>700. N1856 defines struct <tt>identity</tt></h3>
+<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</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>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
+defines struct <tt>identity</tt> in <tt>&lt;utility&gt;</tt> which clashes with
+the traditional definition of struct <tt>identity</tt> in <tt>&lt;functional&gt;</tt>
+(not standard, but a common extension from old STL). Be nice
+if we could avoid this name clash for backward compatibility.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.2.2 [forward]:
+</p>
+
+<blockquote>
+<pre>template &lt;class T&gt; struct identity
+{
+    typedef T type;
+    <ins>const T&amp; operator()(const T&amp; x) const;</ins>
+};
+</pre>
+<blockquote>
+<pre><ins>const T&amp; operator()(const T&amp; x) const;</ins>
+</pre>
+<blockquote>
+<p>
+<ins><i>Returns:</i> <tt>x</tt>.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="703"></a>703. <tt>map::at()</tt> need a complexity specification</h3>
+<p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-07-03</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>map::at()</tt> need a complexity specification.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following to the specification of <tt>map::at()</tt>, 23.3.1.2 [map.access]:
+</p>
+<blockquote>
+<p>
+<i>Complexity:</i> logarithmic.
+</p>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="705"></a>705. type-trait <tt>decay</tt> incompletely specified</h3>
+<p><b>Section:</b> 20.5.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The current working draft has a type-trait <tt>decay</tt> in 20.5.7 [meta.trans.other].
+</p>
+
+<p>
+Its use is to turn C++03 pass-by-value parameters into efficient C++0x
+pass-by-rvalue-reference parameters. However, the current definition
+introduces an incompatible change where the cv-qualification of the
+parameter type is retained. The deduced type should loose such
+cv-qualification, as pass-by-value does.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.5.7 [meta.trans.other] change the last sentence:
+</p>
+
+<blockquote><p>
+Otherwise the  member typedef <tt>type</tt> equals <tt><ins>remove_cv&lt;</ins>U<ins>&gt;::type</ins></tt>.
+</p></blockquote>
+
+<p>
+In 20.4.1.3 [tuple.creation]/1 change:
+</p>
+
+<blockquote><p>
+<del>where each <tt>Vi</tt> in <tt>VTypes</tt> is <tt>X&amp;</tt> if, for the
+corresponding type <tt>Ti</tt> in <tt>Types</tt>,
+<tt>remove_cv&lt;remove_reference&lt;Ti&gt;::type&gt;::type</tt> equals
+<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
+<tt>decay&lt;Ti&gt;::type</tt>.</del>
+<ins>Let <tt>Ui</tt> be <tt>decay&lt;Ti&gt;::type</tt> for each
+<tt>Ti</tt> in <tt>Types</tt>. Then each <tt>Vi</tt> in <tt>VTypes</tt>
+is <tt>X&amp;</tt> if <tt>Ui</tt> equals
+<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
+<tt>Ui</tt>.</ins>
+</p></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="706"></a>706. <tt>make_pair()</tt> should behave as <tt>make_tuple()</tt> wrt. <tt>reference_wrapper()</tt></h3>
+<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The current draft has <tt>make_pair()</tt> in 20.2.3 [pairs]/16
+and <tt>make_tuple()</tt> in 20.4.1.3 [tuple.creation].
+<tt>make_tuple()</tt> detects the presence of
+<tt>reference_wrapper&lt;X&gt;</tt> arguments and "unwraps" the reference in
+such cases. <tt>make_pair()</tt> would OTOH create a
+<tt>reference_wrapper&lt;X&gt;</tt> member. I suggest that the two
+functions are made to behave similar in this respect to minimize
+confusion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.2 [utility] change the synopsis for make_pair() to read
+</p>
+
+<blockquote><pre>template &lt;class T1, class T2&gt;
+  pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>, <del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt; make_pair(T1&amp;&amp;, T2&amp;&amp;);
+</pre></blockquote>
+
+<p>
+In 20.2.3 [pairs]/16 change the declaration to match the above synopsis.
+Then change the 20.2.3 [pairs]/17 to:
+</p>
+
+<blockquote>
+<p>
+<i>Returns:</i> <tt>pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>,<del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt;(forward&lt;T1&gt;(x),forward&lt;T2&gt;(y))</tt> <ins>where <tt>V1</tt> and
+<tt>V2</tt> are determined as follows: Let <tt>Ui</tt> be
+<tt>decay&lt;Ti&gt;::type</tt> for each <tt>Ti</tt>. Then each
+<tt>Vi</tt> is <tt>X&amp;</tt> if <tt>Ui</tt> equals
+<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
+<tt>Ui</tt>.</ins>
+</p>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="710"></a>710. Missing postconditions</h3>
+<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</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#WP">WP</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 <tt>shared_ptr</tt> move constructor and the cast functions are
+missing postconditions for the <tt>get()</tt> accessor.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Move to "ready", adopting the first (Peter's) proposed resolution.
+</p>
+<p>
+Note to the project editor: there is an editorial issue here. The
+wording for the postconditions of the casts is slightly awkward, and the
+editor should consider rewording "If w is the return value...", e. g. as
+"For a return value w...".
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to 20.7.12.2.1 [util.smartptr.shared.const]:
+</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>
+<p>
+<i>Postconditions:</i>  <tt>*this</tt> shall contain the old value of <tt>r</tt>. <tt>r</tt>
+shall be empty. <ins><tt>r.get() == 0</tt>.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Add to 20.7.12.2.10 [util.smartptr.shared.cast]:
+</p>
+
+<blockquote>
+<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; static_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
+</pre>
+<blockquote>
+<p>
+<ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
+<tt>w.get() == static_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; dynamic_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
+</pre>
+<blockquote>
+<p>
+<ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast&lt;T*&gt;(r.get())</tt>.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; const_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
+</pre>
+<blockquote>
+<p>
+<ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
+<tt>w.get() == const_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Alberto Ganesh Barbati has written an
+<a href="http://barbati.net/c++/shared_ptr.pdf">alternative proposal</a>
+where he suggests (among other things) that the casts be respecified in terms of
+the aliasing constructor as follows:
+</p>
+
+<p>
+Change 20.7.12.2.10 [util.smartptr.shared.cast]:
+</p>
+
+<blockquote>
+<p>
+-2- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
+shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
+object that stores <tt>static_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
+<tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, static_cast&lt;T*&gt;(r.get())</tt>.</ins>
+</p>
+</blockquote>
+
+<blockquote>
+<p>
+-6- <i>Returns:</i>
+</p>
+<ul>
+<li><del>When <tt>dynamic_cast&lt;T*&gt;(r.get())</tt> returns a nonzero value,
+a <tt>shared_ptr&lt;T&gt;</tt> object that stores a copy 
+of it and <i>shares ownership</i> with <tt>r</tt>;</del></li>
+<li><del>Otherwise, an <i>empty</i> <tt>shared_ptr&lt;T&gt;</tt> object.</del></li>
+<li><ins>If <tt>p = dynamic_cast&lt;T*&gt;(r.get())</tt> is a non-null pointer, <tt>shared_ptr&lt;T&gt;(r, p);</tt></ins></li>
+<li><ins>Otherwise, <tt>shared_ptr&lt;T&gt;()</tt>.</ins></li>
+</ul>
+</blockquote>
+
+<blockquote>
+<p>
+-10- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
+shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
+object that stores <tt>const_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
+<tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, const_cast&lt;T*&gt;(r.get())</tt>.</ins>
+</p>
+</blockquote>
+
+<p>
+This takes care of the missing postconditions for the casts by bringing
+in the aliasing constructor postcondition "by reference".
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="712"></a>712. <tt>seed_seq::size</tt> no longer useful</h3>
+<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Marc Paterno <b>Date:</b> 2007-08-25</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+One of the motivations for incorporating <tt>seed_seq::size()</tt>
+was to simplify the wording
+in other parts of 26.4 [rand].
+As a side effect of resolving related issues,
+all such references
+to <tt>seed_seq::size()</tt> will have been excised.
+More importantly,
+the present specification is contradictory,
+as "The number of 32-bit units the object can deliver"
+is not the same as "the result of <tt>v.size()</tt>."
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="715"></a>715. <tt>minmax_element</tt> complexity is too lax</h3>
+<p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The complexity for <tt>minmax_element</tt> (25.3.7 [alg.min.max] par 16) says "At most <tt>max(2 *
+(last - first ) - 2, 0)</tt> applications of the corresponding comparisons",
+i.e. the worst case complexity is no better than calling <tt>min_element</tt> and
+<tt>max_element</tt> separately. This is gratuitously inefficient. There is a
+well known technique that does better: see section 9.1 of CLRS
+(Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein).
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 25.3.7 [alg.min.max] to:
+</p>
+
+<blockquote>
+<pre>template&lt;class ForwardIterator&gt; 
+  pair&lt;ForwardIterator, ForwardIterator&gt; 
+    minmax_element(ForwardIterator first , ForwardIterator last); 
+template&lt;class ForwardIterator, class Compare&gt; 
+  pair&lt;ForwardIterator, ForwardIterator&gt; 
+    minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>make_pair(m, M)</tt>, where <tt>m</tt> is
+<del><tt>min_element(first, last)</tt> or <tt>min_element(first, last,
+comp)</tt></del> <ins>the first iterator in <tt>[first,
+last)</tt> such that no iterator in the range refers to a smaller element,</ins> and
+<ins>where</ins> <tt>M</tt> is <del><tt>max_element(first, last)</tt> or
+<tt>max_element(first, last, comp)</tt></del> <ins>the last iterator
+in <tt>[first, last)</tt> such that no iterator in the range refers to a larger element</ins>.
+</p>
+<p>
+<i>Complexity:</i> At most <del><tt>max(2 * (last - first ) - 2, 0)</tt></del>
+<ins><tt>max(&#8970;(3/2) (N-1)&#8971;, 0)</tt></ins> applications of the
+corresponding <del>comparisons</del> <ins>predicate, where <tt>N</tt> is <tt>distance(first, last)</tt></ins>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="722"></a>722. Missing [c.math] functions <tt>nanf</tt> and <tt>nanl</tt></h3>
+<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-27</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In the listing of 26.7 [c.math], table 108: Header <tt>&lt;cmath&gt;</tt> synopsis I miss
+the following C99 functions (from 7.12.11.2):
+</p>
+
+<blockquote><pre>float nanf(const char *tagp);
+long double nanl(const char *tagp);
+</pre></blockquote>
+
+<p>
+(Note: These functions cannot be overloaded and they are also not
+listed anywhere else)
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 26.7 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt>
+just after the existing entry <tt>nan</tt>.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="740"></a>740. Please remove <tt>*_ptr&lt;T[N]&gt;</tt></h3>
+<p><b>Section:</b> 20.7.11.4 [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Herb Sutter <b>Date:</b> 2007-10-04</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Please don't provide <tt>*_ptr&lt;T[N]&gt;</tt>. It doesn't enable any useful
+bounds-checking (e.g., you could imagine that doing <tt>op++</tt> on a
+<tt>shared_ptr&lt;T[N]&gt;</tt> yields a <tt>shared_ptr&lt;T[N-1]&gt;</tt>, but that promising path
+immediately falters on <tt>op--</tt> which can't reliably dereference because we
+don't know the lower bound). Also, most buffers you'd want to point to
+don't have a compile-time known size.
+</p>
+
+<p>
+To enable any bounds-checking would require run-time information, with
+the usual triplet: base (lower bound), current offset, and max offset
+(upper  bound). And I can sympathize with the point of view that you
+wouldn't want to require this on <tt>*_ptr</tt> itself. But please let's not
+follow the <tt>&lt;T[N]&gt;</tt> path, especially not with additional functions to
+query the bounds etc., because this sets wrong user expectations by
+embarking on a path that doesn't go all the way to bounds checking as it
+seems to imply.
+</p>
+
+<p>
+If bounds checking is desired, consider a <tt>checked_*_ptr</tt> instead (e.g.,
+<tt>checked_shared_ptr</tt>). And make the interfaces otherwise identical so that
+user code could easily <tt>#define/typedef</tt> between prepending <tt>checked_</tt> on
+debug builds and not doing so on release builds (for example).
+</p>
+
+<p>
+Note that some may object that <tt>checked_*_ptr</tt> may seem to make the smart
+pointer more like <tt>vector</tt>, and we don't want two ways to spell <tt>vector</tt>. I
+don't agree, but if that were true that would be another reason to
+remove <tt>*_ptr&lt;T[N]&gt;</tt> which equally makes the smart pointer more like
+<tt>std::array.</tt> :-)
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>Suggestion that fixed-size array instantiations are going to fail at
+compile time anyway (if we remove specialization) due to pointer decay,
+at least that appears to be result from available compilers.
+</p>
+<p>
+So concerns about about requiring static_assert seem unfounded.
+</p>
+<p>After a little more experimentation with compiler, it appears that
+fixed size arrays would only work at all if we supply these explicit
+specialization. So removing them appears less breaking than originally
+thought.
+</p>
+<p>
+straw poll unanimous move to Ready.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis under 20.7.11 [unique.ptr] p2:
+</p>
+
+<blockquote><pre>...
+template&lt;class T&gt; struct default_delete; 
+template&lt;class T&gt; struct default_delete&lt;T[]&gt;; 
+<del>template&lt;class T, size_t N&gt; struct default_delete&lt;T[N]&gt;;</del>
+
+template&lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr; 
+template&lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt;; 
+<del>template&lt;class T, class D, size_t N&gt; class unique_ptr&lt;T[N], D&gt;;</del>
+...
+</pre></blockquote>
+
+<p>
+Remove the entire section 20.7.11.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete&lt;T[N]&gt;</tt></b>.
+</p>
+
+<p>
+Remove the entire section 20.7.11.4 [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b>
+and its subsections: 20.7.11.4.1 [unique.ptr.compiletime.dtor], 20.7.11.4.2 [unique.ptr.compiletime.observers],
+20.7.11.4.3 [unique.ptr.compiletime.modifiers].
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="743"></a>743. rvalue <tt>swap</tt> for <tt>shared_ptr</tt></h3>
+<p><b>Section:</b> 20.7.12.2.9 [util.smartptr.shared.spec] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+When the LWG looked at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a> in Kona the following note was made:
+</p>
+
+<blockquote><p>
+We may need to open an issue to deal with the question of
+whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
+</p></blockquote>
+
+<p>
+This issue was opened in response to that note.
+</p>
+
+<p>
+I believe allowing rvalue <tt>shared_ptr</tt>s to <tt>swap</tt> is both
+appropriate, and consistent with how other library components are currently specified.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Concern that the three signatures for swap is needlessly complicated,
+but this issue merely brings shared_ptr into equal complexity with the
+rest of the library. Will open a new issue for concern about triplicate
+signatures.
+</p>
+<p>
+Adopt issue as written.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 20.7.12.2 [util.smartptr.shared]:
+</p>
+
+<blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
+...
+template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
+<ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
+template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
+</pre></blockquote>
+
+<p>
+Change 20.7.12.2.4 [util.smartptr.shared.mod]:
+</p>
+
+<blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
+</pre></blockquote>
+
+<p>
+Change 20.7.12.2.9 [util.smartptr.shared.spec]:
+</p>
+
+<blockquote><pre>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
+<ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
+template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="744"></a>744. What is the lifetime of an exception pointed to by an exception_ptr?</h3>
+<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Without some lifetime guarantee, it is hard to know how this type can be
+used.  Very specifically, I don't see how the current wording would
+guarantee and exception_ptr caught at the end of one thread could be safely
+stored and rethrown in another thread - the original motivation for this
+API.
+</p>
+<p>
+(Peter Dimov agreed it should be clearer, maybe a non-normative note to
+explain?)
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Agree the issue is real.
+</p>
+<p>
+Intent is lifetime is similar to a shared_ptr (and we might even want to
+consider explicitly saying that it is a shared_ptr&lt; unspecified type &gt;).
+</p>
+<p>
+We expect that most implementations will use shared_ptr, and the
+standard should be clear that the exception_ptr type is intended to be
+something whose semantics are smart-pointer-like so that the user does
+not need to worry about lifetime management. We still need someone to
+draught those words - suggest emailing Peter Dimov.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 18.7.5 [propagation]/7:
+</p>
+
+<blockquote>
+-7- Returns: An <tt>exception_ptr</tt> object that refers to the currently
+handled exception or a copy of the currently handled exception, or a
+null <tt>exception_ptr</tt> object if no exception is being handled.
+<ins>The referenced object remains valid at least as long as there is an
+<tt>exception_ptr</tt> that refers to it.</ins>
+If the function needs to allocate memory and the attempt
+fails, it returns an <tt>exception_ptr</tt> object that refers to an instance of
+<tt>bad_alloc</tt>. It is unspecified whether the return values of two successive
+calls to <tt>current_exception</tt> refer to the same exception object. [<i>Note:</i>
+that is, it is unspecified whether <tt>current_exception</tt> creates a new copy
+each time it is called. <i>--end note</i>]
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="746"></a>746. current_exception may fail with bad_alloc</h3>
+<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I understand that the attempt to copy an exception may run out of memory,
+but I believe this is the only part of the standard that mandates failure
+with specifically <tt>bad_alloc</tt>, as opposed to allowing an
+implementation-defined type derived from <tt>bad_alloc</tt>.  For instance, the Core
+language for a failed new expression is:
+</p>
+<blockquote>
+<p>
+Any other allocation function that fails to allocate storage shall indicate
+failure only by throwing an exception of a type that would match a handler
+(15.3) of type <tt>std::bad_alloc</tt> (18.5.2.1).
+</p>
+</blockquote>
+<p>
+I think we should allow similar freedom here (or add a blanket
+compatible-exception freedom paragraph in 17)
+</p>
+<p>
+I prefer the clause 17 approach myself, and maybe clean up any outstanding
+wording that could also rely on it.
+</p>
+<p>
+Although filed against a specific case, this issue is a problem throughout
+the library. 
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Is issue bigger than library?
+</p>
+<p>
+No - Core are already very clear about their wording, which is inspiration for the issue.
+</p>
+<p>
+While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue.
+</p>
+<p>
+Accept the broad view and move to ready
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following exemption clause to 17.4.4.9 [res.on.exception.handling]:
+</p>
+
+<blockquote>
+A function may throw a type not listed in its <i>Throws</i> clause so long as it is
+derived from a class named in the <i>Throws</i> clause, and would be caught by an
+exception handler for the base type.
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="749"></a>749. Currently <tt>has_nothrow_copy_constructor&lt;T&gt;::value</tt> is true if T has 'a' nothrow copy constructor.</h3>
+<p><b>Section:</b> 20.5.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Unfortunately a class can have multiple copy constructors, and I believe to
+be useful this trait should only return true is ALL copy constructors are
+no-throw.
+</p>
+<p>
+For instance:
+</p>
+<blockquote>
+<pre>struct awkward {
+ awkward( const awkward &amp; ) throw() {}
+ awkward( awkward &amp; ) { throw "oops"; } };
+</pre>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.5.4.3 [meta.unary.prop]:
+</p>
+
+<blockquote>
+<pre>has_trivial_copy_constructor</pre>
+<blockquote>
+<tt>T</tt> is a trivial type (3.9) or a reference type or a class type <del>with a trivial copy constructor</del>
+<ins>where all copy constructors are trivial</ins> (12.8).
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>has_trivial_assign</pre>
+<blockquote>
+<tt>T</tt> is neither <tt>const</tt> nor a reference type, and <tt>T</tt> is a trivial type (3.9)
+or a class type <del>with a trivial copy assignment operator</del> <ins>where all copy assignment operators are trivial</ins> (12.8).
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>has_nothrow_copy_constructor</pre>
+<blockquote>
+<tt>has_trivial_copy_constructor&lt;T&gt;::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with
+a</del> <ins>where all</ins> copy constructor<ins>s</ins> <del>that is</del> <ins>are</ins> 
+known not to throw any exceptions or <tt>T</tt> is an
+array of such a class type
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>has_nothrow_assign</pre>
+<blockquote>
+<tt>T</tt> is neither <tt>const</tt> nor a reference type, and
+<tt>has_trivial_assign&lt;T&gt;::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with a</del>
+<ins>where all</ins> copy
+assignment operator<ins>s</ins> tak<ins>e</ins><del>ing</del> an lvalue of type <tt>T</tt> that is known not to
+throw any exceptions or <tt>T</tt> is an array of such a class type.
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="755"></a>755. <tt>std::vector</tt> and <tt>std:string</tt> lack explicit shrink-to-fit operations</h3>
+<p><b>Section:</b> 23.2.6.2 [vector.capacity], 21.3.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-10-31</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+A <tt>std::vector</tt> can be shrunk-to-fit via the swap idiom:
+</p>
+
+<blockquote><pre>vector&lt;int&gt; v;
+...
+v.swap(vector&lt;int&gt;(v));  // shrink to fit
+</pre>
+<blockquote><p>
+or:
+</p></blockquote>
+<pre>vector&lt;int&gt;(v).swap(v);  // shrink to fit
+</pre>
+<blockquote><p>
+or:
+</p></blockquote>
+<pre>swap(v, vector&lt;int&gt;(v));  // shrink to fit
+</pre>
+</blockquote>
+
+<p>
+A non-binding request for shrink-to-fit can be made to a <tt>std::string</tt> via:
+</p>
+
+<blockquote><pre>string s;
+...
+s.reserve(0);
+</pre></blockquote>
+
+<p>
+Neither of these is at all obvious to beginners, and even some
+experienced C++ programmers are not aware that shrink-to-fit is
+trivially available.
+</p>
+<p>
+Lack of explicit functions to perform these commonly requested
+operations makes vector and string less usable for non-experts. Because
+the idioms are somewhat obscure, code readability is impaired. It is
+also unfortunate that two similar vector-like containers use different
+syntax for the same operation.
+</p>
+<p>
+The proposed resolution addresses these concerns. The proposed function
+takes no arguments to keep the solution simple and focused.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+To Class template basic_string 21.3 [basic.string] synopsis,
+Class template vector 23.2.6 [vector] synopsis, and Class
+vector&lt;bool&gt; 23.2.7 [vector.bool] synopsis, add:
+</p>
+
+<blockquote><pre>    
+void shrink_to_fit();
+</pre></blockquote>
+
+<p>
+To basic_string capacity 21.3.4 [string.capacity] and vector
+capacity 23.2.6.2 [vector.capacity], add:
+</p>
+
+<blockquote>
+<pre>void shrink_to_fit();
+</pre>
+<blockquote>
+<i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce
+<tt>capacity()</tt> to <tt>size()</tt>. [<i>Note:</i> The request is non-binding to
+allow latitude for implementation-specific optimizations.
+<i>-- end note</i>]
+</blockquote>
+</blockquote>
+
+<p><i>[
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a> has been added to deal with this issue with respect to <tt>deque</tt>.
+]</i></p>
+
+
+
+
+
+
+<hr>
+<h3><a name="759"></a>759. A reference is not an object</h3>
+<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Jens Maurer <b>Date:</b> 2007-11-06</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+23.1 [container.requirements] says:
+</p>
+
+<blockquote>
+-12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No 
+diagnostic required.
+</blockquote>
+
+<p>
+A reference is not an object, but this sentence appears to claim so.
+</p>
+
+<p>
+What is probably meant here:
+</p>
+<blockquote>
+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><b>Proposed resolution:</b></p>
+<p>
+Change 23.1 [container.requirements]:
+</p>
+
+<blockquote>
+-12- <del>Objects passed to member functions of a container as rvalue references shall not be elements</del>
+<ins>An object bound to an rvalue
+reference parameter of a member function of a container shall not be
+an element</ins>
+of that container<del>.</del><ins>;</ins> <del>N</del><ins>n</ins>o 
+diagnostic required.
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="761"></a>761. <tt>unordered_map</tt> needs an <tt>at()</tt> member function</h3>
+<p><b>Section:</b> 23.4.1.2 [unord.map.elem] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-15</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The new member function <tt>at()</tt> was recently added to <tt>std::map()</tt>.  It acts 
+like <tt>operator[]()</tt>, except it throws an exception when the input key is 
+not found.  It is useful when the <tt>map</tt> is <tt>const</tt>, the <tt>value_type</tt> of the 
+key doesn't have  a default constructor, it is an error if the key is 
+not found, or the user wants to avoid accidentally adding an element to 
+the map.  For exactly these same reasons, <tt>at()</tt> would be equally useful 
+in <tt>std::unordered_map</tt>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following functions to the definition of <tt>unordered_map</tt> under "lookup" (23.4.1 [unord.map]):
+</p>
+
+<blockquote><pre>mapped_type&amp; at(const key_type&amp; k);
+const mapped_type &amp;at(const key_type &amp;k) const;
+</pre></blockquote>
+
+<p>
+Add the following definitions to 23.4.1.2 [unord.map.elem]:
+</p>
+
+<blockquote>
+<pre>mapped_type&amp; at(const key_type&amp; k);
+const mapped_type &amp;at(const key_type &amp;k) const;
+</pre>
+<blockquote>
+<p>
+<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>.
+</p>
+<p>
+<i>Throws:</i> An exception object of type <tt>out_of_range</tt> if no such element 
+is present.
+</p>
+</blockquote>
+</blockquote>
+
+<p><i>[
+Bellevue:  Editorial note: the "(unique)" differs from map.
+]</i></p>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="766"></a>766. Inconsistent exception guarantees between ordered and unordered associative containers</h3>
+<p><b>Section:</b> 23.1 [container.requirements], 23.1.5.1 [unord.req.except] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Ion Gaztañaga <b>Date:</b> 2007-12-22</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+23.1 [container.requirements]p10 states:
+</p>
+
+<blockquote>
+<p>
+Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following
+additional requirements:
+</p>
+<ul>
+
+<li>[...]</li>
+
+<li>no <tt>erase()</tt>, <tt>pop_back()</tt> or <tt>pop_front()</tt> function throws an exception.</li>
+
+</ul>
+</blockquote>
+
+<p>
+23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer
+additional guarantees for <tt>deque</tt>/<tt>vector insert()</tt> and
+<tt>erase()</tt> members. However, 23.1 [container.requirements]p10
+does not mention 23.1.5.1 [unord.req.except] that specifies exception
+safety guarantees
+for unordered containers. In addition, 23.1.5.1 [unord.req.except]p1
+offers the following guaratee for
+<tt>erase()</tt>:
+</p>
+
+<blockquote>
+No <tt>erase()</tt> function throws an exception unless that exception
+is thrown by the container's Hash or Pred object (if any).
+</blockquote>
+
+<p>
+Summary:
+</p>
+
+<p>
+According to 23.1 [container.requirements]p10 no
+<tt>erase()</tt> function should throw an exception unless otherwise
+specified. Although does not explicitly mention 23.1.5.1 [unord.req.except], this section offers additional guarantees
+for unordered containers, allowing <tt>erase()</tt> to throw if
+predicate or hash function throws.
+</p>
+
+<p>
+In contrast, associative containers have no exception safety guarantees
+section so no <tt>erase()</tt> function should throw, <em>including
+<tt>erase(k)</tt></em> that needs to use the predicate function to
+perform its work. This means that the predicate of an associative
+container is not allowed to throw.
+</p>
+
+<p>
+So:
+</p>
+
+<ol>
+<li>
+<tt>erase(k)</tt> for associative containers is not allowed to throw. On
+the other hand, <tt>erase(k)</tt> for unordered associative containers
+is allowed to throw.
+</li>
+<li>
+<tt>erase(q)</tt> for associative containers is not allowed to throw. On
+the other hand, <tt>erase(q)</tt> for unordered associative containers
+is allowed to throw if it uses the hash or predicate.
+</li>
+<li>
+To fulfill 1), predicates of associative containers are not allowed to throw.
+Predicates of unordered associative containers are allowed to throw.
+</li>
+<li>
+2) breaks a widely used programming pattern (flyweight pattern) for
+unordered containers, where objects are registered in a global map in
+their constructors and unregistered in their destructors. If <tt>erase(q)</tt> is
+allowed to throw, the destructor of the object would need to rethrow the
+exception or swallow it, leaving the object registered.
+</li>
+</ol>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Create a new sub-section of 23.1.4 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
+safety guarantees".
+</p>
+
+<blockquote>
+<p>
+1 For associative containers, no <tt>clear()</tt> function throws an exception.
+<tt>erase(k)</tt> does not throw an exception unless that exception is thrown by
+the container's Pred object (if any).
+</p>
+
+<p>
+2 For associative containers, if an exception is thrown by any operation
+from within an <tt>insert()</tt> function inserting a single element, the
+<tt>insert()</tt> function has no effect.
+</p>
+
+<p>
+3 For associative containers, no <tt>swap</tt> function throws an exception
+unless that exception is thrown by the copy constructor or copy
+assignment operator of the container's Pred object (if any).
+</p>
+</blockquote>
+
+<p>
+Change 23.1.5.1 [unord.req.except]p1:
+</p>
+
+<blockquote>
+For unordered associative containers, no <tt>clear()</tt> function
+throws an exception. <del>No</del> <tt>erase(<ins>k</ins>)</tt>
+<del>function</del> <ins>does not</ins> throw<del>s</del> an exception
+unless that exception is thrown by the container's Hash or Pred object
+(if any).
+</blockquote>
+
+<p>
+Change 23.1 [container.requirements]p10 to add references to new sections:
+</p>
+
+<blockquote>
+Unless otherwise specified (see [deque.modifiers]<ins>,</ins>
+<del>and</del> [vector.modifiers]<ins>, [associative.req.except],
+[unord.req.except]</ins>) all container types defined in this clause meet
+the following additional requirements:
+</blockquote>
+
+<p>
+Change 23.1 [container.requirements]p10 referring to <tt>swap</tt>:
+</p>
+
+<blockquote>
+<ul>
+<li>
+no <tt>swap()</tt> function throws an exception<del> unless that exception is thrown
+by the copy constructor or assignment operator of the container's
+Compare object (if any; see [associative.reqmts])</del>.
+</li>
+</ul>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="768"></a>768. Typos in [atomics]?</h3>
+<p><b>Section:</b> 29.3.3 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2007-12-28</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+in the latest publicly available draft, paper
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">N2641</a>,
+in section 29.3.3 [atomics.types.generic], the following specialization of the template
+<tt>atomic&lt;&gt;</tt> is provided for pointers:
+</p>
+
+<blockquote><pre>template &lt;class T&gt; struct atomic&lt;T*&gt; : atomic_address { 
+  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
+  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
+
+  atomic() = default; 
+  constexpr explicit atomic(T); 
+  atomic(const atomic&amp;) = delete; 
+  atomic&amp; operator=(const atomic&amp;) = delete; 
+
+  T* operator=(T*) volatile; 
+  T* operator++(int) volatile; 
+  T* operator--(int) volatile; 
+  T* operator++() volatile; 
+  T* operator--() volatile; 
+  T* operator+=(ptrdiff_t) volatile;
+  T* operator-=(ptrdiff_t) volatile; 
+};
+</pre></blockquote>
+
+<p>
+First of all, there is a typo in the non-default constructor which
+should take a <tt>T*</tt> rather than a <tt>T</tt>.
+</p>
+
+<p>
+As you can see, the specialization redefine and therefore hide a few
+methods from the base class <tt>atomic_address</tt>, namely <tt>fetch_add</tt>, <tt>fetch_sub</tt>,
+<tt>operator=</tt>, <tt>operator+=</tt> and <tt>operator-=</tt>. That's good, but... what happened
+to the other methods, in particular these ones:
+</p>
+
+<blockquote><pre>void store(T*, memory_order = memory_order_seq_cst) volatile;
+T* load( memory_order = memory_order_seq_cst ) volatile;
+T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
+bool compare_swap( T*&amp;, T*, memory_order, memory_order ) volatile;
+bool compare_swap( T*&amp;, T*, memory_order = memory_order_seq_cst ) volatile;
+</pre></blockquote>
+
+<p>
+By reading paper
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427 "C++ Atomic Types and Operations"</a>,
+I see that the
+definition of the specialization <tt>atomic&lt;T*&gt;</tt> matches the one in the
+draft, but in the example implementation the methods <tt>load()</tt>, <tt>swap()</tt>
+and <tt>compare_swap()</tt> are indeed present.
+</p>
+
+<p>
+Strangely, the example implementation does not redefine the method
+<tt>store()</tt>. It's true that a <tt>T*</tt> is always convertible to <tt>void*</tt>, but not
+hiding the <tt>void*</tt> signature from the base class makes the class
+error-prone to say the least: it lets you assign pointers of any type to
+a <tt>T*</tt>, without any hint from the compiler.
+</p>
+
+<p>
+Is there a true intent to remove them from the specialization or are
+they just missing from the definition because of a mistake?
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+The proposed revisions are accepted.
+</p>
+<p>
+Further discussion: why is the ctor labeled "constexpr"? Lawrence said
+this permits the object to be statically initialized, and that's
+important because otherwise there would be a race condition on
+initialization.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 29.3.3 [atomics.types.generic]:
+</p>
+
+<blockquote><pre>template &lt;class T&gt; struct atomic&lt;T*&gt; : atomic_address { 
+  <ins>void store(T*, memory_order = memory_order_seq_cst) volatile;</ins>
+  <ins>T* load( memory_order = memory_order_seq_cst ) volatile;</ins>
+  <ins>T* swap( T*, memory_order = memory_order_seq_cst ) volatile;</ins>
+  <ins>bool compare_swap( T*&amp;, T*, memory_order, memory_order ) volatile;</ins>
+  <ins>bool compare_swap( T*&amp;, T*, memory_order = memory_order_seq_cst ) volatile;</ins>
+
+  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
+  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
+
+  atomic() = default; 
+  constexpr explicit atomic(T<ins>*</ins>); 
+  atomic(const atomic&amp;) = delete; 
+  atomic&amp; operator=(const atomic&amp;) = delete; 
+
+  T* operator=(T*) volatile; 
+  T* operator++(int) volatile; 
+  T* operator--(int) volatile; 
+  T* operator++() volatile; 
+  T* operator--() volatile; 
+  T* operator+=(ptrdiff_t) volatile;
+  T* operator-=(ptrdiff_t) volatile; 
+};
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="770"></a>770. std::function should use rvalue swap</h3>
+<p><b>Section:</b> 20.6.15 [func.wrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-10</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+It is expected that typical implementations of <tt>std::function</tt> will
+use dynamic memory allocations at least under given conditions,
+so it seems appropriate to change the current lvalue swappabilty of
+this class to rvalue swappability.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.6 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis, just below of
+</p>
+
+<blockquote><pre>template&lt;class R, class... ArgTypes&gt;
+  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
+<ins>template&lt;class R, class... ArgTypes&gt;
+  void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
+template&lt;class R, class... ArgTypes&gt;
+  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</ins>
+</pre></blockquote>
+
+<p>
+In 20.6.15.2 [func.wrap.func] class <tt>function</tt> definition, change
+</p>
+
+<blockquote><pre>void swap(function&amp;<ins>&amp;</ins>);
+</pre></blockquote>
+
+<p>
+In 20.6.15.2 [func.wrap.func], just below of
+</p>
+
+<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
+  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
+<ins>template &lt;class R, class... ArgTypes&gt;
+  void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
+template &lt;class R, class... ArgTypes&gt;
+  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</ins>
+</pre></blockquote>
+
+<p>
+In 20.6.15.2.2 [func.wrap.func.mod] change
+</p>
+
+<blockquote><pre>void swap(function&amp;<ins>&amp;</ins> other);
+</pre></blockquote>
+
+<p>
+In 20.6.15.2.7 [func.wrap.func.alg] add the two overloads
+</p>
+
+<blockquote><pre><ins>template&lt;class R, class... ArgTypes&gt;
+  void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp; f2);
+template&lt;class R, class... ArgTypes&gt;
+  void swap(function&lt;R(ArgTypes...)&gt;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp;&amp; f2);</ins>
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="775"></a>775. Tuple indexing should be unsigned?</h3>
+<p><b>Section:</b> 20.4.1.4 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-01-16</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The tuple element access API identifies the element in the sequence
+using signed integers, and then goes on to enforce the requirement that
+I be &gt;= 0.  There is a much easier way to do this - declare I as
+<tt>unsigned</tt>.
+</p>
+<p>
+In fact the proposal is to use <code>std::size_t</code>, matching the type used in the <tt>tuple_size</tt> API.
+</p>
+<p>
+A second suggestion is that it is hard to imagine an API that deduces
+and index at compile time and returns a reference throwing an exception.
+Add a specific <em>Throws:</em> Nothing paragraph to each element
+access API.
+</p>
+<p>
+In addition to <code>tuple</code>, update the API applies to
+<code>pair</code> and <code>array</code>, and should be updated
+accordingly.
+</p>
+
+<p>
+A third observation is that the return type of the <code>get</code>
+functions for <code>std::pair</code> is pseudo-code, but it is not
+clearly marked as such.  There is actually no need for pseudo-code as
+the return type can be specified precisely with a call to
+<code>tuple_element</code>.  This is already done for
+<code>std::tuple</code>, and <code>std::array</code> does not have a
+problem as all elements are of type <code>T</code>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Update header &lt;utility&gt; synopsis in 20.2 [utility]
+</p>
+<pre><em>// 20.2.3, tuple-like access to pair:</em>
+template &lt;class T&gt; class tuple_size;
+template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element;
+
+template &lt;class T1, class T2&gt; struct tuple_size&lt;std::pair&lt;T1, T2&gt; &gt;;
+template &lt;class T1, class T2&gt; struct tuple_element&lt;0, std::pair&lt;T1, T2&gt; &gt;;
+template &lt;class T1, class T2&gt; struct tuple_element&lt;1, std::pair&lt;T1, T2&gt; &gt;;
+
+template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
+  <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(std::pair&lt;T1, T2&gt;&amp;);
+template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
+  const <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(const std::pair&lt;T1, T2&gt;&amp;);
+</pre>
+<p>
+Update <strong>20.2.3 [pairs] Pairs</strong>
+</p>
+<pre>template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
+  <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(pair&lt;T1, T2&gt;&amp;);
+template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
+  const <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(const pair&lt;T1, T2&gt;&amp;);
+</pre>
+<p>
+<del>24 <em>Return type:</em> If <code>I == 0</code> then <code>P</code> is <code>T1</code>, if <code>I == 1</code> then <code>P</code> is <code>T2</code>, and otherwise the program is ill-formed.</del>
+</p>
+<p>
+25 <em>Returns:</em> If <code>I == 0</code> returns <code>p.first</code>, <del>otherwise</del> <ins>if <code>I == 1</code></ins> returns <code>p.second</code><ins>, and otherwise the program is ill-formed</ins>.
+</p>
+<p>
+<ins><em>Throws:</em> Nothing.</ins>
+</p>
+
+
+<p>
+Update header &lt;tuple&gt; synopsis in 20.4 [tuple] with a APIs as below:
+</p>
+<pre>template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element; <em>// undefined</em>
+template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt; class tuple_element&lt;I, tuple&lt;Types...&gt; &gt;;
+
+<em>// 20.3.1.4, element access:</em>
+template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt;
+  typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp; get(tuple&lt;Types...&gt;&amp;);
+template &lt;<del>int</del><ins>size_t</ins> I, class ... types&gt;
+  typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type const&amp; get(const tuple&lt;Types...&gt;&amp;);
+</pre>
+
+<p>
+Update <strong>20.4.1.4 [tuple.helper] Tuple helper classes</strong>
+</p>
+<pre>template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt;
+class tuple_element&lt;I, tuple&lt;Types...&gt; &gt; {
+public:
+  typedef TI type;
+};</pre>
+<p>
+1 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
+</p>
+<p>
+2 <em>Type:</em> <code>TI</code> is the type of the <code>I</code>th element of <code>Types</code>, where indexing is zero-based.
+</p>
+<p>
+Update <strong>20.4.1.5 [tuple.elem] Element access</strong>
+</p>
+<pre>template &lt;<del>int</del><ins>size_t</ins> I, class... types &gt;
+typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp; get(tuple&lt;Types...&gt;&amp; t);
+</pre>
+1 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
+<p>
+2 <em>Returns:</em> A reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
+</p>
+<ins><em>Throws:</em> Nothing.</ins>
+<pre>template &lt;<del>int</del><ins>size_t</ins> I, class... types&gt;
+typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type const&amp; get(const tuple&lt;Types...&gt;&amp; t);
+</pre>
+<p>
+3 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
+</p>
+<p>
+4 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
+</p>
+<p>
+<ins><em>Throws:</em> Nothing.</ins>
+</p>
+
 
+<p>
+Update header &lt;array&gt; synopsis in 20.2 [utility]
+</p>
+<pre>template &lt;class T&gt; class tuple_size; <em>// forward declaration</em>
+template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element; <em>// forward declaration</em>
+template &lt;class T, size_t N&gt;
+  struct tuple_size&lt;array&lt;T, N&gt; &gt;;
+template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
+  struct tuple_element&lt;I, array&lt;T, N&gt; &gt;;
+template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
+  T&amp; get(array&lt;T, N&gt;&amp;);
+template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
+  const T&amp; get(const array&lt;T, N&gt;&amp;);
+</pre>
 
-<hr>
-<h3><a name="689"></a>689. reference_wrapper constructor overly constrained</h3>
-<p><b>Section:</b> 20.5.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-The constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary
-motivation behind this is the safety problem with respect to rvalues,
-which is addressed by the proposed resolution of the previous issue.
-Therefore we should consider relaxing the requirements on the
-constructor since requests for the implicit conversion keep resurfacing.
+Update <strong>23.2.1.6 [array.tuple] Tuple interface to class template array</strong>
 </p>
+<pre>tuple_element&lt;<ins>size_t </ins>I, array&lt;T, N&gt; &gt;::type
+</pre>
 <p>
-Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
+3 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N.</code> The program is ill-formed if <code>I</code> is out of bounds.
 </p>
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Remove the <tt>explicit</tt> from the constructor of <tt>reference_wrapper</tt>. If the
-proposed resolution of the previous issue is accepted, remove the
-<tt>explicit</tt> from the <tt>T&amp;&amp;</tt> constructor as well to keep them in sync.
+4 <em>Value:</em> The type <code>T</code>.
+</p>
+<pre>template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt; T&amp; get(array&lt;T, N&gt;&amp; a);
+</pre>
+<p>
+5 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N</code>. The program is ill-formed if <code>I</code> is out of bounds.
+</p>
+<p>
+<em>Returns:</em> A reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
 </p>
+<p>
+<ins><em>Throws:</em> Nothing.</ins>
+</p>
+<pre>template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt; const T&amp; get(const array&lt;T, N&gt;&amp; a);
+</pre>
+<p>
+6 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N</code>. The program is ill-formed if <code>I</code> is out of bounds.
+</p>
+<p>
+7 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
+</p>
+<p>
+<ins><em>Throws:</em> Nothing.</ins>
+</p>
+
 
+<p><i>[
+Bellevue: Note also that the phrase "The program is ill-formed if I is
+out of bounds" in the requires clauses are probably unnecessary, and
+could be removed at the editor's discretion. Also std:: qualification
+for pair is also unnecessary.
+]</i></p>
 
 
 
 
 <hr>
-<h3><a name="693"></a>693. <code>std::bitset::all()</code> missing</h3>
-<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</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>
+<h3><a name="777"></a>777. Atomics Library Issue</h3>
+<p><b>Section:</b> 29.4 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-01-21</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#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The  <code>bitset</code> class template  provides the  member function
-<code>any()</code> to determine whether an  object of the type has any
-bits  set, and  the member  function <code>none()</code>  to determine
-whether all of an object's  bits are clear. However, the template does
-not   provide  a   corresponding  function   to  discover   whether  a
-<code>bitset</code>  object  has  all  its  bits  set.   While  it  is
-possible,  even easy,  to  obtain this  information  by comparing  the
-result of <code>count()</code>  with the result of <code>size()</code>
-for  equality  (i.e.,  via  <code>b.count()  ==  b.size()</code>)  the
-operation  is   less  efficient   than  a  member   function  designed
-specifically  for that purpose  could be.   (<code>count()</code> must
-count  all non-zero bits  in a  <code>bitset</code> a  word at  a time
-while <code>all()</code> could stop counting as soon as it encountered
-the first word with a zero bit).
+The load functions are defined as
 </p>
 
+<blockquote><pre>C atomic_load(volatile A* object);
+C atomic_load_explicit(volatile A* object, memory_order);
+C A::load(memory_order order = memory_order_seq_cst) volatile;
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Add  a declaration of the new  member function <code>all()</code> to the
-defintion of the <code>bitset</code> template in 23.3.5 [template.bitset], p1,
-right above the declaration of <code>any()</code> as shown below:
+which prevents their use in <tt>const</tt> contexts.
 </p>
 
-<blockquote><pre>bool operator!=(const bitset&lt;N&gt;&amp; rhs) const;
-bool test(size_t pos) const;
-<ins>bool all() const;</ins>
-bool any() const;
-bool none() const;
-</pre></blockquote>
+<p><i>[
+post Bellevue Peter adds:
+]</i></p>
+
 
+<blockquote>
 <p>
-Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text:
-</p>
-<blockquote><p>
-<code>bool all() const;</code>
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a> suggests making <tt>atomic_load</tt> operate on <tt>const</tt> objects. There is a
+subtle point here. Atomic loads do not generally write to the object, except
+potentially for the <tt>memory_order_seq_cst</tt> constraint. Depending on the
+architecture, a dummy write with the same value may be required to be issued
+by the atomic load to maintain sequential consistency. This, in turn, may
+make the following code:
 </p>
-<blockquote>
-<i>Returns</i>: <code>count() == size()</code>.
-</blockquote>
-</blockquote>
+
+<blockquote><pre>const atomic_int x{};
+
+int main()
+{
+  x.load();
+}
+</pre></blockquote>
 
 <p>
-In  addition,   change  the  description   of  <code>any()</code>  and
-<code>none()</code>   for  consistency   with   <code>all()</code>  as
-follows:
-</p>
-<blockquote><p>
-<code>bool any() const;</code>
+dump core under a straightforward implementation that puts const objects in
+a read-only section.
 </p>
-<blockquote>
 <p>
-<i>Returns</i>: <del><code>true</code> if any bit in <code>*this</code>
-is one</del><ins><code>count() != 0</code></ins>.
+There are ways to sidestep the problem, but it needs to be considered.
 </p>
-</blockquote>
 <p>
-<code>bool none() const;</code>
+The tradeoff is between making the data member of the atomic types
+mutable and requiring the user to explicitly mark atomic members as
+mutable, as is already the case with mutexes.
 </p>
-<blockquote>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-<i>Returns</i>: <del><code>true</code> if no bit in <code>*this</code>
-is one</del><ins><code>count() == 0</code></ins>.
+Add the <tt>const</tt> qualifier to <tt>*object</tt> and <tt>*this</tt>.
 </p>
-</blockquote>
-</blockquote>
+
+<blockquote><pre>C atomic_load(<ins>const</ins> volatile A* object);
+C atomic_load_explicit(<ins>const</ins> volatile A* object, memory_order);
+C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile;
+</pre></blockquote>
+
 
 
 
 
 
 <hr>
-<h3><a name="694"></a>694. <code>std::bitset</code> and <code>long long</code></h3>
-<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</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>
+<h3><a name="778"></a>778. std::bitset does not have any constructor taking a string literal</h3>
+<p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-01-24</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a></p>
 <p><b>Discussion:</b></p>
 <p>
-Objects of the  <code>bitset</code> class template specializations can
-be constructed from  and explicitly converted to values  of the widest
-C++ integer  type, <code>unsigned long</code>.   With the introduction
-of  <code>long long</code> into  the language  the template  should be
-enhanced to make it possible  to interoperate with values of this type
-as well, or  perhaps <code>uintmax_t</code>.  See c++std-lib-18274 for
-a brief discussion in support of this change.
+A small issue with <tt>std::bitset</tt>: it does not have any constructor
+taking a string literal, which is clumsy and looks like an oversigt when
+we tried to enable uniform use of <tt>string</tt> and <tt>const char*</tt> in the library.
 </p>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
-For simplicity,  instead of  adding overloads for  <code>unsigned long
-long</code> and dealing with possible ambiguities in the spec, replace
-the <code>bitset</code> ctor  that takes an <code>unsigned long</code>
-argument  with  one  taking  <code>unsigned long  long</code>  in  the
-definition  of the  template as  shown below.   (The  standard permits
-implementations  to add  overloads on  other integer  types  or employ
-template tricks to  achieve the same effect provided  they don't cause
-ambiguities or changes in behavior.)
+Suggestion: Add
 </p>
-<blockquote>
-<pre>// [bitset.cons] constructors:
-bitset();
-bitset(unsigned <ins>long</ins> long val);
-template&lt;class charT, class traits, class Allocator&gt;
-explicit bitset(
-                const basic_string&lt;charT,traits,Allocator&gt;&amp; str,
-                typename basic_string&lt;charT,traits,Allocator&gt;::size_type pos = 0,
-                typename basic_string&lt;charT,traits,Allocator&gt;::size_type n =
-                    basic_string&lt;charT,traits,Allocator&gt;::npos);
-</pre>
-</blockquote>
+
+<blockquote><pre>explicit bitset( const char* str );
+</pre></blockquote>
+
 <p>
-Make a corresponding change in 23.3.5.1 [bitset.cons], p2:
+to std::bitset.
 </p>
-<blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-<code>bitset(unsigned <ins>long</ins> long val);</code>
+Add to synopsis in 23.3.5 [template.bitset]
 </p>
-<blockquote>
-<i>Effects</i>:  Constructs   an  object  of   class  bitset&lt;N&gt;,
-initializing  the  first <code><i>M</i></code>  bit  positions to  the
-corresponding      bit     values      in     <code><i>val</i></code>.
-<code><i>M</i></code> is the  smaller of <code><i>N</i></code> and the
-number of bits in  the value representation (section [basic.types]) of
-<code>unsigned  <ins> long</ins> long</code>.   If  <code><i>M</i> &lt;
-<i>N</i></code>  <ins>is  <code>true</code></ins>,  the remaining  bit
-positions are initialized to zero.
-</blockquote>
-</blockquote>
+
+<blockquote><pre>explicit bitset( const char* str );
+</pre></blockquote>
 
 <p>
-Additionally, introduce a new member function <code>to_ullong()</code>
-to make  it possible to  convert <code>bitset</code> to values  of the
-new  type. Add  the following  declaration  to the  definition of  the
-template, immediate  after the declaration  of <code>to_ulong()</code>
-in 23.3.5 [template.bitset], p1, as shown below:
+Add to synopsis in 23.3.5.1 [bitset.cons]
 </p>
-<blockquote>
-<pre>// element access:
-bool operator[](size_t pos) const; // for b[i];
-reference operator[](size_t pos); // for b[i];
-unsigned long to_ulong() const;
-<ins>unsigned long long to_ullong() const;</ins>
-template &lt;class charT, class traits, class Allocator&gt;
-basic_string&lt;charT, traits, Allocator&gt; to_string() const;
+
+<blockquote><pre>explicit bitset( const char* str );
 </pre>
-</blockquote>
-<p>
-And add a description of  the new member function to 23.3.5.2 [bitset.members],
-below  the  description of  the  existing <code>to_ulong()</code>  (if
-possible), with the following text:
-</p>
-<blockquote>
 <p>
-<code>unsigned long long to_ullong() const;</code>
+<i>Effects:</i> Constructs a <tt>bitset</tt> as if <tt>bitset(string(str))</tt>.
 </p>
-<blockquote>
-<i>Throws</i>:  <code>overflow_error</code>   if  the  integral  value
-<code><i>x</i></code> corresponding to  the bits in <code>*this</code>
-cannot be represented as type <code>unsigned long long</code>.
-</blockquote>
-<blockquote>
-<i>Returns:</i> <code><i>x</i></code>.
-</blockquote>
 </blockquote>
 
 
 
 
 
+
 <hr>
-<h3><a name="695"></a>695. ctype&lt;char&gt;::classic_table() not accessible</h3>
-<p><b>Section:</b> 22.2.1.3 [facet.ctype.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
+<h3><a name="781"></a>781. <tt>std::complex</tt> should add missing C99 functions</h3>
+<p><b>Section:</b> 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The   <code>ctype&lt;char&gt;::classic_table()</code>   static  member
-function    returns    a    pointer    to   an    array    of    const
-<code>ctype_base::mask</code>    objects    (enums)   that    contains
-<code>ctype&lt;char&gt;::table_size</code>    elements.    The   table
-describes the properties of the character set in the "C" locale (i.e.,
-whether a  character at an index  given by its value  is alpha, digit,
-punct,   etc.),   and   is    typically   used   to   initialize   the
-<code>ctype&lt;char&gt;</code>  facet in the  classic "C"  locale (the
-protected      <code>ctype&lt;char&gt;</code>      member     function
-<code>table()</code>    then    returns     the    same    value    as
-<code>classic_table()</code>).
+A comparision of the N2461 header <tt>&lt;complex&gt;</tt> synopsis ([complex.synopsis])
+with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
+some complex functions that are missing in C++. These are:
 </p>
+
+<ol>
+<li>
+7.3.9.4: (required elements of the C99 library)<br>
+The <tt>cproj</tt> functions
+</li>
+<li>
+7.26.1: (optional elements of the C99 library)<br>
+<pre>cerf    cerfc    cexp2
+cexpm1  clog10   clog1p
+clog2   clgamma  ctgamma
+</pre>
+</li>
+</ol>
+
 <p>
-However, while <code>ctype&lt;char&gt;::table_size</code> (the size of
-the   table)    is   a   public    static   const   member    of   the
-<code>ctype&lt;char&gt;</code>           specialization,           the
-<code>classic_table()</code> static member function is protected. That
-makes getting at the classic  data less than convenient (i.e., one has
-to create  a whole derived class just  to get at the  masks array). It
-makes  little sense  to expose  the size  of the  table in  the public
-interface while making the table itself protected, especially when the
-table is a constant object.
+I propose that at least the required <tt>cproj</tt> overloads are provided as equivalent
+C++ functions. This addition is easy to do in one sentence (delegation to C99
+function).
 </p>
+
 <p>
-The  same argument  can be  made for  the non-static  protected member
-function <code>table()</code>.
+Please note also that the current entry <tt>polar</tt>
+in 26.3.9 [cmplx.over]/1
+should be removed from the mentioned overload list. It does not make sense to require that a
+function already expecting <em>scalar</em> arguments
+should cast these arguments into corresponding
+<tt>complex&lt;T&gt;</tt> arguments, which are not accepted by
+this function.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Make     the    <code>ctype&lt;char&gt;::classic_table()</code>    and
-<code>ctype&lt;char&gt;::table()</code>  member  functions  public  by
-moving their declarations into the public section of the definition of
-specialization in 22.2.1.3 [facet.ctype.special] as shown below:
+In 26.3.1 [complex.synopsis] add just between the declaration of <tt>conj</tt> and <tt>fabs</tt>:
+</p>
+
+<blockquote><pre>template&lt;class T&gt; complex&lt;T&gt; conj(const complex&lt;T&gt;&amp;);
+<ins>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp;);</ins>
+template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp;);
+</pre></blockquote>
+
+<p>
+In 26.3.7 [complex.value.ops] just after p.6 (return clause of <tt>conj</tt>) add:
+</p>
+
+<blockquote>
+<pre>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp; x);
+</pre>
+<blockquote>
+
+<i>Effects:</i> Behaves the same as C99 function <tt>cproj</tt>, defined in
+subclause 7.3.9.4."
+</blockquote>
+</blockquote>
+
+<p>
+In 26.3.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to
+the overload list.
 </p>
-<blockquote>
-<pre>  static locale::id id;
-  static const size_t table_size = IMPLEMENTATION_DEFINED;
-<del>protected:</del>
-  const mask* table() const throw();
-  static const mask* classic_table() throw();
-<ins>protected:</ins>
 
-~ctype(); // virtual
-virtual char do_toupper(char c) const;
-</pre>
+<blockquote>
+<p>
+The following function templates shall have additional overloads:
+</p>
+<blockquote><pre>arg           norm 
+conj          <del>polar</del> <ins>proj</ins>
+imag          real
+</pre></blockquote>
 </blockquote>
 
 
 
 
 
+
 <hr>
-<h3><a name="699"></a>699. N2111 changes min/max</h3>
-<p><b>Section:</b> 26.4 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</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="782"></a>782. Extended <tt>seed_seq</tt> constructor is useless</h3>
+<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-27</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</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#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
-changes <tt>min/max</tt> in several places in random from member
-functions to static data members. I believe this introduces
-a needless backward compatibility problem between C++0X and
-TR1. I'd like us to find new names for the static data members,
-or perhaps change <tt>min/max</tt> to <tt>constexpr</tt>s in C++0X.
+Part of the resolution of n2423, issue 8 was the proposal to
+extend the <tt>seed_seq</tt> constructor accepting an input range
+as follows (which is now part of N2461):
 </p>
 
+<blockquote><pre>template&lt;class InputIterator,
+size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits&gt;
+seed_seq(InputIterator begin, InputIterator end);
+</pre></blockquote>
+
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
+First, the expression <tt>iterator_traits&lt;InputIterator&gt;::value_type</tt>
+is invalid due to missing <tt>typename</tt> keyword, which is easy to
+fix.
 </p>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+Second (and worse), while the language now supports default
+template arguments of function templates, this customization
+point via the second <tt>size_t</tt> template parameter is of no advantage,
+because <tt>u</tt> can never be deduced, and worse - because it is a
+constructor function template - it can also never be explicitly
+provided (14.8.1 [temp.arg.explicit]/7).
 </p>
 
+<p>
+The question arises, which advantages result from a compile-time
+knowledge of <tt>u</tt> versus a run time knowledge? If run time knowledge
+suffices, this parameter should be provided as normal function
+default argument [Resolution marked (A)], if compile-time knowledge
+is important, this could be done via a tagging template or more
+user-friendly via a standardized helper generator function
+(<tt>make_seed_seq</tt>), which allows this [Resolution marked (B)].
+</p>
 
 <p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+Bellevue:
 ]</i></p>
 
 
+<blockquote>
+<p>
+Fermilab does not have a strong opinion. Would prefer to go with
+solution A. Bill agrees that solution A is a lot simpler and does the
+job.
+</p>
+<p>
+Proposed Resolution: Accept Solution A.
+</p>
+</blockquote>
+
+<p>
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> claims to make this issue moot.
+</p>
 
 
 
-<hr>
-<h3><a name="700"></a>700. N1856 defines struct <tt>identity</tt></h3>
-<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</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>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Proposed resolution:</b></p>
+<ol type="A">
+<li>
 <p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
-defines struct <tt>identity</tt> in <tt>&lt;utility&gt;</tt> which clashes with
-the traditional definition of struct <tt>identity</tt> in <tt>&lt;functional&gt;</tt>
-(not standard, but a common extension from old STL). Be nice
-if we could avoid this name clash for backward compatibility.
+In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace:
 </p>
 
+<blockquote><pre>class seed_seq 
+{ 
+public:
+   ...
+   template&lt;class InputIterator<del>,
+      size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
+          seed_seq(InputIterator begin, InputIterator end<ins>,
+          size_t u = numeric_limits&lt;typename iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</ins>);
+   ...
+};
+</pre></blockquote>
+
+<p>
+and do a similar replacement in the member description between
+p.3 and p.4.
+</p>
+</li>
 
-<p><b>Proposed resolution:</b></p>
+<li>
 <p>
-Change 20.2.2 [forward]:
+In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis <em>and</em> in the
+member description between p.3 and p.4 replace:
+</p>
+
+<blockquote><pre>template&lt;class InputIterator<del>,
+  size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
+         seed_seq(InputIterator begin, InputIterator end);
+<ins>template&lt;class InputIterator, size_t u&gt;
+seed_seq(InputIterator begin, InputIterator end, <i>implementation-defined</i> s);</ins>
+</pre></blockquote>
+
+<p>
+In 26.4.2 [rand.synopsis], header <tt>&lt;random&gt;</tt> synopsis, immediately after the
+class <tt>seed_seq</tt> declaration <em>and</em> in 26.4.7.1 [rand.util.seedseq]/2, immediately
+after the class <tt>seed_seq</tt> definition add:
+</p>
+
+<blockquote><pre>template&lt;size_t u, class InputIterator&gt;
+  seed_seq make_seed_seq(InputIterator begin, InputIterator end);
+</pre></blockquote>
+
+<p>
+In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
 </p>
 
 <blockquote>
-<pre>template &lt;class T&gt; struct identity
-{
-    typedef T type;
-    <ins>const T&amp; operator()(const T&amp; x) const;</ins>
-};
-</pre>
+<p>
+The first constructor behaves as if it would provide an
+integral constant expression <tt>u</tt> of type <tt>size_t</tt> of value
+<tt>numeric_limits&lt;typename iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</tt>.
+</p>
+<p>
+The second constructor uses an implementation-defined mechanism
+to provide an integral constant expression <tt>u</tt> of type <tt>size_t</tt> and
+is called by the function <tt>make_seed_seq</tt>.
+</p>
+</blockquote>
+
+<p>
+In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add:
+</p>
+
 <blockquote>
-<pre><ins>const T&amp; operator()(const T&amp; x) const;</ins>
+<pre>template&lt;size_t u, class InputIterator&gt;
+   seed_seq make_seed_seq(InputIterator begin, InputIterator end);
 </pre>
 <blockquote>
 <p>
-<ins><i>Returns:</i> <tt>x</tt>.</ins>
+where <tt>u</tt> is used to construct an object <tt>s</tt> of implementation-defined type.
+</p>
+<p>
+<i>Returns:</i> <tt>seed_seq(begin, end, s)</tt>;
 </p>
 </blockquote>
 </blockquote>
 
-</blockquote>
+</li>
+</ol>
 
 
 
@@ -26270,24 +29539,82 @@ Change 20.2.2 [forward]:
 
 
 <hr>
-<h3><a name="703"></a>703. <tt>map::at()</tt> need a complexity specification</h3>
-<p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-07-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p>
+<h3><a name="783"></a>783. <tt>thread::id</tt> reuse</h3>
+<p><b>Section:</b> 30.2.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Hans Boehm <b>Date:</b> 2008-02-01</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-<tt>map::at()</tt> need a complexity specification.
+The current working paper 
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html">N2497</a>,
+integrated just before Bellevue) is
+not completely clear whether a given <tt>thread::id</tt> value may be reused once
+a thread has exited and has been joined or detached.  Posix allows
+thread ids (<tt>pthread_t</tt> values) to be reused in this case.  Although it is
+not completely clear whether this originally was the right decision, it
+is clearly the established practice, and we believe it was always the
+intent of the C++ threads API to follow Posix and allow this.  Howard
+Hinnant's example implementation implicitly relies on allowing reuse
+of ids, since it uses Posix thread ids directly.
+</p>
+
+<p>
+It is important to be clear on this point, since it the reuse of thread
+ids often requires extra care in client code, which would not be
+necessary if thread ids were unique across all time.  For example, a
+hash table indexed by thread id may have to be careful not to associate
+data values from an old thread with a new one that happens to reuse the
+id.  Simply removing the old entry after joining a thread may not be
+sufficient, if it creates a visible window between the join and removal
+during which a new thread with the same id could have been created and
+added to the table.
+</p>
+
+<p><i>[
+post Bellevue Peter adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+There is a real issue with <tt>thread::id</tt> reuse, but I urge the LWG to
+reconsider fixing this by disallowing reuse, rather than explicitly allowing
+it. Dealing with thread id reuse is an incredibly painful exercise that
+would just force the world to reimplement a non-conflicting <tt>thread::id</tt> over
+and over.
+</p>
+<p>
+In addition, it would be nice if a <tt>thread::id</tt> could be manipulated
+atomically in a lock-free manner, as motivated by the recursive lock
+example:
+</p>
+
+<p>
+<a href="http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html">http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html</a>
 </p>
+</blockquote>
+
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add the following to the specification of <tt>map::at()</tt>, 23.3.1.2 [map.access]:
+Add a sentence to 30.2.1.1 [thread.thread.id]/p1:
 </p>
+
 <blockquote>
 <p>
-<i>Complexity:</i> logarithmic.
+An object of type <code>thread::id</code> provides
+a unique identifier for each thread of execution
+and a single distinct value for all thread objects
+that do not represent a thread of execution ([thread.threads.class]).
+Each thread of execution has a <code>thread::id</code>
+that is not equal to the <code>thread::id</code>
+of other threads of execution
+and that is not equal to
+the <code>thread::id</code> of <code>std::thread</code> objects
+that do not represent threads of execution.
+<ins>The library may reuse the value of a <code>thread::id</code> of a
+terminated thread that can no longer be joined.</ins>
 </p>
 </blockquote>
 
@@ -26296,143 +29623,153 @@ Add the following to the specification of <tt>map::at()</tt>, 23.3.1.2 [map.acce
 
 
 <hr>
-<h3><a name="705"></a>705. type-trait <tt>decay</tt> incompletely specified</h3>
-<p><b>Section:</b> 20.4.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p>
+<h3><a name="789"></a>789. <tt>xor_combine_engine(result_type)</tt> should be explicit</h3>
+<p><b>Section:</b> 26.4.4.4 [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.adapt.xor">issues</a> in [rand.adapt.xor].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The current working draft has a type-trait <tt>decay</tt> in 20.4.7 [meta.trans.other].
+<tt>xor_combine_engine(result_type)</tt> should be <tt>explicit</tt>. (Obvious oversight.)
 </p>
 
-<p>
-Its use is to turn C++03 pass-by-value parameters into efficient C++0x
-pass-by-rvalue-reference parameters. However, the current definition
-introduces an incompatible change where the cv-qualification of the
-parameter type is retained. The deduced type should loose such
-cv-qualification, as pass-by-value does.
-</p>
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Non-controversial. Bill is right, but Fermilab believes that this is
+easy to use badly and hard to use right, and so it should be removed
+entirely. Got into TR1 by well defined route, do we have permission to
+remove stuff? Should probably check with Jens, as it is believed he is
+the originator. Broad consensus that this is not a robust engine
+adapter.
+</blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-In 20.4.7 [meta.trans.other] change the last sentence:
+Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis].
 </p>
-
-<blockquote><p>
-Otherwise the  member typedef <tt>type</tt> equals <tt><ins>remove_cv&lt;</ins>U<ins>&gt;::type</ins></tt>.
-</p></blockquote>
-
 <p>
-In 20.3.1.3 [tuple.creation]/1 change:
+Remove 26.4.4.4 [rand.adapt.xor] <tt>xor_combine_engine</tt>.
 </p>
 
-<blockquote><p>
-<del>where each <tt>Vi</tt> in <tt>VTypes</tt> is <tt>X&amp;</tt> if, for the
-corresponding type <tt>Ti</tt> in <tt>Types</tt>,
-<tt>remove_cv&lt;remove_reference&lt;Ti&gt;::type&gt;::type</tt> equals
-<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
-<tt>decay&lt;Ti&gt;::type</tt>.</del>
-<ins>Let <tt>Ui</tt> be <tt>decay&lt;Ti&gt;::type</tt> for each
-<tt>Ti</tt> in <tt>Types</tt>. Then each <tt>Vi</tt> in <tt>VTypes</tt>
-is <tt>X&amp;</tt> if <tt>Ui</tt> equals
-<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
-<tt>Ui</tt>.</ins>
-</p></blockquote>
-
-
 
 
 
 
 <hr>
-<h3><a name="706"></a>706. <tt>make_pair()</tt> should behave as <tt>make_tuple()</tt> wrt. <tt>reference_wrapper()</tt></h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</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>
+<h3><a name="792"></a>792. <tt>piecewise_constant_distribution</tt> is undefined for a range with just one endpoint</h3>
+<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The current draft has <tt>make_pair()</tt> in 20.2.3 [pairs]/16
-and <tt>make_tuple()</tt> in 20.3.1.3 [tuple.creation].
-<tt>make_tuple()</tt> detects the presence of
-<tt>reference_wrapper&lt;X&gt;</tt> arguments and "unwraps" the reference in
-such cases. <tt>make_pair()</tt> would OTOH create a
-<tt>reference_wrapper&lt;X&gt;</tt> member. I suggest that the two
-functions are made to behave similar in this respect to minimize
-confusion.
+<tt>piecewise_constant_distribution</tt> is undefined for a range with just one
+endpoint. (Probably should be the same as an empty range.)
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-In 20.2 [utility] change the synopsis for make_pair() to read
-</p>
-
-<blockquote><pre>template &lt;class T1, class T2&gt;
-  pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>, <del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt; make_pair(T1&amp;&amp;, T2&amp;&amp;);
-</pre></blockquote>
-
-<p>
-In 20.2.3 [pairs]/16 change the declaration to match the above synopsis.
-Then change the 20.2.3 [pairs]/17 to:
+Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
 </p>
 
 <blockquote>
-<p>
-<i>Returns:</i> <tt>pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>,<del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt;(forward&lt;T1&gt;(x),forward&lt;T2&gt;(y))</tt> <ins>where <tt>V1</tt> and
-<tt>V2</tt> are determined as follows: Let <tt>Ui</tt> be
-<tt>decay&lt;Ti&gt;::type</tt> for each <tt>Ti</tt>. Then each
-<tt>Vi</tt> is <tt>X&amp;</tt> if <tt>Ui</tt> equals
-<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
-<tt>Ui</tt>.</ins>
-</p>
+b) If <tt>firstB == lastB</tt> <ins>or the sequence <tt>w</tt> has the length zero</ins>,
 </blockquote>
 
 
 
 
 
-
 <hr>
-<h3><a name="712"></a>712. <tt>seed_seq::size</tt> no longer useful</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Marc Paterno <b>Date:</b> 2007-08-25</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</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>
+<h3><a name="798"></a>798. Refactoring of binders lead to interface breakage</h3>
+<p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-02-14</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-One of the motivations for incorporating <tt>seed_seq::size()</tt>
-was to simplify the wording
-in other parts of 26.4 [rand].
-As a side effect of resolving related issues,
-all such references
-to <tt>seed_seq::size()</tt> will have been excised.
-More importantly,
-the present specification is contradictory,
-as "The number of 32-bit units the object can deliver"
-is not the same as "the result of <tt>v.size()</tt>."
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2521.pdf">N2521</a>
+and its earlier predecessors have moved the old binders from
+[lib.binders] to D.8 [depr.lib.binders] thereby introducing some renaming
+of the template parameter names (<tt>Operation -&gt; Fn</tt>). During this
+renaming process the <em>protected</em> data member <tt>op</tt> was also renamed to
+<tt>fn</tt>, which seems as an unnecessary interface breakage to me - even if
+this user access point is probably rarely used.
 </p>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
+Change D.8.1 [depr.lib.binder.1st]:
 </p>
 
+<blockquote>
+<pre>template &lt;class Fn&gt; 
+class binder1st 
+  : public unary_function&lt;typename Fn::second_argument_type, 
+                          typename Fn::result_type&gt; { 
+protected: 
+  Fn <del>fn</del> <ins>op</ins>; 
+  typename Fn::first_argument_type value; 
+public: 
+  binder1st(const Fn&amp; x, 
+            const typename Fn::first_argument_type&amp; y); 
+  typename Fn::result_type 
+    operator()(const typename Fn::second_argument_type&amp; x) const; 
+  typename Fn::result_type 
+    operator()(typename Fn::second_argument_type&amp; x) const; 
+};
+</pre>
+
+<blockquote>
+<p>
+-1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
+</p>
+<p>
+-2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
+</p>
+</blockquote>
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+Change D.8.3 [depr.lib.binder.2nd]:
 </p>
 
+<blockquote>
+<pre>template &lt;class Fn&gt; 
+class binder2nd
+  : public unary_function&lt;typename Fn::first_argument_type, 
+                          typename Fn::result_type&gt; { 
+protected: 
+  Fn <del>fn</del> <ins>op</ins>; 
+  typename Fn::second_argument_type value; 
+public: 
+  binder2nd(const Fn&amp; x, 
+            const typename Fn::second_argument_type&amp; y); 
+  typename Fn::result_type 
+    operator()(const typename Fn::first_argument_type&amp; x) const; 
+  typename Fn::result_type 
+    operator()(typename Fn::first_argument_type&amp; x) const; 
+};
+</pre>
+
+<blockquote>
+<p>
+-1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
+</p>
+<p>
+-2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
+</p>
+</blockquote>
+</blockquote>
 
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
 
 
 
diff --git a/libstdc++-v3/doc/xml/manual/intro.xml b/libstdc++-v3/doc/xml/manual/intro.xml
index 8cca6f3..b64b969 100644 (file)
--- a/libstdc++-v3/doc/xml/manual/intro.xml
+++ b/libstdc++-v3/doc/xml/manual/intro.xml
@@ -611,7 +611,7 @@
     <listitem><para>Follow the straightforward proposed resolution.
     </para></listitem></varlistentry>
 
-    <varlistentry><term><ulink url="../ext/lwg-active.html#550">550</ulink>:
+    <varlistentry><term><ulink url="../ext/lwg-defects.html#550">550</ulink>:
         <emphasis>What should the return type of pow(float,int) be?</emphasis>
     </term>
     <listitem><para>In C++0x mode, remove the pow(float,int), etc., signatures.
@@ -623,7 +623,7 @@
     <listitem><para>Change it to be a formatted output function (i.e. catch exceptions).
     </para></listitem></varlistentry>
 
-    <varlistentry><term><ulink url="../ext/lwg-active.html#596">596</ulink>:
+    <varlistentry><term><ulink url="../ext/lwg-defects.html#596">596</ulink>:
         <emphasis>27.8.1.3 Table 112 omits "a+" and "a+b" modes</emphasis>
     </term>
     <listitem><para>Add the missing modes to fopen_mode.
@@ -654,13 +654,13 @@
     <listitem><para>Make the member functions table and classic_table public.
     </para></listitem></varlistentry>
 
-    <varlistentry><term><ulink url="../ext/lwg-active.html#761">761</ulink>:
+    <varlistentry><term><ulink url="../ext/lwg-defects.html#761">761</ulink>:
         <emphasis>unordered_map needs an at() member function</emphasis>
     </term>
     <listitem><para>In C++0x mode, add at() and at() const.
     </para></listitem></varlistentry>
 
-    <varlistentry><term><ulink url="../ext/lwg-active.html#775">775</ulink>:
+    <varlistentry><term><ulink url="../ext/lwg-defects.html#775">775</ulink>:
         <emphasis>Tuple indexing should be unsigned?</emphasis>
     </term>
     <listitem><para>Implement the int -> size_t replacements.
@@ -672,14 +672,14 @@
     <listitem><para>In C++0x mode, remove assign, add fill.
     </para></listitem></varlistentry>
 
-    <varlistentry><term><ulink url="../ext/lwg-active.html#778">778</ulink>:
+    <varlistentry><term><ulink url="../ext/lwg-defects.html#778">778</ulink>:
         <emphasis>std::bitset does not have any constructor taking a string 
                  literal</emphasis>
     </term>
     <listitem><para>Add it.
     </para></listitem></varlistentry>
 
-    <varlistentry><term><ulink url="../ext/lwg-active.html#781">781</ulink>:
+    <varlistentry><term><ulink url="../ext/lwg-defects.html#781">781</ulink>:
         <emphasis>std::complex should add missing C99 functions</emphasis>
     </term>
     <listitem><para>In C++0x mode, add std::proj.
Domain: System / Toolchain;