OSDN Git Service

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
libstdc++-v3/doc/html/ext/lwg-active.html
libstdc++-v3/doc/html/ext/lwg-closed.html
libstdc++-v3/doc/html/ext/lwg-defects.html
libstdc++-v3/doc/xml/manual/intro.xml

index cbb6671..c4a4926 100644 (file)
@@ -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,
index 27e0ed2..94b57c0 100644 (file)
@@ -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:
<